IM-Workflow

jp.co.intra_mart.foundation.workflow.application.process
クラス ProcessManager

java.lang.Object
  上位を拡張 jp.co.intra_mart.foundation.workflow.application.process.ProcessManager

public class ProcessManager
extends Object

処理マネージャ

案件の処理に必要な情報の取得や、再申請、承認、承認終了、否認、取止め、差戻し、保留、保留削除の処理を行うことができます。
引戻しの処理については、引戻しマネージャ「PullBackManager」を利用してください。

処理マネージャの設定が必要なノード情報等を取得する処理では、申請マネージャApplyManager」とは違い、トランザクションデータを用いて行なっています。
マスタデータに変更があった場合でも、その情報が反映されてない状態でデータが取得されます。

詳細は各メソッドの説明を参照してください。

導入されたバージョン:
7.2
関連項目:
PullBackManager, ApplyManager

コンストラクタの概要
ProcessManager(String loginGroupId, String localeId, String systemMatterId, String nodeId)
          コンストラクタ
引数で指定したログイングループID、ロケールID、システム案件ID、ノードIDで処理マネージャを
新しく生成します。
 
メソッドの概要
 void applyFromUnapply(ApplyFromUnapplyParam applyFromUnapplyParam, Map<String,Object> userParam)
          未申請状態の案件(起票した案件)の申請処理を実行します。
 void approve(ApproveParam approveParam, Map<String,Object> userParam)
          承認処理を行います。
 void approveEnd(ApproveEndParam approveEndParam, Map<String,Object> userParam)
          承認終了処理を行います。
 void deny(DenyParam denyParam, Map<String,Object> userParam)
          否認処理を行います。
 void discontinue(DiscontinueParam discontinueParam, Map<String,Object> userParam)
          取止め処理を行います。
 AuthUserModel[] getAuthUser(String executeUserCode)
          指定したユーザの未完了案件に対する処理権限者情報を取得します。
 AuthUserOrgzModel[] getAuthUserOrgz(String authUserCode)
          指定したユーザの未完了案件に対する処理権限者の所属組織情報を取得します。
 NodeConfigSetToProcessModel getConfigSetToProcess()
          承認等の処理を行う際に処理権限者等の設定が可能なノード情報を取得します。
 NodeConfigSetToProcessModel getConfigSetToProcessWithProcessTarget()
          承認等の処理を行う際に処理権限者等の設定が可能なノード情報を初期値で設定した処理権限者情報と共に取得します。
 MatterNodeModel[] getNodesToSendBack()
          特定のノードから差戻し可能なノード情報を取得します。
 Boolean isPossibleToProcess(String executeUserCode)
          パラメータで指定したユーザが対象案件のノードで処理を実行できるか判定します。
 void reapply(ReapplyParam reapplyParam, Map<String,Object> userParam)
          案件の再申請処理を実行します。
 void reserve(ReserveParam reserveParam, Map<String,Object> userParam)
          保留処理を行います。
 void reserveCancel(ReserveCancelParam reserveCancelParam, Map<String,Object> userParam)
          保留解除処理を行います。
 void sendBack(SendBackParam sendBackParam, Map<String,Object> userParam)
          差戻し処理を行います。
 
クラス java.lang.Object から継承されたメソッド
equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
 

コンストラクタの詳細

ProcessManager

public ProcessManager(String loginGroupId,
                      String localeId,
                      String systemMatterId,
                      String nodeId)
コンストラクタ
引数で指定したログイングループID、ロケールID、システム案件ID、ノードIDで処理マネージャを
新しく生成します。

パラメータ:
loginGroupId - ログイングループID
localeId - ロケールID
systemMatterId - システム案件ID
nodeId - ノードID
メソッドの詳細

applyFromUnapply

public void applyFromUnapply(ApplyFromUnapplyParam applyFromUnapplyParam,
                             Map<String,Object> userParam)
                      throws WorkflowException
未申請状態の案件(起票した案件)の申請処理を実行します。

このメソッドでは内部でトランザクションの制御処理を行なっています。
メソッドの実行前に、ユーザトランザクションを終了状態にして置く必要があります。

ApplyManager.draft(jp.co.intra_mart.foundation.workflow.application.model.param.DraftParam)」で起票した案件の、起票後の申請処理を行います。

「applyFromUnapplyParam 起票案件申請用パラメータ情報」に設定されている内容での申請処理を行います。

「申請実行者コード」と「申請権限者コード」が異なる場合には、代理権限での申請処理になります。
申請者の組織情報を指定する場合には、「会社コード」、「組織セットコード」、「組織コード」の3つのパラメータをセットで指定します。

申請時に動的承認・確認ノードの処理対象者を指定する場合には、パラメータの「動的・確認ノード設定情報の配列」を設定します。

申請時に横・縦配置ノードを展開したり、処理対象者を設定する場合には、パラメータの「横配置・縦配置ノード設定情報の配列」を設定します。

申請時に分岐開始ノードの分岐先を指定する場合には、パラメータの「分岐先選択情報の配列」を設定します。

申請ノードで設定できる各ノード情報は「ApplyManager.getConfigSetToApply(String, String)」等で取得できますが、
申請処理時に特にチェック処理は行なっていません。設定可能なノードの指定とは関係なく、処理できます。
但し、申請ノードの直後に、展開が必要な横・縦配置ノードが存在し、そのノードが展開されてない状態で、申請処理が実行されると、
例外「WorkflowException」が発生します。申請ノード直後に横・縦配置ノードがある場合には、必ずパラメータに展開情報を設定する必要があります。

申請処理を行う際に、起票処理時とは異なる「案件番号」、「案件名」、「優先度」を指定した場合は、
該当する案件データ(「imw_t_actv_matter」テーブルや「matter.xml」ファイルデータ)を新規で設定したデータに更新します。

申請処理で行う内部の詳細処理については、「ApplyManager.apply(jp.co.intra_mart.foundation.workflow.application.model.param.ApplyParam, Map)」の【案件申請処理】からの処理説明を参照してください。

パラメータ:
applyFromUnapplyParam - 起票案件申請用パラメータ情報
userParam - ユーザパラメータマップ
例外:
WorkflowException - ワークフロー例外

reapply

public void reapply(ReapplyParam reapplyParam,
                    Map<String,Object> userParam)
             throws WorkflowException
案件の再申請処理を実行します。

申請済みの案件が、差戻しや引戻し等の処理で、申請ノードに戻された場合に、申請ノードからの再申請を行います。

このメソッドでは内部でトランザクションの制御処理を行なっています。
メソッドの実行前に、ユーザトランザクションを終了状態にして置く必要があります。

「reapplyParam 再申請用パラメータ情報」に設定されている内容での再申請処理を行います。

「実行者コード」と「権限者コード」が異なる場合には、代理権限での再申請処理になります。
申請者の組織情報を指定する場合には、「会社コード」、「組織セットコード」、「組織コード」の3つのパラメータをセットで指定します。

再申請時に動的承認・確認ノードの処理対象者を指定する場合には、パラメータの「動的・確認ノード設定情報の配列」を設定します。

再申請時に横・縦配置ノードを展開したり、処理対象者を設定する場合には、パラメータの「横配置・縦配置ノード設定情報の配列」を設定します。
指定した横・縦配置ノードが既に別の処理で展開されている場合には、横・縦配置ノードをマスタフローを参照し、元の状態に戻してから、再展開処理を行います。

再申請時に分岐開始ノードの分岐先を指定する場合には、パラメータの「分岐先選択情報の配列」を設定します。

再申請ノードで設定できる各ノード情報は「getConfigSetToProcess()」等で取得できますが、
再申請処理時に特にチェック処理は行なっていません。設定可能なノードの指定とは関係なく、処理できます。
但し、申請ノードの直後に、展開が必要な横・縦配置ノードが存在し、そのノードが展開されてない状態で、再申請処理が実行されると、
例外「WorkflowException」が発生します。申請ノード直後に横・縦配置ノードがある場合には、必ずパラメータに展開情報を設定する必要があります。

再申請を行う際に別の処理で添付した案件の添付ファイルを削除する場合には「削除対象システムファイル名」に対象ファイル名を指定します。

再申請処理を行う際に、他の処理時とは異なる「案件番号」、「案件名」、「優先度」を指定した場合は、
該当する案件データ(「imw_t_actv_matter」テーブルや「matter.xml」ファイルデータ)を新規で設定したデータに更新します。

再申請処理で行う内部の詳細処理については、「ApplyManager.apply(jp.co.intra_mart.foundation.workflow.application.model.param.ApplyParam, Map)」の【案件申請処理】からの処理説明を参照してください。

パラメータ:
reapplyParam - 再申請用パラメータ情報
userParam - ユーザパラメータマップ
例外:
WorkflowException - ワークフロー例外

discontinue

public void discontinue(DiscontinueParam discontinueParam,
                        Map<String,Object> userParam)
                 throws WorkflowException
取止め処理を行います。

このメソッドでは内部でトランザクションの制御処理を行なっています。
メソッドの実行前に、ユーザトランザクションを終了状態にして置く必要があります。

「discontinueParam 取止め用パラメータ情報」に設定されている内容での取止め処理を行います。

「実行者コード」と「権限者コード」が異なる場合には、代理権限での取止め処理になります。
処理者の組織情報を指定する場合には、「会社コード」、「組織セットコード」、「組織コード」の3つのパラメータをセットで指定します。

取止め処理では、処理待ち状態になっている処理ノードを終了し、次のノードを開始せずに、案件終了処理を行うことになります。
即ち、処理待ちノードの終了後に開始されるノードはありません。結果的に終了ノードの開始処理も実行されませので、
終了ノードの到達処理や他に実行される到達処理はありません。フローに設定した案件終了時の処理は実行されます。

ただし、取止めにより実行された案件終了処理で例外が発生した場合には、終了ノードを開始して置く処理が自動で行われます。
この処理は、エラーになった案件を引戻しや案件操作で処理できるようにする為に行われます。

処理待ち状態になっている処理ノードの終了と、案件終了処理の内部処理は基本「approve(ApproveParam, Map)」と同じ動きになります。
approve(ApproveParam, Map)」の説明を参照してください。(※終了ノードの到達処理は動作しません。)

取止め処理はノードの完了ステータスの違い以外では、否認処理「deny(DenyParam, Map)」や承認終了処理「approveEnd(ApproveEndParam, Map)」と同じ処理になります。

処理対象ノードに確認ノードが繋がっている場合でも、本メソッドの処理により確認ノードは到達状態になりません。確認処理できない状態のままです。
確認処理ができるようにするには、取止めではなく、承認処理「approve(ApproveParam, Map)」を行う必要があります。

パラメータ:
discontinueParam - 取止め用パラメータ情報
userParam - ユーザパラメータマップ
例外:
WorkflowException - ワークフロー例外

approve

public void approve(ApproveParam approveParam,
                    Map<String,Object> userParam)
             throws WorkflowException
承認処理を行います。

このメソッドでは内部でトランザクションの制御処理を行なっています。
メソッドの実行前に、ユーザトランザクションを終了状態にして置く必要があります。

「approveParam 承認用パラメータ情報」に設定されている内容での承認処理を行います。

「実行者コード」と「権限者コード」が異なる場合には、代理権限での承認処理になります。
承認者の組織情報を指定する場合には、「会社コード」、「組織セットコード」、「組織コード」の3つのパラメータをセットで指定します。

承認処理時に動的承認・確認ノードの処理対象者を指定する場合には、パラメータの「動的・確認ノード設定情報の配列」を設定します。

承認処理時に横・縦配置ノードを展開したり、処理対象者を設定する場合には、パラメータの「横配置・縦配置ノード設定情報の配列」を設定します。
指定した横・縦配置ノードが既に別の処理で展開されている場合には、横・縦配置ノードをマスタフローを参照し、元の状態に戻してから、再展開処理を行います。

承認処理時に分岐開始ノードの分岐先を指定する場合には、パラメータの「分岐先選択情報の配列」を設定します。

承認ノードで設定できる各ノード情報は「getConfigSetToProcess()」等で取得できますが、
承認処理時に特にチェック処理は行なっていません。設定可能なノードの指定とは関係なく、処理できます。

承認処理時に別の処理で添付した案件の添付ファイルを削除する場合には「削除対象システムファイル名」に対象ファイル名を指定します。

承認処理時に、他の処理時とは異なる「案件番号」、「案件名」、「優先度」を指定した場合は、
該当する案件データ(「imw_t_actv_matter」テーブルや「matter.xml」ファイルデータ)を新規データに更新します。

承認ノードの直後に、展開が必要な横・縦配置ノードが存在し、そのノードが展開されてない状態で、承認処理が実行されると、
例外「WorkflowException」が発生します。承認ノード直後に横・縦配置ノードがある場合には、必ずパラメータに展開情報を設定する必要があります。

承認処理では、処理待ち状態になっている処理ノードで【案件承認処理】を行います。
承認処理を行う前に、まずパラメータに設定されている分岐開始ノードの分岐先設定や、動的承認、横・縦配置ノードの設定情報を基に、
処理フロー情報の変更処理を行います。この変更されたフロー情報は承認処理が終了するまでに、そのまま使用されます。
例えば、アクション処理等でフロー情報XMLを変更しても、その情報は処理中のフロー情報には反映されません。

案件承認処理は、承認ノードを終了し、次のノードへの移動処理になります。
ノードの移動処理では、ユーザのアクション処理と到達処理が実行されます。承認ノードの次が終了ノードの場合は案件終了時処理も実行されます。
下記の拡張ポイントのプラグイン処理を拡張することで、処理を追加することができます。
アクション処理:「jp.co.intra_mart.workflow.plugin.event.node.action.process」
到達処理:「jp.co.intra_mart.workflow.plugin.event.node.arrive.process」
案件終了時処理:「jp.co.intra_mart.workflow.plugin.event.matter.end.process」

アクション処理は承認ノードに設定されている処理が実行されます。
アクション処理の実行は、ノードの移動処理の前に実行されます。アクション処理では移動処理前の状態のデータが取得されます。
アクション処理にはパラメータで設定した「userParam ユーザパラメータ」がそのまま渡されます。
アクション処理に渡したいデータがある場合には、「ユーザパラメータ」を利用してください。
アクション処理で実行される外部プログルムのデータベースへの登録・更新処理等もこのメソッド内のノード移動処理と同じトランザクション内の処理になります。
アクション処理の実行や、ノード移動処理が全て正常に終了されない場合には、登録した全データがロールバックされて、「WorkflowException」が発生します。
エラーが発生したタイミングによっては、データベース処理のみロールバックされて、作成したXMLファイル情報はそのまま残る場合もありますが、
再度処理を行う時に影響はありません。ゴミデータになります。

承認ノードのアクション処理では、処理結果として「案件番号」を返すことができます。
(※標準で提供しているアクション処理のサンプルでは、承認処理時には返却値を返せないように実装されています。)
アクション処理の実行結果、案件番号が返却された場合には、その値で案件データを更新します。承認時のパラメータに指定した案件番号より優先されます。

ノード移動処理は、IM-Workflowのエンジンのノード移動ロジックで、データの作成、更新、削除処理を行います。
前処理で作成された承認ノードの情報を処理中のデータを保存する「imw_t_actv_task」、「imw_t_actv_executable_user」、「imw_t_actv_user_orgz」等から削除し、
タスク完了データとして「imw_t_cpl_task」、「imw_t_cpl_user」に保存します。
その後承認ノードの次のノードの情報を処理中の新データとして、「imw_t_actv_task」、「imw_t_actv_executable_user」、「imw_t_actv_user_orgz」等に保存します。
データベースへの更新処理と共に、XMLファイルの更新処理も行います。

XMLファイルの更新処理は、処理タスクID別に履歴ディレクトリを作成し、その中にXMLファイル情報を作成する処理になります。
作成対象ファイルは、フロー情報XML「flow.xml」、進捗情報XML「progress.xml」、処理履歴情報XML「history.xml」、処理対象者情報XML「executableUser.xml」です。
(※処理対象者情報XML「executableUser.xml」は承認ノードの次のノードの開始処理時のみ作成します。)
(※処理履歴情報XML「history.xml」、処理対象者情報XML「executableUser.xml」は、トランザクションファイルレベル設定が「[2]:全てのファイル情報を作成」の場合に作成します。)
格納されるディレクトリは、案件テーブル「imw_t_actv_matter」の最終処理ID「LAST_PROCESS_ID」を基に作成します。
承認ノードの終了処理時には「ep_」で始まる最終処理IDが付与されます。
承認ノードの次のノードの開始処理時には「sp_」で始まる最終処理IDが付与されます。
標準の設定の場合は、各ファイルは下記に格納されます。
※{%StorageService%}/storage/workflow/data/{%ログイングループID%}/transaction/yyyymm/dd/hh/{%システム案件ID%}/task/{%最終処理ID%}/flow.xml
※{%StorageService%}/storage/workflow/data/{%ログイングループID%}/transaction/yyyymm/dd/hh/{%システム案件ID%}/task/{%最終処理ID%}/progress.xml
※{%StorageService%}/storage/workflow/data/{%ログイングループID%}/transaction/yyyymm/dd/hh/{%システム案件ID%}/task/{%最終処理ID%}/history.xml
※{%StorageService%}/storage/workflow/data/{%ログイングループID%}/transaction/yyyymm/dd/hh/{%システム案件ID%}/task/{%最終処理ID%}/executableUser.xml

ノード移動処理後には、承認ノードの次のノードが処理ノードの場合は、処理対象者展開処理が実行されます。
「executableUser.xml」はこのタイミングで作成されます。
処理対象者展開処理後には、承認ノードの次のノードに指定した到達処理が実行されます。
処理対象者展開処理や到達処理はIM-Workflowのシステムパラメータの同期/非同期制御パラメータ「arrive-process-async」が「true(標準)」の場合は、
非同期で実行されます。逆の設定の場合は、同期に処理されます。
非同期・同期処理に関わらず、処理対象者展開処理や到達処理は本メソッドとは別トランザクション処理になります。
処理対象者展開処理では内部でトランザクション制御を行なっていますが、到達処理の実行処理の内部では、トランザクション制御を行なっていませんので、
実行される到達処理で制御を行う必要があります。
同じく、非同期・同期処理に関わらず、到達処理で失敗した場合でも、このメソッドの処理には影響がありません。正常終了になります。
尚、一覧系のメソッドで、非同期で実行された到達処理等がまだ実行中の場合にはその案件は取得対象外にする場合があります。
その制御の為に、非同期で実行中の到達処理の情報は「imw_t_thread」で管理されています。

承認ノードに確認ノードが繋がっている場合には、確認ノードを初期化し、確認可能な状態に変更します。
確認ノードのデータと権限者情報を「imw_t_confirm」、「imw_t_confirm_user」、「imw_t_confirm_orgz」に作成し、関連するXMLファイルを作成・初期化します。
確認ノードの権限者作成処理は、処理者展開処理と同じく非同期処理で行います。処理者展開処理を実行するタイミングで一緒に処理されます。
作成される確認ノード関連XMLファイルは、標準設定の場合は下記に格納されます。
※{%StorageService%}/storage/workflow/data/{%ログイングループID%}/transaction/yyyymm/dd/hh/{%システム案件ID%}/operation_history/confirm.xml
※{%StorageService%}/storage/workflow/data/{%ログイングループID%}/transaction/yyyymm/dd/hh/{%システム案件ID%}/operation_history/confirmEnableUser.xml

承認処理が終了した後に、添付ファイルが存在する場合には、ファイルの移動処理を行います。
添付ファイルの一時領域から、案件のトランザクションファイルデータフォルダに移動します。
標準の設定の場合、添付ファイルは下記に格納されます。
※{%StorageService%}/storage/workflow/data/{%ログイングループID%}/transaction/yyyymm/dd/hh/{%システム案件ID%}/attachfile
添付ファイル移動処理後、全ての処理が終了した後に、根回しメールの送信処理を行います。
メール送信は内部トランザクションを終了した後に実行します。送信処理でエラーになった場合でも、本メソッドの処理には影響ありません。

承認ノードの次のノードが分岐ノードの場合は、分岐先の判別処理を行い、決定した分岐先への移動処理を行います。
ノード移動処理の内部処理は、承認時の処理と同様です。
ただし、分岐ノードの判別で、次のノードに移動した場合に、本メソッドの承認処理により実行される到達処理は、
分岐の判断で移動して到達した分岐先ノードの到達処理が実行されます。
分岐先の判別のために、実行される分岐ロジック(分岐開始ノードに設定されているプラグイン)は、
本メソッドで実行されるアクション処理やノードの移動処理と同じトランザクションになりますので、
承認ノードの次が分岐ノードで、分岐先判別処理で例外が発生した場合は、承認できず、例外「WorkflowException」が発生します。

承認ノードの次のノードが終了ノードの場合は、処理中の案件は【案件終了処理】により終了されます。
承認処理による案件終了時には、フローに設定した終了ノードの到達処理と案件終了時処理と内部の案件終了処理が実行されます。
3つの処理順番は「終了ノードの到達処理」→「案件終了処理(「案件終了時処理」→「内部の案件終了処理」)」になります。
3つの処理は、上記の処理対象者や到達処理と同じく、非同期設定によって、同期あるいは非同期(標準)で実行されます。
設定の詳細は上記の処理対象者や到達処理の説明を参照してください。
非同期・同期処理に関わらず、3つの処理は本メソッドとは別トランザクション処理になります。
到達処理や案件終了時処理の実行処理の内部ではトランザクション制御を行なっていませんので、実行される処理で制御を行う必要があります。
2つの処理実行後に実行される内部の案件終了処理ではトランザクション制御を行なっています。前に実行される2つの処理でトランザクションを終了して置く必要があります。

「終了ノードの到達処理」の実行で失敗した場合は、案件終了処理は実行されません。終了ノードが処理待ちの状態になります。
「案件終了処理」の実行で失敗した場合でも、DBデータはロールバックされ、終了ノードが処理待ちの状態になります。
この状態では、承認等の処理は実行できません。
直前の処理した人が引戻し「PullBackManager.pullBack(jp.co.intra_mart.foundation.workflow.application.model.param.PullBackParam, Map)」をするか、
案件操作「ActvMatterHandleManager.moveActvNode(String, String[])」で他のノードに移動させる必要があります。

案件終了処理では「imw_t_actv_」で始まる未完了案件関連データテーブルのデータを「imw_t_cpl_」で始まる完了案件関連テーブルへ移行する処理を行います。
データベースの移行処理後に、トランザクションデータファイルの整理処理を行います。
案件処理時に作成されたタスク情報を纏めて、ZIPファイルを作成します。標準の設定の場合に、完了案件のファイルは下記のようになります。
※{%StorageService%}/storage/workflow/data/{%ログイングループID%}/transaction/yyyymm/dd/hh/{%システム案件ID%}/result/{%最終処理ID%}
※{%StorageService%}/storage/workflow/data/{%ログイングループID%}/transaction/yyyymm/dd/hh/{%システム案件ID%}/task.zip
  ※「task.zip」ファイルは履歴の為に作成されるファイルです。内部処理では使用されていません。
  ※「task.zip」を作成するかしないかの設定は、ログイングループパラメータの「not-make-task-zip-file」で設定できます。

パラメータ:
approveParam - 承認用パラメータ情報
userParam - ユーザパラメータマップ
例外:
WorkflowException - ワークフロー例外

approveEnd

public void approveEnd(ApproveEndParam approveEndParam,
                       Map<String,Object> userParam)
                throws WorkflowException
承認終了処理を行います。

このメソッドでは内部でトランザクションの制御処理を行なっています。
メソッドの実行前に、ユーザトランザクションを終了状態にして置く必要があります。

「approveEndParam 承認終了用パラメータ情報」に設定されている内容での承認終了処理を行います。

「実行者コード」と「権限者コード」が異なる場合には、代理権限での承認終了処理になります。
承認者の組織情報を指定する場合には、「会社コード」、「組織セットコード」、「組織コード」の3つのパラメータをセットで指定します。

承認処理時に別の処理で添付した案件の添付ファイルを削除する場合には「削除対象システムファイル名」に対象ファイル名を指定します。

承認終了処理時に、他の処理時とは異なる「案件番号」、「案件名」、「優先度」を指定した場合は、
該当する案件データ(「imw_t_actv_matter」テーブルや「matter.xml」ファイルデータ)を新規で設定したデータに更新します。

承認終了処理では、処理待ち状態になっている処理ノードを終了し、次のノードを開始せずに、案件終了処理を行うことになります。
即ち、処理待ちノードの終了後に開始されるノードはありません。結果的に終了ノードの開始処理も実行されませので、
終了ノードの到達処理や他に実行される到達処理はありません。フローに設定した案件終了時の処理は実行されます。

ただし、承認終了による案件終了処理では例外が発生した場合には、終了ノードを開始して置く処理が自動で行われます。
この処理は、エラーになった案件を引戻しや案件操作で処理できるようにする為です。

処理待ち状態になっている処理ノードの終了と、案件終了処理の内部処理は基本「approve(ApproveParam, Map)」と同じ動きになります。
approve(ApproveParam, Map)」の説明を参照してください。(※終了ノードの到達処理は動作しません。)

承認終了処理はノードの完了ステータスの違い以外では、否認処理「deny(DenyParam, Map)」や取止め処理「discontinue(DiscontinueParam, Map)」と同じ処理になります。

処理対象ノードに確認ノードが繋がっている場合でも、本メソッドの処理により確認ノードは到達状態になりません。確認処理できない状態のままです。
確認処理ができるようにするには、承認終了ではなく、承認処理「approve(ApproveParam, Map)」を行う必要があります。

パラメータ:
approveEndParam - 承認終了用パラメータ情報
userParam - ユーザパラメータマップ
例外:
WorkflowException - ワークフロー例外

getNodesToSendBack

public MatterNodeModel[] getNodesToSendBack()
                                     throws WorkflowException
特定のノードから差戻し可能なノード情報を取得します。

コンストラクタで指定した「nodeId ノードID」から差戻し先として指定可能なノードの情報を取得します。

差戻し先として指定可能なノードは、対象案件で処理されたノードの中で、指定したノードより前方向(開始側)に存在するノードになります。
詳細な仕様は「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

ルート情報以外に、処理された履歴の取得は「imw_t_cpl_task」テーブルから取得します。

XMLファイルからのデータ取得やデータベースの検索処理で失敗した場合には、例外「WorkflowException」が発生します。
ノードIDに対して、存在有無のチェックは行なっていません。指定したノードIDがフロー情報に存在しない場合にも例外「WorkflowException」が発生します。

戻り値:
MatterNodeModel[] 案件ノード情報の配列
例外:
WorkflowException - ワークフロー例外

sendBack

public void sendBack(SendBackParam sendBackParam,
                     Map<String,Object> userParam)
              throws WorkflowException
差戻し処理を行います。

このメソッドでは内部でトランザクションの制御処理を行なっています。
メソッドの実行前に、ユーザトランザクションを終了状態にして置く必要があります。

「sendBackParam 差戻し用パラメータ情報」に設定されている内容での差戻し処理を行います。

「実行者コード」と「権限者コード」が異なる場合には、代理権限での差戻し処理になります。
処理者の組織情報を指定する場合には、「会社コード」、「組織セットコード」、「組織コード」の3つのパラメータをセットで指定します。

差戻し処理時に、他の処理時とは異なる「案件番号」、「案件名」、「優先度」を指定した場合は、
該当する案件データ(「imw_t_actv_matter」テーブルや「matter.xml」ファイルデータ)を新規データに更新します。

差戻し先に指定可能なノード情報は「getNodesToSendBack()」で取得できますが、
差戻し時に特にチェック処理は行なっていません。設定可能なノードの指定とは関係なく、処理できます。

差戻し処理では、処理待ち状態になっている差戻し元ノードを終了し、差戻し先ノードへの移動処理を行います。

ノードの移動処理では、差戻し元ノードのユーザアクション処理と差戻し先ノードの到達処理が実行されます。
下記の拡張ポイントのプラグイン処理を拡張することで、処理を追加することができます。
アクション処理:「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のエンジンのノード移動ロジックで、データの作成、更新、削除処理を行います。
ノードの移動処理については、承認処理「approve(ApproveParam, Map)」で行なっている処理と同じです。
approve(ApproveParam, Map)」のノード移動処理関連の説明を参照してください。
ただし、差戻し処理では、差戻し元ノードから差戻し先ノードへの移動処理以外に、下記の処理を行います。
差戻し元ノードに関しては、差戻しステータスで完了した後に、再びキャンセル処理を行い、処理していない状態に戻します。
その後、差戻し元ノードから差戻し先ノードまでのルート上に存在するノードの処理ステータスをキャンセルに変更する処理を行います。
キャンセルされたノードは処理されてない状態と同じ扱いになります。
差戻し元ノードから差戻し先ノードの間にあるノードのキャンセル処理は、ノードの移動処理は1個ずつ繰り返して行います。
このノード移動処理中では、各ノードに対してユーザの展開処理やアクション処理、到達処理の実行を行なっていません。単純なノードの移動処理になります。
到達処理やユーザの展開処理が実行されるのは、最後の差戻し先ノードのみになります。

差戻し先ノードで行われるユーザ展開処理では、前回に処理したユーザのみが展開されます。

全ての処理が終了した後に、根回しメールの送信処理を行います。
メール送信は内部トランザクションを終了した後に実行します。送信処理でエラーになった場合でも、本メソッドの処理には影響ありません。

差戻し元ノードに確認ノードが繋がっている場合でも、本メソッドの処理により確認ノードは到達状態になりません。確認処理できない状態のままです。
確認処理ができるようにするには、差戻しではなく、承認処理「approve(ApproveParam, Map)」を行う必要があります。

パラメータ:
sendBackParam - 差戻し用パラメータ情報
userParam - ユーザパラメータマップ
例外:
WorkflowException - ワークフロー例外

deny

public void deny(DenyParam denyParam,
                 Map<String,Object> userParam)
          throws WorkflowException
否認処理を行います。

このメソッドでは内部でトランザクションの制御処理を行なっています。
メソッドの実行前に、ユーザトランザクションを終了状態にして置く必要があります。

「denyParam 否認用パラメータ情報」に設定されている内容での否認処理を行います。

「実行者コード」と「権限者コード」が異なる場合には、代理権限での否認処理になります。
否認者の組織情報を指定する場合には、「会社コード」、「組織セットコード」、「組織コード」の3つのパラメータをセットで指定します。

否認処理では、処理待ち状態になっている処理ノードを終了し、次のノードを開始せずに、案件終了処理を行うことになります。
即ち、処理待ちノードの終了後に開始されるノードはありません。結果的に終了ノードの開始処理も実行されませので、
終了ノードの到達処理や他に実行される到達処理はありません。フローに設定した案件終了時の処理は実行されます。

ただし、否認による案件終了処理では例外が発生した場合には、終了ノードを開始して置く処理が自動で行われます。
この処理は、エラーになった案件を引戻しや案件操作で処理できるようにする為です。

処理待ち状態になっている処理ノードの終了と、案件終了処理の内部処理は基本「approve(ApproveParam, Map)」と同じ動きになります。
approve(ApproveParam, Map)」の説明を参照してください。(※終了ノードの到達処理は動作しません。)

否認処理はノードの完了ステータスの違い以外では、取止め処理「discontinue(DiscontinueParam, Map)」や承認終了処理「approveEnd(ApproveEndParam, Map)」と同じ処理になります。

処理対象ノードに確認ノードが繋がっている場合でも、本メソッドの処理により確認ノードは到達状態になりません。確認処理できない状態のままです。
確認処理ができるようにするには、否認ではなく、承認処理「approve(ApproveParam, Map)」を行う必要があります。

パラメータ:
denyParam - 否認用パラメータ情報
userParam - ユーザパラメータマップ
例外:
WorkflowException - ワークフロー例外

reserve

public void reserve(ReserveParam reserveParam,
                    Map<String,Object> userParam)
             throws WorkflowException
保留処理を行います。

このメソッドでは内部でトランザクションの制御処理を行なっています。
メソッドの実行前に、ユーザトランザクションを終了状態にして置く必要があります。

「reserveParam 保留用パラメータ情報」に設定されている内容での保留処理を行います。

「実行者コード」と「権限者コード」が異なる場合には、代理権限での保留処理になります。

保留処理では、処理対象ノードから自分自身への移動処理を行うことになります。
ただし、自分自身への移動処理を行う際に、処理対象者はパラメータで指定した権限者以外の処理者を処理不可に変更して、展開します。

保留処理による対象ノードのアクション処理は実行されますが、到達処理は実行されません。

自分自身への移動処理の詳細仕様は承認処理「approve(ApproveParam, Map)」と同じです。
承認処理「approve(ApproveParam, Map)」のノード移動処理関連説明を参照してください。

処理対象ノードに確認ノードが繋がっている場合でも、本メソッドの処理により確認ノードは到達状態になりません。確認処理できない状態のままです。
確認処理ができるようにするには、保留ではなく、承認処理「approve(ApproveParam, Map)」を行う必要があります。

保留削除を行うには、「reserveCancel(ReserveCancelParam, Map)」や「ActvMatterHandleManager.reserveCancel(ReserveCancelParam, String)」を利用してください。

パラメータ:
reserveParam - 保留用パラメータ情報
userParam - ユーザパラメータマップ
例外:
WorkflowException - ワークフロー例外

reserveCancel

public void reserveCancel(ReserveCancelParam reserveCancelParam,
                          Map<String,Object> userParam)
                   throws WorkflowException
保留解除処理を行います。

このメソッドでは内部でトランザクションの制御処理を行なっています。
メソッドの実行前に、ユーザトランザクションを終了状態にして置く必要があります。

「reserveCancelParam 保留解除用パラメータ情報」に設定されている内容での保留削除処理を行います。

「実行者コード」と「権限者コード」が異なる場合には、代理権限での保留削除処理になります。

保留削除処理では、処理対象ノードから自分自身への移動処理を行うことになります。
ただし、自分自身への移動処理を行う際に、処理対象者は処理不可になっている権限者を処理可に変更して、展開します。

保留削除処理による対象ノードのアクション処理は実行されますが、到達処理は実行されません。

自分自身への移動処理の詳細仕様は承認処理「approve(ApproveParam, Map)」と同じです。
承認処理「approve(ApproveParam, Map)」のノード移動処理関連説明を参照してください。

処理対象ノードに確認ノードが繋がっている場合でも、本メソッドの処理により確認ノードは到達状態になりません。確認処理できない状態のままです。
確認処理ができるようにするには、保留削除ではなく、承認処理「approve(ApproveParam, Map)」を行う必要があります。

管理者権限で、ノードを指定して保留削除を行うには、「ActvMatterHandleManager.reserveCancel(ReserveCancelParam, String)」を利用してください。

パラメータ:
reserveCancelParam - 保留解除用パラメータ情報
userParam - ユーザパラメータマップ
例外:
WorkflowException - ワークフロー例外

isPossibleToProcess

public Boolean isPossibleToProcess(String executeUserCode)
                            throws WorkflowException
パラメータで指定したユーザが対象案件のノードで処理を実行できるか判定します。

コンストラクタで指定した案件の特定ノードに対して、
パラメータで指定した「executeUserCode 実行者コード」のユーザが処理できるかを判定します。

指定したユーザが他のユーザの保留処理によって処理不可になった等、処理できない場合でも、
「false:処理不可能」を返却します。
対象のノードが既に処理されている場合でも、「false:処理不可能」を返却します。
案件が存在しない場合は、例外「WorkflowException」が発生します。

このメソッドでは代理のチェックを行なっています。
指定したユーザが代理権限(ノードにより、申請権限又は処理権限)があり、代理先ユーザの権限で処理できる場合でも、
「true:処理可能」を返却します。

このメソッドでは、タスク処理対象者テーブル「imw_t_actv_executable_user」テーブルにあるユーザデータと、
その代理先情報である「imw_t_act」や「imw_t_act_temporary_expand」テーブルから必要なデータを取得します。

データベースの検索処理でエラーが発生した場合には、例外「WorkflowException」が発生します。

処理権限があるユーザに対して、処理権限者情報を取得するには、「getAuthUser(String)」を利用してください。

パラメータ:
executeUserCode - 実行者コード
戻り値:
Boolean 処理可否判定結果(true:処理可能 / false:処理不可能)
例外:
WorkflowException - ワークフロー例外

getAuthUserOrgz

public AuthUserOrgzModel[] getAuthUserOrgz(String authUserCode)
                                    throws WorkflowException
指定したユーザの未完了案件に対する処理権限者の所属組織情報を取得します。

未完了案件のタスク処理権限者組織情報テーブル「imw_t_actv_user_orgz」に保存されているデータを基に、
指定したユーザが選択できる所属組織情報を取得します。
このメソッドでは代理設定情報は考慮されていません。代理権限で代理先ユーザの所属組織を取得したい場合は、
代理先ユーザコードをパラメータに指定する必要があります。

指定したユーザが保留によって処理不可になっている場合は、その所属組織情報は取得できません。サイズ0のオブジェクトを返却します。
指定したユーザが選択可能な組織情報が存在しない場合でも、サイズ0の空オブジェクトを返却します。
ユーザの所属組織が複数存在する場合は、権限者の「会社コード」「組織セットコード」「組織コード」の各項目の昇順でソートされます。

データベースへの検索処理に失敗した場合は、例外「WorkflowException」が発生します。

一括処理時に選択可能な組織情報を取得するには、「LumpAuthUserOrgzManager.getProcAuthUserOrgz(String[])」を利用してください。

起票処理を行う前にマスタデータ情報を基に処理権限者の所属組織情報を取得するには、「ApplyManager.getAuthUserOrgz(String, String, String)」を利用してください。

パラメータ:
authUserCode - 権限者コード
戻り値:
AuthUserOrgzModel[] 処理権限者所属組織情報の配列
例外:
WorkflowException - ワークフロー例外

getAuthUser

public AuthUserModel[] getAuthUser(String executeUserCode)
                            throws WorkflowException
指定したユーザの未完了案件に対する処理権限者情報を取得します。

コンストラクタで指定した案件の特定ノードに対して、
パラメータで指定した「executeUserCode 実行者コード」のユーザが処理できる場合に、その権限者の情報を取得できます。

指定したユーザが他のユーザの保留処理によって処理不可になった場合等で処理できない場合には、
サイズ0の空オブジェクトを返却します。
対象のノードが既に処理されている場合でも、サイズ0の空オブジェクトを返却します。
案件が存在しない場合は、例外「WorkflowException」が発生します。

このメソッドでは代理のチェックを行なっています。
指定したユーザが代理権限(ノードにより、申請権限又は処理権限)があり、代理先ユーザの権限で処理できる場合には、
その代理先ユーザ情報も取得されます。

このメソッドでは、タスク処理対象者テーブル「imw_t_actv_executable_user」テーブルにあるユーザデータと、
その代理先情報である「imw_t_act」や「imw_t_act_temporary_expand」テーブルから必要なデータを取得します。

データベースの検索処理でエラーが発生した場合には、例外「WorkflowException」が発生します。

処理権限者情報を取得する前に、処理ができるかの判断のみを行う場合は、「isPossibleToProcess(String)」を利用してください。
特定ユーザが処理を行う際に、選択できる所属組織情報を取得するには、「getAuthUserOrgz(String)」利用してください。

パラメータ:
executeUserCode - 実行者コード
戻り値:
AuthUserModel[] 処理権限者情報の配列
例外:
WorkflowException - ワークフロー例外

getConfigSetToProcess

public NodeConfigSetToProcessModel getConfigSetToProcess()
                                                  throws WorkflowException
承認等の処理を行う際に処理権限者等の設定が可能なノード情報を取得します。

処理を行う際に、設定が可能な動的承認ノード、確認ノード、横・縦配置ノード、分岐開始ノードが存在する場合には、
その設定が可能なノード関連情報を取得できます。

このメソッドでは、設定が可能なノード情報を取得する際に、その設定対象ノードに初期値で設定されている処理権限者情報を除いて取得します。
処理対象者の初期化設定ができるノードは動的承認ノード、確認ノード、横・縦配置ノードです。
初期値で指定した処理対象者情報を含めて取得したい場合には、「getConfigSetToProcessWithProcessTarget()」を利用してください。

返却モデルの「NodeConfigSetToProcessModel 設定対象ノードセット情報(処理用)」には処理ノードの各情報と、設定が可能なノードがあればその情報が格納されます。
・処理ノードで、ある確認ノードの処理対象者を設定可能な場合は返却モデル内の「設定対象確認ノード情報(処理用)の配列」にその確認ノード情報が設定されます。
・処理ノードで、ある動的承認ノードの処理対象者を設定可能な場合は返却モデル内の「設定対象動的承認ノード情報(処理用)の配列」にその動的承認ノード情報が設定されます。
・処理ノードで、ある横配置ノードの展開設定や処理対象者を設定可能な場合は返却モデル内の「設定対象横配置ノード情報(処理用)の配列」にその横配置ノード情報が設定されます。
・処理ノードで、ある縦配置ノードの展開設定や処理対象者を設定可能な場合は返却モデル内の「設定対象縦配置ノード情報(処理用)の配列」にその縦配置ノード情報が設定されます。
・処理ノードで、ある分岐開始ノードの分岐先を設定可能な場合は返却モデル内の「設定対象分岐開始ノード情報(処理用)の配列」にその分岐開始ノード情報が設定されます。
各項目に対して、設定ができない場合には、該当項目にサイズ0にオブジェクトが設定されます。

このメソッドで必要なデータの取得は、トランザクションデータを用いて行なっています。マスタデータに変更があった場合でも、その情報が反映されてない状態で取得されます。

申請処理で設定が可能なノード情報を取得するには、「ApplyManager.getConfigSetToApply(String, String)」を利用してください。

戻り値:
NodeConfigSetToProcessModel 設定対象ノードセット情報(処理用)
例外:
WorkflowException - ワークフロー例外

getConfigSetToProcessWithProcessTarget

public NodeConfigSetToProcessModel getConfigSetToProcessWithProcessTarget()
                                                                   throws WorkflowException
承認等の処理を行う際に処理権限者等の設定が可能なノード情報を初期値で設定した処理権限者情報と共に取得します。

処理を行う際に、設定が可能な動的承認ノード、確認ノード、横・縦配置ノード、分岐開始ノードが存在する場合には、
その設定が可能なノード関連情報を取得できます。

このメソッドでは、設定が可能なノード情報を取得する際に、その設定対象ノードに初期値で設定されている処理権限者情報を含めて取得します。
処理対象者の初期化設定ができるノードは動的承認ノード、確認ノード、横・縦配置ノードです。
初期値で指定した処理対象者情報を除いて取得したい場合には、「getConfigSetToProcess()」を利用してください。

返却モデルの「NodeConfigSetToProcessModel 設定対象ノードセット情報(処理用)」には処理ノードの各情報と、設定が可能なノードがあればその情報が格納されます。
・処理ノードで、ある確認ノードの処理対象者を設定可能な場合は返却モデル内の「設定対象確認ノード情報(処理用)の配列」にその確認ノード情報が設定されます。
・処理ノードで、ある動的承認ノードの処理対象者を設定可能な場合は返却モデル内の「設定対象動的承認ノード情報(処理用)の配列」にその動的承認ノード情報が設定されます。
・処理ノードで、ある横配置ノードの展開設定や処理対象者を設定可能な場合は返却モデル内の「設定対象横配置ノード情報(処理用)の配列」にその横配置ノード情報が設定されます。
・処理ノードで、ある縦配置ノードの展開設定や処理対象者を設定可能な場合は返却モデル内の「設定対象縦配置ノード情報(処理用)の配列」にその縦配置ノード情報が設定されます。
・処理ノードで、ある分岐開始ノードの分岐先を設定可能な場合は返却モデル内の「設定対象分岐開始ノード情報(処理用)の配列」にその分岐開始ノード情報が設定されます。
各項目に対して、設定ができない場合には、該当項目にサイズ0にオブジェクトが設定されます。

このメソッドで必要なデータの取得は、トランザクションデータを用いて行なっています。マスタデータに変更があった場合でも、その情報が反映されてない状態で取得されます。

申請処理で設定が可能なノード情報を初期値で設定した処理権限者情報と共に取得するには、「ApplyManager.getConfigSetToApplyWithProcessTarget(String, String)」を利用してください。

戻り値:
NodeConfigSetToProcessModel 設定対象ノードセット情報(処理用)
例外:
WorkflowException - ワークフロー例外

IM-Workflow

Copyright © 2000-2015 NTT DATA INTRAMART CO.,LTD.. All Rights Reserved.