PEXA Supportについて

PEXAプロパティ

トランスレータ

印刷フレームワーク

AETフレームワーク

ワークフロー

動的フォーム

変換フレームワーク

テンプレートエンジン

カレンダー

タスクスケジューラー
目次

  1. はじめに
  2. 全体構成
  3. スキーマ構成
    1. 承認対象スキーマ
    2. 承認ルートスキーマ
  4. データモデル構成
    1. 承認対象(WF_Target)
    2. 承認状態管理情報(WF_Request)
  5. データモデルカスタマイズ(項目追加)
  6. ワークフロー処理の流れ
    1. 申請者による承認対象の生成
    2. 申請者による申請
    3. 承認者による申請情報の取得
    4. 承認者による承認or返却or保留
    5. 申請者による申請取下
    6. 承認者による承認取消
    7. 承認者による保留解除
  7. ワークフローイベント
    1. イベントの種類
    2. フィードバック
    3. モデルイベント
  8. 承認権限管理
    1. 標準の権限管理機能を使用する場合
    2. 独自の権限管理を行う場合
    3. 絞込フィルタ
    4. 権限委譲


はじめに

このドキュメントは、ワークフローフレームワークのアーキテクチャについて解説するものです。

ワークフローフレームワークは、機能ブロックが３つに分かれていて、更にデータモデル及びスキーマが関連してきます。
このドキュメントに一通り目を通して全体構成を把握した上で利用してください。


全体構成

図１：全体構成

  • 青：プログラム要素
  • 紫：スキーマ
  • 緑：データモデル

図１は、ワークフローフレームワークの機能を構成している各要素の関係を表したものです。
機能ブロックとして大きく分けて以下の３つに分類されています。

  • アプリケーション
  • 承認ルート制御機能
  • 承認権限制御機能
これらの機能ブロック中に、プログラム的な要素、データモデル、スキーマが存在していて、
それぞれが関連しあって機能を構成しています。以下のそれぞれの概略を示します。

プログラム要素

ワークフローフレームワークのエンジン部分や、呼び出し元となるアプリケーションなどです。

WorkflowOperationがワークフローエンジン部分の機能の呼び出し口となっています。
これはService定義からサービスプロセス(format_type = workflow)の形で呼び出すことができます。

後述のワークフロー処理の流れの項で、それぞれがどのような流れで機能を呼び出していくかを説明します。


スキーマ

スキーマとしては以下の２種類があります。
詳細は以降の章で解説します。

  • 承認対象スキーマ：ワークフローに流したいデータモデルと承認ルートの関連付けを行います。
  • 承認ルートスキーマ：承認ルートそのものを定義し、状態遷移表的な構成でルートの中身を記述します。


データモデル

ワークフローフレームワークを使用する上で必要となるデータモデルが標準で提供されています。
承認状態等が記録されるトランザクション系モデル、権限情報等を管理するマスタ系モデルがあります。
これらは大きく分けて以下の４種類に分類されます。

  • 承認状態管理情報：承認対象データモデルの申請者、提出先、操作履歴、現在状態などが記録されます。
  • 権限委譲情報：ユーザー間での一時的な権限委譲について、委譲元、委譲先、有効期間などが記録されます。
  • 権限管理マスタ：ユーザーの伝票承認権限を管理するワークフロー標準提供マスタです。
  • 操作者マスタ：ユーザー情報を表すPEXA標準提供マスタです。
これらの具体的なデータモデル名及びそれらの間の関連については次の章で解説します。



スキーマ構成

ワークフローフレームワークでは、以下の２つのスキーマが用意されています。

ここでは、それぞれにどのような情報が含まれるか解説します。
なお、それぞれのスキーマの詳細については別途リファレンスがありますのでそちらを参照してください。

承認対象スキーマ

承認対象となるデータモデルに、どの承認ルートが適用されるかを定義するスキーマです。
承認対象となるデータモデル１つに対して１スキーマ作成します。

承認対象と適用ルートの関係は以下の３通りがあります。

  • 固定的に特定のルートが必ず適用される
  • 適用候補のルートが複数あり、承認対象の内容によってどれか一つに決まる
  • 適用候補のルートが複数あり、承認対象の内容によって複数決まる
このスキーマでは上記の３通りのケースに対応できるようになっています。
また、適用結果が見つからなかったり、適用結果が１つになることを期待しているのに複数になったりした場合にエラーとするか無視するか等指定できます。

詳細はスキーマリファレンスを参照してください。

承認対象スキーマの記述サンプル 

;;---------------------------------------------------------------
;; Current-Module:   $HeadURL: http://pexa.atrris.com/repos/trunk/readme.txt $
;; Release-Date:     $Date:: 2014-11-10 08:54:57 #$
;; Release-Version:  $Revision: 7828 $
;; First-Created-On: 2010/06/29
;; First-Created-By: morishita
;; Copy-Right-Owner: %Q%
;; ---------------------------------------------------------------
;; Description:
;; ---------------------------------------------------------------
(workflow_target
    workflow_target_id      "WTG_TEST_000001"
    workflow_target_name    "TestHeaderModel"
    (request
        ;;--------------------------------------------
        ;; 申請時の適用ルートマッピング
        ;;--------------------------------------------
        [route_matching
            ;------------------------------------------
            ; TestHeaderModelのCommentがnull以外の場合
            ;------------------------------------------
            filter      "@WF_Target/Comment is not null"
            route       "テスト照査ルート１"
            ,
            ;------------------------------------------
            ; TestHeaderModelのCommentがnullの場合
            ;------------------------------------------
            filter      "@WF_Target/Comment is null"
            route       "テスト照査ルート２"
        ]
        unique                  "true"
        no_found_ignore         "false"
    )
)


承認ルートスキーマ

承認対象に適用される承認ルートそのものを定義するスキーマです。
承認ルートをどのような粒度で定義すべきは、ワークフローフレームワークでは定めていません。
基本的には以下の２通りの考え方があります。

  • 承認対象を基準にして対応するルートを作成する
  • 承認ルートを主として先に作成し後から承認対象をマッピングする
企業内における承認行為は、対象の伝票を軸に考えられている場合が多いので前者が該当しやすく、
役所内における承認行為は、法律によって承認内容が先に決まっていて、そこに個々の書類がマッチングされるような場合があり後者が該当しやすくなります。

このスキーマは、状態遷移表のような形で記述するようになっています。

  • 承認対象が申請された場合にどの承認ポイントに入るか？
  • ある承認ポイント上で承認された場合に次の遷移先となる承認ポイントがどこになるか？
を記述することで承認ルートの全体構成を記述します。

また、承認対象がルートを出入りすることでワークフローイベントが内部で発生します。
そのイベント発生時にフィードバックやモデルイベント送信などを行うように指定することができます。

詳細はスキーマリファレンスを参照してください。

承認ルートスキーマの記述サンプル 

;;---------------------------------------------------------------
;; Current-Module:   $HeadURL: http://pexa.atrris.com/repos/trunk/readme.txt $
;; Release-Date:     $Date:: 2014-11-10 08:54:57 #$
;; Release-Version:  $Revision: 7828 $
;; First-Created-On: 2010/06/29
;; First-Created-By: morishita
;; Copy-Right-Owner: %Q%
;; ---------------------------------------------------------------
;; Description:
;; ---------------------------------------------------------------
(workflow_route
    workflow_route_id       "WRT_TEST_000001"
    workflow_route_name     "テスト照査ルート１"
    ;;--------------------------------------------
    ;; 条件
    ;;--------------------------------------------
    (condition
        ;;--------------------------------------------
        ;; 申請可能条件
        ;;--------------------------------------------
        [request
            filter      "@WF_Target/TotalQuantity is not null"
            error       "TotalQuantityがnullなら申請できません"
            ,
            filter      "@WF_Target/TotalQuantity = 0"
            error       "TotalQuantityが0以外なら申請できません"
        ]
        ;;--------------------------------------------
        ;; 決裁取消可能条件
        ;;--------------------------------------------
        (unapprove
            filter      "@WF_Target/TotalQuantity is not null"
            error       "TotalQuantityがnullである"
        )
    )
    ;;--------------------------------------------
    ;; 申請時の状態マッチング
    ;;--------------------------------------------
    (request
        [state_matching
            filter      "@WF_Target/TotalQuantity = 0"
            state       "01:部門長承認待ち"
            ,
            filter      "@WF_Target/TotalQuantity > 1"
            state       "02:経理承認待ち"
        ]
    )
    ;;--------------------------------------------
    ;; 状態遷移表
    ;;--------------------------------------------
    (state_chart
        ;;--------------------------------------------
        ;; 部門長承認待ち
        ;;--------------------------------------------
        (01:部門長承認待ち
            (receiver
                finder  "common"
                filter  "@WF_Request/WF_Target/申請時部署No in @WF_Receiver/部署List/部署No"
                ;;↑同じ部署の部長のみに絞るフィルタ
            )
            (operation
                (ACCEPT
                    (state_matching
                        state   02:経理承認待ち
                    )
                )
            )
        )
        ;;--------------------------------------------
        ;; 経理承認待ち
        ;;--------------------------------------------
        (02:経理承認待ち
            (receiver
                finder  "common"
            )
            (operation
                (ACCEPT
                    (state_matching
                        state   03:役員承認待ち
                    )
                )
            )
        )
        ;;--------------------------------------------
        ;; 役員承認待ち
        ;;--------------------------------------------
        (03:役員承認待ち
            (receiver
                finder  "common"
            )
            (operation
                (ACCEPT
                    [state_matching
                        state       04:社長決済
                        filter      "@WF_Target/TotalQuantity >= 100000000"
                        ,
                        state       APPROVED
                        filter      "@WF_Target/TotalQuantity < 100000000"
                    ]
                )
            )
        )
        ;;--------------------------------------------
        ;; 社長決済待ち
        ;;--------------------------------------------
        (04:社長決済待ち
            (receiver
                finder  "common"
            )
            (operation
                (ACCEPT
                    (state_matching
                        state       APPROVED
                    )
                )
            )
        )
    )
    ;;--------------------------------------------
    ;; フィードバック
    ;;--------------------------------------------
    (feedback
        ;;--------------------------------------------
        ;; 申請(NOT_REQUESTED -> REQUESTED)
        ;;--------------------------------------------
        (REQUESTED
            commit      true
            (mapping
                WorkflowFeedbackComment "申請中"
            )
        )
        ;;--------------------------------------------
        ;; 申請取下(REQUESTED -> NOT_REQUESTED)
        ;;--------------------------------------------
        (UNREQUESTED
            commit      true
            (mapping
                WorkflowFeedbackComment "&Null"
            )
        )
        ;;--------------------------------------------
        ;; 最終承認(REQUESTED -> APPROVED)
        ;;--------------------------------------------
        (APPROVED
            commit  true
            (mapping
                WorkflowFeedbackComment "決裁済"
            )
        )
        ;;--------------------------------------------
        ;; 最終承認取消(APPROVED -> REQUESTED)
        ;;--------------------------------------------
        (UNAPPROVED
            commit  true
            (mapping
                WorkflowFeedbackComment "申請中"
            )
        )
        ;;--------------------------------------------
        ;; 返却(REQUESTED -> REJECTED)
        ;;--------------------------------------------
        (REJECTED
            commit  true
            (mapping
                WorkflowFeedbackComment "返却済"
            )
        )
        ;;--------------------------------------------
        ;; 保留(REQUESTED->SUSPENDED)
        ;;--------------------------------------------
        (SUSPENDED
            commit  true
            (mapping
                WorkflowFeedbackComment "保留中"
            )
        )
        ;;--------------------------------------------
        ;; 保留解除(SUSPENDED -> REQUESTED)
        ;;--------------------------------------------
        (UNSUSPENDED
            commit  true
            (mapping
                WorkflowFeedbackComment "申請中"
            )
        )
    )
    ;;--------------------------------------------
    ;; モデルイベント送信
    ;;--------------------------------------------
    (send
        ;;--------------------------------------------
        ;; 最終承認(REQUESTED -> APPROVED)
        ;;--------------------------------------------
        (APPROVED
            table_name  "SampleEventTable" ;;必須
            ;;operation ACCEPT      ;;省略可。デフォルトはイベント名に対応したModelOperationCategoryがセットされる。
            ;;unsync    true/false  ;;省略可。デフォルトはfalse
        )
        ;;--------------------------------------------
        ;; 最終承認取消(APPROVED -> REQUESTED)
        ;;--------------------------------------------
        (UNAPPROVED
            table_name  "SampleEventTable" ;;必須
            ;;operation UNACCEPT    ;;省略可。デフォルトはイベント名に対応したModelOperationCategoryがセットされる。
            ;;unsync    true/false  ;;省略可。デフォルトはfalse
        )
        ;;--------------------------------------------
        ;; 返却(REQUESTED -> REJECTED)
        ;;--------------------------------------------
        (REJECTED
            table_name  "SampleEventTable" ;;必須
            ;;operation REJECT      ;;省略可。デフォルトはイベント名に対応したModelOperationCategoryがセットされる。
            ;;unsync    true/false  ;;省略可。デフォルトはfalse
        )
    )
)



データモデル構成

図２：データモデル構成

  • 水：WFトランザクション系モデル
  • 紫：業務固有トランザクションモデル
  • 緑：PEXA標準オペレータ系マスタモデル
  • 橙：プロセスベース系WFマスタモデル
  • 青：ロールベース系WFマスタモデル

ワークフローフレームワークでは、定義ファイルだけでなく多数のデータモデルが動作に関係しています。
ここでは、具体的にどのようなデータモデルがあるのか解説します。

承認状態管理情報

承認対象の適用ルート、現在状態、申請者、提出先といった制御用の情報を記録するデータモデル群です。

承認対象のデータモデルが申請されたタイミングでWF_Requestのインスタンスがワークフローエンジンによって新規生成されます。
以降はワークフロー操作が行われるごとに操作履歴が追加されつつ承認状態が管理されていきます。

WF_Requestデータモデルは中心的な役割を果たすものでアプリケーション側でも参照することになります。
このデータモデルの内容については以降で別途説明します。こちらを参照してください。

モデルID モデル名 提供レベル 説明
--- 承認対象となる
個別のデータモデル 		プロジェクト 組織内部で第三者による承認を必要とするデータモデルです。
見積、受注、発注依頼、請求依頼などプロジェクトごとの個別のデータモデルとなります。
DML_PEXA_920001 WF_Request ワークフロー 承認対象の申請、承認状態を記録するデータモデルです。
申請時のタイミングにワークフローエンジンによってインスタンスが生成されて、適用された承認ルートや現在状態などが記録されます。
以降は承認者による承認行為や返却行為などが行われるたびにワークフローエンジンによって参照されながら承認状態が制御されます。
DML_PEXA_920002 WF_OperationHistory ワークフロー ワークフロー操作履歴を記録するデータモデルです。
WorkflowOperationによってワークフローエンジンの機能が呼び出される毎に生成されて、WF_Requestの明細として保存されます。
アプリケーション側で参考情報として表示したり、引き戻し処理の制御に利用されたりします。

権限委譲情報

操作者の間で一時的に承認権限を委譲することを記録するデータモデルです。

このデータモデルの生成はワークフローエンジンではサポートしません。アプリケーションから直接登録されることを想定しています。
ここに記録された情報と、権限管理マスタ群の情報がワークフローエンジンによって実行時に重ねあわされてアプリケーション上に反映されます。

モデルID モデル名 提供レベル 説明
DML_PEXA_920003 WF_Delegation ワークフロー 操作者間での権限委譲に関する情報を記録するデータモデルです。
委譲元、委譲先、有効期間といった情報が保持されます。

権限管理マスタ

操作者の承認権限を管理する標準提供マスタモデル群です。

主なマスタモデルはWF_RoleとWF_AcceptPointで、それ以外は明細モデルもしくは組み合わせモデルとなります。
これらを使用するかどうかは任意です。使用しない場合は個別に権限の仕組みを用意して、承認ルートスキーマから呼び出すように記述します。

なお、ワークフローフレームワークにおける承認権限そのものを表すマスタモデルはWF_AcceptPointです。
このモデルは承認ルート中の承認ポイントを表し、そこに参加することができる操作者が「承認権限を持つ」ということになります。
権限設定は以下の２通りの観点から行うことができるように構成されています。

  • 操作者に権限を割り当てる：この観点の場合、権限集合であるロールを操作者マスタに貼り付けます。
  • 承認ポイントに操作者を割り当てる：この観点の場合、承認ルート中の各承認ポイントに操作者を配置する形になります。
上記は片方のみでも利用できますし、両者を混在させて利用することもできます。

モデルID モデル名 提供レベル 説明
DML_PEXA_920011 WF_Role ワークフロー 承認権限のセットを表すマスタモデルです。
操作者に権限を割り当てる観点で権限設定する場合に、あらかじめこのマスタで権限の集合を作成しておいて、操作者にはこのロールを割り当てます。
DML_PEXA_920012 WF_RoleAcceptPoint ワークフロー WF_Roleの明細モデルです。ロールが持つ権限を表します。
DML_PEXA_920013 WF_OperatorRole ワークフロー 操作者マスタとロールを結びつける組み合わせマスタです。
操作者に権限を割り当てる観点で権限設定する場合に使用します。
DML_PEXA_920014 WF_OperatorGroupRole ワークフロー 操作者グループマスタとロールを結びつける組み合わせマスタです。
操作者に権限を割り当てる観点で権限設定する場合に使用します。
DML_PEXA_920021 WF_AcceptPoint ワークフロー 承認権限を表すマスタモデルです。
ワークフローフレームワークにおける承認権限とは、承認ルート中の各承認ポイントに参加できる・できないという観点で定義します。
そのため、このマスタは承認ルートスキーマの内容と同期している必要があります。
DML_PEXA_920022 WF_AcceptPointOperator ワークフロー WF_AcceptPointの明細モデルで、承認ポイントに参加する操作者を表します。
承認ポイントに操作者を割り当てるという観点で権限設定を行う場合に使用します。
DML_PEXA_920023 WF_AcceptPointOperatorGroup ワークフロー WF_AcceptPointの明細モデルで、承認ポイントに参加する操作者グループを表します。
承認ポイントに操作者を割り当てるという観点で権限設定を行う場合に使用します。

操作者マスタ

ユーザーマスタに該当するPEXA標準提供のマスタモデル群です。

これらのデータモデルはワークフローフレームワーク以外でも利用されるPEXA標準のマスタモデルです。
WF_Requestに記録される申請者、提出先などがこれらのマスタモデルを指すように設計されているため、ワークフローフレームワークにおいても必須となります。

モデルID モデル名 提供レベル 説明
DML_PEXA_000001 Operator PEXA 操作者を表すマスタモデルです。
WF_Requestに含まれる申請者や提出先といった情報はこのOperatorモデルを指すことで表現されます。
DML_PEXA_000011 OperatorGroup PEXA 操作者グループを表すマスタモデルです。
承認対象を特定の個人に申請するのではなく、グループに対して行うような場合は提出先がこのOperatorGroupを指すことになります。
DML_PEXA_000012 OperatorGroupMemeber PEXA OperatorGroupの明細モデルです。
操作者グループに所属するメンバーとなるOperatorを指します。


承認対象(WF_Target)

ワークフローの申請・承認行為で取り扱う対象となる業務情報を表すデータモデルです。
これは、各プロジェクト毎に設計される個別のデータモデルとなります。(例：見積、発注、請求など)

後述のWF_Requestデータモデル側では、この承認対象データモデルのモデル名及びProxy値文字列を保持します。
そのため、WF_Requestから見るとWF_Targetは必ず一意に特定することが出来ます。

逆に承認対象データモデル側から、自身のモデル名及びProxy値文字列を持つWF_Requestを逆引きで検索することも出来ます。
この逆引きしたWF_Requestが何件になるかはワークフローアプリケーション側の都合により変わりますが、基本的には1:1となるように扱うのが望ましい形です。
1:Nの関係になると、逆引きした結果が有り、無し以外に複数というケースがでてくるため、アプリケーション側での扱いが難しくなります。

WF_Target側からWF_Requestを逆引きするためのProcedure項目及びProcedure実装がワークフローフレームワークで提供されています。
必要に応じてWF_Targetとなるデータモデルに追加してアプリケーション側で使用して下さい。

現象型定義 WF_Request
Procedure定義 WF_RequestModelProcedure
Procedure実装クラス pexa.share.util.procedure.wf.WF_RequestModelProcedure


承認状態管理情報(WF_Request)

ワークフローエンジンが取り扱うデータモデルの中心となるのがWF_Requestデータモデルです。
このWF_Requestに、承認対象に適用された承認ルートや現在の承認ポイントといった制御用の情報が書き込まれて管理されます。

WF_Requestが生成されるのは申請者による申請を行うタイミングです。
この時に呼び出されるワークフロー操作のMATCHING操作によって未コミットの状態でWF_Requestが生成されて、 REQUEST操作の実行によってコミットされます。
以降は各ワークフロー操作が呼び出される毎にワークフローエンジンが参照したり書き込んだりしながら処理が流れていきます。

WF_Requestが保持する項目は、大きく分けて以下の４タイプに分類されます。

以下でそれぞれについて説明します。

ワークフローエンジンが制御用に取り扱う項目

以下の項目は、ワークフローエンジンが承認対象の状態制御に使用する項目です。
アプリケーション側での更新は禁止となります。

現象型名 説明
WF_TargetName 承認対象のデータモデル名
WF_TargetProxyString 承認対象のデータモデルのProxy値文字列
WF_Requestor 申請者を指すFK項目(OperatorNo)
WF_RequestDate 申請日付
WF_RequestDatetime 申請日時
WF_RequestStatusCategory 承認状態区分
WF_RouteName 適用されたワークフロー承認ルート名
WF_RouteStateName ワークフロー承認ルート上での承認ポイント名
WF_Receiver 申請の受取者を表すFK項目(OperatorNo)。WF_ReceiverGroupNoと排他設定。最終承認後はnull。
WF_ReceiverGroupNo 申請の受取者グループを表すFK項目(OperatorGroupNo)。WF_Receiverと排他設定。最終承認後はnull。
WF_ReceiverDelegatedFlag 受取者が権限委譲されていることを表すフラグ
WF_LastAcceptor 直近の承認者を表すFK項目(OperatorNo)
WF_LastAcceptDate 直近の承認日付
WF_LastAcceptDatetime 直近の承認日時
WF_LastOperator 直近の操作者を表すFK項目(OperatorNo)
WF_LastOperationDate 直近の操作日付
WF_LastOperationDatetime 直近の操作日時
WF_LastOperationCategory 直近の操作区分
WF_OperationHistoryList ワークフロー操作履歴のリスト。ワークフロー操作の呼び出し毎にワークフローエンジンが追加していく。

アプリケーションが任意に使用できる項目

以下の項目は、ワークフローエンジンは使用せずアプリケーション側が任意に設定する項目です。
アプリケーション側で必要に応じて値を設定してください。

現象型名 説明
WF_RequestCode 申請行為に対して採番する申請コードです。必須でコード体系は任意です。
アプリケーション側でREQUEST操作の呼び出し前に設定してください。
WF_RequestRapidFlag 緊急フラグです。設定は任意です。
迅速に取り扱ってほしいという意志を表したい場合に設定してください。
WF_OperationComment 操作コメントです。設定は任意です。
申請者による申請時コメントや、承認者による承認者コメントを残したい場合に、
アプリケーション側でこの現象型でコメント文字列をWF_Requestに設定してください。
WF_OperationCommentが設定されていたら、ワークフローエンジンがその内容を操作履歴に保存します。

MATCHING操作の結果を表す揮発性項目

以下の項目は、MATCHING操作を呼び出した際にWF_Requestに設定されるマッチング結果を表す項目です。
DBカラムとマッピングされていない揮発性項目なので、WF_Requestがコミットされると消去されます。
申請、承認の実行画面の初期化などに利用してください。

現象型名 説明
WF_ExpectedRouteName 適用された承認ルートの名前です。
WF_ExpectedRouteStateName 遷移先となる次の承認ポイントの名前です。
WF_ExpectedReceiverList 次の承認ポイントにおける受取者となりうる、承認権限保持者リストです。
WF_ExpectedReceiverGroupList 次の承認ポイントにおける受取者グループとなりうる、承認権限保持グループリストです。

関連情報を取得するためのProcedure項目

以下の項目は、WF_Requestと関連する各種情報を取得するためのProcedure項目です。
アプリケーション側で必要に応じて参照してください。

現象型名 説明
WF_Target 承認対象データモデルを取得するProcedure項目です。
WF_TargetとWF_TargetProxyStringを元に取得します。
WF_RouteMeta 適用された承認ルートのメタ情報を返すProcedure項目です。
single combination項目となっており、無名モデルに情報を格納して返します。
WF_LastOperationHistory 最終操作履歴を取得するProcedure項目です。
WF_LastAcceptOperationHistory 直近の承認操作履歴を取得するProcedure項目です。
UNACCEPTされていない最新の承認操作の履歴を返します。
WF_LastRequestOperationHistory 直近の申請操作履歴を取得するProcedure項目です。
UNREQUESTされていない最新の申請操作の履歴を返します。


データモデルカスタマイズ(項目追加)

ワークフローエンジンが直接操作するデータモデルのうち、以下の物は各プロジェクト毎に任意の業務項目を追加することが出来ます。
(最初から入っている項目の削除はできません。追加のみです。)

  • DML_PEXA_000001 : Operator
  • DML_PEXA_000011 : OperatorGroup
  • DML_PEXA_920001 : WF_Request

OperatorとOperatorGroupに関しては、ユーザー情報を保持するマスタとなるため、各プロジェクトで必ず個別の項目が必要となります。
基本的にカスタマイズが前提となるデータモデルと考えて下さい。

WF_Requestに関しては、ワークフローエンジンが制御に使用する項目が最初から入っています。
それに加えて、ワークフローアプリケーションが一覧画面上などで検索する際の検索条件になるような任意の業務項目を必要であれば追加して下さい。

これらのデータモデルをカスタマイズするには、以下のフォルダ配下に格納されているモデル定義Excelシートをコピーして使用して下さい。 

    /doc/material/pexa/model
また、カスタマイズされることが前提である関係上、OpeartorおよびWF_Requestのデータモデル定義XMLファイルはPEXA配布パッケージによる強制上書きは行われません。
カスタマイズしていないファイルが必要になった場合はローカルの対象XMLファイルを一度削除してアップデートするか、手動で上書きして下さい。


ワークフロー処理の流れ

ここでは、ワークフロー処理の一連の流れの中で、アプリケーションがどのようにワークフローエンジンの機能を呼び出しながら動作するかを解説します。

ワークフロー処理は１トランザクションで処理が完結するタイプの処理ではなく、申請者および複数の承認者の間でデータを受け渡ししつつ行われます。
ここでは、この受け渡しの基本的な流れに沿った形でワークフローエンジンの機能の呼び出し順番を解説します。

  1. 申請者による承認対象の生成
  2. 申請者による申請
  3. 承認者による申請情報の取得
  4. 承認者による承認or返却or保留
また、以下のような取消系の処理についても解説します。


申請者による承認対象の生成

まず、ワークフローに流したい承認対象データを申請者が登録します。
これは、たとえば見積、受注、発注依頼、請求依頼といった、承認してもらいたい内容を含んだデータです。
この時点ではまだワークフローの処理は発生していないので通常のアプリケーションによる処理となります。

なお、この承認対象データは、申請実行前にコミットしておいたほうが無難です。
ワークフローフレームワークの仕組み上ではコミット前でも申請実行は可能ですが、
アプリケーション側でコミット処理が抜けると承認対象の本体が無いのに申請情報だけが登録された状態になります。


申請者による申請

図３：申請時の機能呼び出しイメージ

次に、申請者による申請処理を行います。
申請処理を行う際には、ワークフローエンジンの機能を２回呼び出します。

なお、ワークフローエンジンの機能を呼び出すには、サービス定義ファイルでformat_type="workflow"のプロセスを使用します。
このプロセスで呼び出したいワークフロー操作を指定することでワークフローエンジンを呼び出すことができます。
ワークフロー操作の詳細については以降の章で別途解説します。

１回目の呼び出し：ワークフロー操作「MATCHING」

申請者が申請実行画面を呼び出したタイミングで、まずワークフロー操作のMATCHINGを呼び出します。

サービス定義からの呼び出し例： 

(申請時マッチングを行う
    format_type  workflow
    (workflow
        operation  matching
        (matching
            for       request
            target    @申請対象
            requestor @LoginUserInfo
        )
    )
)
これは、承認対象データをワークフローエンジンに渡して承認対象スキーマとのマッチングを行う処理です。
これにより、適用される承認ルート、承認ポイント、提出先となる承認者の候補リストを割り出します。

このタイミングでWF_Requestデータモデル(未コミット状態)のインスタンスが生成されて、
マッチング結果が以下の現象型としてWF_Requestデータモデルにセットされて、呼び出し元に返されます。
  • WF_ExpectedRouteName：適用される承認ルート名
  • WF_ExpectedRouteStateName：適用される承認ポイント名
  • WF_ExpectedReceiverList：提出先となる承認者候補リスト
  • WF_ExpectedReceiverGroupList：提出先となる承認者グループ候補リスト
マッチング結果を保持したWF_Requestには、申請実行画面の初期化に必要な情報が含まれています。(申請先の選択ComboBoxの中身など)
そのため、MATCHINGの呼び出しは申請実行画面の初期化タイミングで行うようにしてください。


２回目の呼び出し：ワークフロー操作「REQUEST」

申請者が申請実行ボタン押下などの操作を行ったタイミングで、ワークフロー操作のREQUESTを呼び出します。

サービス定義からの呼び出し例： 

(申請を行う
    format_type  workflow
    (workflow
        operation  request
        (request
            request   @WF_Request
            target    @申請対象
            requestor @LoginUserInfo
            receiver  @申請先
        )
    )
)
これは、承認対象データ、WF_Request、申請先をワークフローエンジンに渡して申請状態を確定する処理です。
これにより、ワークフローエンジンによってWF_Requestに適用ルート、承認ポイント、申請者、受取者、操作履歴等の設定が行われてコミットされます。
また、承認ルートスキーマの内容に従って、必要があれば承認対象へのフィードバックやモデルイベント送信などを行います。

このワークフロー操作を行った結果、WF_Requestが以下のようになります。
  • WF_RouteNameが適用された承認ルート名になる
  • WF_RouteStateNameが適用された承認ポイント名になる
  • WF_RequestStatusCategoryが「REQUESTED」になる
  • WF_Receiver or WF_ReceiverGroupNoが指定された受取者の値になる



承認者による申請情報の取得

承認者が自分に回ってきた書類をかき集めるように、申請情報を表すWF_Requestを取得します。
WF_Request自体は通常のデータモデルなので、普通にService定義のsearchプロセスで検索して取得してください。

検索条件としては、

  • 承認者に直接提出された物についてはWF_Receiver
  • 承認者が所属する承認者グループについてはWF_ReceiverGroupNo
を検索条件に指定してください。

例：承認者の操作者マスタを表すセッションキーがOperatorの場合 

(申請情報を検索
    format_type  search
    (search
        source         WF_Request
        session_value  申請情報リスト
        [filter
            filter    "WF_Receiver = @Operator/OperatorNo"
            ,
            operator  or
            condition "@Operator/OperatorGroupMemberList/OperatorGroupNo is not null"
            filter    "WF_ReceiverGroupNo in @Operator/OperatorGroupMemberList/OperatorGroupNo"
        ]
    )
)


承認者による承認or返却or保留

図４：承認時の機能呼び出しイメージ

検索して取得したWF_Requestの一覧から承認したいものを選択して、承認者が承認、返却、保留の処理を実行します。
申請時と同じように、この場合にもワークフローエンジンの機能を２回呼び出します。

１回目の呼び出し：ワークフロー操作「MATCHING」

承認者が承認実行画面を呼び出したタイミングで、まずワークフロー操作のMATCHINGを呼び出します。

サービス定義からの呼び出し例： 

(承認時マッチングを行う
    format_type  workflow
    (workflow
        operation  matching
        (matching
            for       accept
            request   @WF_Request
            operator  @LoginUserInfo
        )
    )
)
これは、承認対象データをワークフローエンジンに渡して承認ルートスキーマとのマッチングを行う処理です。
これにより、次の承認ポイント、次の承認者の候補リストを割り出します。
マッチング結果は以下の現象型としてWF_Requestにセットされて、呼び出し元に返されます。
  • WF_ExpectedRouteStateName：次の承認ポイント名
  • WF_ExpectedReceiverList：次の承認者候補リスト
  • WF_ExpectedReceiverGroupList：次の承認者グループ候補リスト
マッチング結果を保持したWF_Requestには、承認実行画面の初期化に必要な情報が含まれています。(次の承認者の選択ComboBoxの中身など)
そのため、MATCHINGの呼び出しは承認実行画面の初期化タイミングで行うようにしてください。

なお、承認ルートスキーマに照らし合わせた結果、今回承認されると決裁(最終承認)されることになる場合は以下のようになります。
  • WF_RequestにセットされるWF_ExpectedRouteStateNameが固定で「APPROVED」になる。
  • 次承認者はいないのでWF_Requestに候補者リストは設定されない。


２回目の呼び出し：ワークフロー操作「ACCEPT」

承認者が申請内容を承認する場合は、ワークフロー操作のACCEPTを呼び出します。

サービス定義からの呼び出し例： 

(承認を行う
    format_type  workflow
    (workflow
        operation  accept
        (accept
            request   @WF_Request
            operator  @LoginUserInfo
            receiver  @次の承認者 ;; 最終承認時はnull
        )
    )
)
これは、承認対象データ、WF_Request、次の承認者をワークフローエンジンに渡して承認状態を確定する処理です。
これにより、ワークフローエンジンによってWF_Requestに遷移先の承認ポイント、次の受取者、操作履歴等の設定が行われてコミットされます。
また、承認ルートスキーマの内容に従って、必要があれば承認対象へのフィードバックやモデルイベント送信などを行います。

このワークフロー操作を行った結果、通常承認の場合はWF_Requestが以下のようになります。
  • WF_RouteStateNameが遷移先の承認ポイント名になる
  • WF_Receiver or WF_ReceiverGroupNoが指定された受取者の値になる
このワークフロー操作を行った結果、決裁(最終承認)された場合はWF_Requestが以下のようになります。
  • WF_RouteStateNameが「APPROVED」になる
  • WF_RequestStatusCategoryが「APPROVED」になる
  • WF_ReceiverとWF_ReceiverGroupNoがnullになる


２回目の呼び出し：ワークフロー操作「REJECT」

承認者が申請内容を否決する場合は、ワークフロー操作のREJECTを呼び出します。

サービス定義からの呼び出し例： 

(返却を行う
    format_type  workflow
    (workflow
        operation  reject
        (reject
            request   @WF_Request
            operator  @LoginUserInfo
        )
    )
)
これは、WF_Requestをワークフローエンジンに渡して、申請内容を否決して申請者に返却する処理です。
これにより、ワークフローエンジンによってWF_Requestの状態や操作履歴等の設定が行われてコミットされます。
また、承認ルートスキーマの内容に従って、必要があれば承認対象へのフィードバックやモデルイベント送信などを行います。

このワークフロー操作を行った結果、WF_Requestが以下のようになります。
  • WF_RouteStateNameが「REJECTED」になる
  • WF_RequestStatusCategoryが「REJECTED」になる
  • WF_ReceiverとWF_ReceiverGroupNoがnullになる


２回目の呼び出し：ワークフロー操作「SUSPEND」

承認者が申請内容を保留扱いにする場合は、ワークフロー操作のSUSPENDを呼び出します。

サービス定義からの呼び出し例： 

(保留にする
    format_type  workflow
    (workflow
        operation  suspend
        (suspend
            request   @WF_Request
            operator  @LoginUserInfo
        )
    )
)
これは、WF_Requestをワークフローエンジンに渡して、申請内容を保留状態にする処理です。
これにより、ワークフローエンジンによってWF_Requestの状態や操作履歴等の設定が行われてコミットされます。
また、承認ルートスキーマの内容に従って、必要があれば承認対象へのフィードバックやモデルイベント送信などを行います。

このワークフロー操作を行った結果、WF_Requestが以下のようになります。
  • WF_RequestStatusCategoryが「SUSPENDED」になる



申請者による申請取下

申請者による申請取下は、ワークフロー操作のUNREQUESTを呼び出します。

サービス定義からの呼び出し例： 

(申請を取り下げる
    format_type  workflow
    (workflow
        operation  unrequest
        (unrequest
            request   @WF_Request
            operator  @LoginUserInfo
        )
    )
)
WF_Requestデータモデルには、申請者を表すWF_Requestorという現象型があります。
この項目を検索条件に指定して申請者が申請したWF_Requestを検索し、その中から取り下げたい対象を選択します。
選択されたWF_Requestをワークフロー操作のUNREQUESTに渡すことで申請取下を行うことができます。

このワークフロー操作を行った結果、WF_Requestが以下のようになります。
  • WF_RouteStateNameが「UNREQUESTED」になる
  • WF_RequestStatusCategoryが「NOT_REQUESTED」になる
  • WF_ReceiverとWF_ReceiverGroupNoがnullになる


承認者による承認取消

承認者による承認取消は、ワークフロー操作のUNACCEPTを呼び出します。

サービス定義からの呼び出し例： 

(申請を取り下げる
    format_type  workflow
    (workflow
        operation  unaccept
        (unaccept
            request   @WF_Request
            operator  @LoginUserInfo
        )
    )
)
この承認取消は、直近の操作者のみが実行することができます。
そのため、間違って承認してしまった場合などにすぐ行えば問題ありませんが、 次の承認者によって承認されてしまって何段階か先の承認ポイントに進んでしまった場合は取消はできません。
WF_Requestデータモデルには、直近の操作者を表すWF_LastOperatorという現象型があります。
この項目を検索条件に指定して、承認者が承認したWF_Requestを検索し、その中から取消したい対象を選択します。
選択されたWF_Requestをワークフロー操作のUNACCEPTに渡すことで承認取消を行うことができます。

このワークフロー操作を行った結果、WF_Requestが以下のようになります。
  • WF_RouteStateNameが承認前の値になる
  • WF_ReceiverとWF_ReceiverGroupNoが承認前の値になる
また、最終承認の取消の場合は、上記に加えて承認ルートスキーマ中のunapprove条件に合致している必要があります。
条件に合致して最終承認の取り消しができた場合は、WF_Requestが以下のようになります。
  • WF_RouteStateNameが承認前の値になる
  • WF_RequestStatusCategoryが「REQUESTED」になる
  • WF_ReceiverとWF_ReceiverGroupNoが承認前の値になる


承認者による保留解除

承認者による保留解除は、ワークフロー操作のUNSUSPENDを呼び出します。

サービス定義からの呼び出し例： 

(保留解除する
    format_type  workflow
    (workflow
        operation  unsuspend
        (unsuspend
            request   @WF_Request
            operator  @LoginUserInfo
        )
    )
)
この保留解除は、保留状態にした承認者のみが実行することができます。
それ以外の承認者による取消はできません。
WF_Requestデータモデルには、直近の操作者を表すWF_LastOperatorという現象型があります。
この項目を検索条件に指定して、承認者が保留したWF_Requestを検索し、その中から取消したい対象を選択します。
選択されたWF_Requestをワークフロー操作のUNSUSPENDに渡すことで承認取消を行うことができます。

このワークフロー操作を行った結果、WF_Requestが以下のようになります。
  • WF_RequestStatusCategoryが「REQUESTED」になる


ワークフローイベント

承認ルートに承認対象が出入することにより、ワークフローエンジン内部でワークフローイベントが発生します。
このワークフローイベント発生時に、承認対象に対するフィードバック処理やモデルイベント送信を行うことができます。

以下で、ワークフローイベントの種類とその発生時に実行できる処理について説明します。

イベントの種類

ワークフローイベントは、ワークフロー操作によって承認対象が承認ルートを出入するタイミングに発生します。
以下がその一覧表になります。

ワークフローイベント名 説明 ワークフロー操作 WF_RequestStatusCategoryの状態変化
REQUESTED 申請者が申請を行った時に発生するイベントです。 REQUEST NOT_REQUESTED --> REQUESTED
UNREQUESTED 申請者が申請を取り下げた時に発生するイベントです。 UNREQUEST REQUESTED --> NOT_REQUESTED
APPROVED 承認対象が決裁(最終承認)された時に発生するイベントです。 ACCEPT REQUESTED --> APPROVED
UNAPPROVED 承認対象の最終承認が取り消された時に発生するイベントです。 UNACCEPT APPROVED --> REQUESTED
REJECTED 承認対象が返却された時に発生するイベントです。 REJECT REQUESTED --> REJECTED
SUSPENDED 承認対象が保留された時に発生するイベントです。 SUSPEND REQUESTED --> SUSPENDED
UNSUSPENDED 承認対象が保留解除された時に発生するイベントです。 UNSUSPEND SUSPENDED --> REQUESTED

フィードバック

ワークフローイベント発生時に、承認対象データモデルに対するフィードバック処理を行うことができます。
例えば、APPROVEDイベント発生時(最終承認された)に承認対象データモデルの最終承認済フラグをONにするといったことができます。

フィードバック処理の指定は、承認ルートスキーマのfeedbackセクションで記述します。

記述例 

(feedback
    ;;--------------------------------------------
    ;; 最終承認(REQUESTED -> APPROVED)
    ;;--------------------------------------------
    (APPROVED
        commit    false
        (mapping
            最終承認済フラグ  最終承認済
        )
    )
    ;;--------------------------------------------
    ;; 最終承認取消(APPROVED -> REQUESTED)
    ;;--------------------------------------------
    (UNAPPROVED
        commit    true
        (mapping
            最終承認済フラグ  未承認
        )
    )
)
各ワークフローイベント発生時に、どの項目を編集するかとコミットを行うかなどを指定します。
また、承認対象データモデルの明細に対するフィードバックも指定できます。明細の明細もネストして記述することで指定可能です。
詳細は承認ルートスキーマのリファレンスを参照してください。

ここで右辺側に指定できるセッションキーは以下の物があります。

セッションキー名 説明
WF_Receiver 申請先として指定されたOperatorモデル。
WF_ReceiverGroup 申請先として指定されたOperatorGroupモデル。
WF_Request WF_Requestモデルを表す。
WF_Target 承認対象モデルを表す。
WF_Operator ワークフロー操作を実行した操作者を表すOperatorモデル。

モデルイベント

ワークフローイベント発生時に、モデルイベントを送信してサービスを呼び出すことができます。
例えば、APPROVEDイベント発生時(最終承認された)に承認対象データモデルに関するAET処理を実行するといったことができます。

モデルイベント送信処理の指定は、承認ルートスキーマのsendセクションで記述します。

記述例 

(send
    ;;--------------------------------------------
    ;; 最終承認(REQUESTED -> APPROVED)
    ;;--------------------------------------------
    (APPROVED
        table_name	"見積モデルイベントテーブル"
        unsync      false ;;同期実行
    )
    ;;--------------------------------------------
    ;; 最終承認取消(APPROVED -> REQUESTED)
    ;;--------------------------------------------
    (UNAPPROVED
        table_name	"見積モデルイベントテーブル"
        unsync      true ;;非同期実行
    )
)
各ワークフローイベント発生時に、送信先のイベントテーブル名や同期、非同期などを指定します。
詳細は承認ルートスキーマのリファレンスを参照してください。



承認権限管理

ワークフローフレームワークでは、標準の権限管理マスタとそれを前提とした承認権限保持者の抽出機能および権限委譲機能があります。

これらを併せて承認権限管理機能として提供しています。
この機能は、ワークフロー操作のMATCHING実行時にワークフローエンジンから呼び出されます。
呼び出された結果として抽出された承認者、承認グループの候補リストはWF_Requestの以下の現象型に設定されます。

  • WF_ExpectedReceiverList：承認権限を持つ操作者モデル(Operator)の一覧
  • WF_ExpectedReceiverGroupList：承認権限を持つ操作者グループモデル(OperatorGroup)の一覧
承認ルートスキーマ中の承認ポイントで標準の権限管理機能を利用するか独自の仕組みを呼び出すかが指定できます。
この標準のマスタおよび機能を利用してもよいですし、独自の権限管理の方式を用意してそれを呼び出すことも可能です。
以降で標準機能の呼び出し、独自の仕組みの呼び出し、および権限委譲についてそれぞれ説明します。

なお、標準の権限管理マスタについてはデータモデル構成の項を参照してください。

標準の権限管理機能を使用する場合

標準の権限管理機能は、ワークフローフレームワークが標準提供しているマスタを前提として動作します。

標準マスタによって操作者(Operator)や操作者グループ(OperatorGroup)と承認ポイント(WF_AcceptPoint)が関連付けされていると、
承認ルートスキーマで以下のように記述してあればMATCHING実行時に承認権限保持者が抽出されます。 

(state_chart
    ;;--------------------------------------------
    ;; 経理承認待ち
    ;;--------------------------------------------
    (経理承認待ち
        (receiver
            finder  "common" ;; 標準の抽出機能を使用
        )
        (receiver_group
            finder  "common" ;; 標準の抽出機能を使用
        )
        (operation
            (ACCEPT
                (state_matching
                    state   役員承認待ち
                )
            )
        )
    )
)
上記のようにreceiverセクションやreceiver_groupセクションのfinderオプションで"common"と指定すると、 標準のマスタから権限保持者を抽出します。


独自の権限管理を行う場合

独自の権限管理を行う場合は、OperatorやOperatorGroupを抽出する処理を行うサービスを承認ルートスキーマ中で指定します。 

(state_chart
    ;;--------------------------------------------
    ;; 経理承認待ち
    ;;--------------------------------------------
    (経理承認待ち
        (receiver
            finder  "original" ;; 独自の抽出機能を使用
            (original
                service       "SSR.ワークフロー権限保持者を抽出する"
                (return_keys   
                    WF_ExpectedReceiverList    @権限保持者リスト
                )
            )
        )
        (receiver_group
            finder  "original" ;; 独自の抽出機能を使用
            (original
                service       "SSR.ワークフロー権限保持者グループを抽出する"
                (return_keys   
                    WF_ExpectedReceiverGroupList    @権限保持者グループリスト
                )
            )
        )
        (operation
            (ACCEPT
                (state_matching
                    state   役員承認待ち
                )
            )
        )
    )
)
上記のようにreceiverセクションやreceiver_groupセクションのfinderオプションで"original"と指定し、
さらに内部にoriginalセクションを記述して呼び出したいサービスを指定します。

このoriginalセクション内部の構成はサービス定義のcallプロセスと同じです。
呼び出し結果として受け取るべきセッションキー名は上記の例のとおり現象型名と同一です。


絞込フィルタ

receiverセクションやreceiver_groupセクションのfilterオプションで絞り込みを行うためのセッションフィルタ式を指定できます。
これは、マスタの内容から抽出した権限保持者に対してさらに絞り込みを行うためのものです。

例えば、部門長承認待ちという承認ポイントに参加できる承認者が多数いるが、実際には申請者と同じ部門の人のみにしたいケースなどです。

(state_chart
    ;;--------------------------------------------
    ;; 部門長承認待ち
    ;;--------------------------------------------
    (部門長承認待ち
        (receiver
            finder  "common" ;; 標準の抽出機能を使用
            filter  "@WF_Target/申請時部署No in @WF_Receiver/部署List/部署No"
        )
        (operation
            (ACCEPT
                (state_matching
                    state   経理承認待ち
                )
            )
        )
    )
)
この絞込フィルタはセッションフィルタ式なので、左辺もしくは右辺のどちらかにWF_Receiver/WF_ReceiverGroupを指定して比較することになります。
セッションフィルタ式になっている理由は、in条件での比較などの場合にWF_Receiver/WF_ReceiverGroupが右辺側にくることがあるからです。
フィルタ式中で指定できるセッションキーは以下になります。

セッションキー名 説明
WF_Receiver receiverセクション側で指定できるセッションキー。マスタから抽出された権限保持者Operatorモデルを表す。
WF_ReceiverGroup receiver_groupセクション側で指定できるセッションキー。マスタから抽出された権限保持OperatorGroupモデルを表す。
WF_Request WF_Requestモデルを表す。
WF_Target 承認対象モデルを表す。
WF_Operator ワークフロー操作のMATCHINGを実行した操作者を表すOperatorモデル。

権限委譲

ワークフローフレームワークが標準提供するWF_Delegationモデルを使用することで、
ワークフロー操作のMATCHING実行時に行われる権限保持者の抽出結果に権限委譲を反映することができます。

WF_Delegationモデルには権限の委譲元、委譲先、有効期間などが記録されます。
WF_Delegationモデル自体は普通のデータモデルなので、登録は通常のアプリケーション処理として行ってください。

権限保持者の抽出は以下の３段階で実行されます。

  1. commonまたはoriginalの抽出処理
  2. filterによる絞込
  3. 権限委譲情報の反映
例：
抽出と絞込の結果が「A氏」、「B氏」、「C氏」の場合権限委譲情報に
  • 委譲元：「B氏」
  • 委譲先：「Y氏」
と設定されている場合、MATCHING実行時のWF_ExcpectedReceiverListは「A氏」、「Y氏」、「C氏」となる。

また、すでに申請済みの承認対象の受取者を、WF_Delegationの情報に従って付け替えることができます。
これは、以下のワークフロー操作を呼び出すことで実行できます。

  • DELEGATE：受取者の付け替えを実行する
  • UNDELEGATE：受取者の付け替え解除を実行する
このワークフロー操作を使用するかどうかは任意です。使用すると申請済みの物に権限委譲の情報を反映することになりますので、
「一度提出された物は受け取った物が処理すべし」というポリシーで運用するような仕様になる場合は使うべきではありません。
実行すべきかどうかは個々のプロジェクト毎の仕様として決めてください。



更新情報

  • 最終更新者 : $Author: kimura $
  • 最終更新日時 : $Date:: 2014-11-10 08:54:57 #$
  • バージョン : $Revision: 7828 $
Copyright © 2006, Atrris Corporation