Hitachi

uCosminexus Service Coordinator Interactive Workflow システム構築・運用ガイド


2.5.2 案件の動的な制御

案件は,基本的にビジネスプロセス定義に従って処理されていきます。一方,ビジネスプロセス定義に記述されている内容とは別に,案件の処理を動的に制御することもできます。案件処理に対する動的な制御は,ワーク管理システムで提供されているAPIを利用した業務プログラムから実行します。ワーク管理システムのAPIについては,マニュアル「uCosminexus Service Coordinator Interactive Workflow AP開発ガイド」を参照してください。

〈この項の構成〉

(1) 引き戻しと差し戻し

現在実行中の業務ステップから,すでに完了した業務ステップに案件処理を戻し,その時点から案件処理をし直せます。これによって,案件の「引き戻し」や「差し戻し」といった処理を実現できます。

(a) 引き戻し

引き戻し処理では,現在実行中の業務ステップを検索し,引き戻し先の業務ステップに案件処理を戻します。

引き戻し処理の流れを次の図に示します。

図2‒25 引き戻し処理の流れ

[図データ]

<説明>
  1. ユーザ(業務プログラム)は,引き戻し対象となる現在実行中の業務ステップを検索します。その情報を基に,引き戻し元の業務ステップ(現在実行中の業務ステップ)と引き戻し先の業務ステップを指定し,CSCIWに引き戻し処理を要求します。

  2. CSCIWは,ユーザ(業務プログラム)からの要求によって,引き戻し元の業務ステップを「強制終了」状態にし,引き戻し先の業務ステップを新しく生成して「実行中」状態にします。

    このときCSCIWは,引き戻し先と引き戻し元の間にある業務ステップの状態を変更しません。また,引き戻し以前の処理によって更新された業務データの値も変更しません。これらの変更が必要な場合は,業務プログラム側で処理します。

  3. 引き戻し先の業務ステップでの処理およびそのあとの処理は,ビジネスプロセス定義に従って実行されます。

(b) 差し戻し

差し戻し処理では,すでに完了した業務ステップを検索して差し戻し先を決定し,現在実行中の業務ステップから差し戻し先の業務ステップに案件処理を戻します。

差し戻し処理の流れを次の図に示します。

図2‒26 差し戻し処理の流れ

[図データ]

<説明>
  1. ユーザ(業務プログラム)は,すでに完了した業務ステップを検索し,差し戻し先となる業務ステップを選択します。その情報を基に,差し戻し元の業務ステップ(現在実行中の業務ステップ)と差し戻し先の業務ステップを指定し,CSCIWに差し戻し処理を要求します。

  2. CSCIWは,ユーザ(業務プログラム)からの要求によって,差し戻し元の業務ステップを「強制終了」状態にし,差し戻し先の業務ステップを新しく生成して「実行中」状態にします。

    このときCSCIWは,差し戻し先と差し戻し元の間にある業務ステップの状態を変更しません。また,差し戻し以前の処理によって更新された業務データの値も変更しません。これらの変更が必要な場合は,業務プログラム側で処理してください。

  3. 差し戻し先の業務ステップでの処理およびそのあとの処理は,ビジネスプロセス定義に従って実行されます。

(c) 引き戻しおよび差し戻しに関する注意事項

引き戻し元と引き戻し先との間,または差し戻し元と差し戻し先との間に制御ノードが含まれる場合,次に示すどちらかの形態に合致している必要があります。

●形態1

引き戻し元と引き戻し先との間,または差し戻し元と差し戻し先との間に含まれる部分(以降,巡回部分と呼ぶ)が,次に示す条件をすべて満たしている形態。

  • 巡回部分での遷移は,必ず,引き戻し先または差し戻し先の業務ステップから始まり,引き戻し元または差し戻し元の業務ステップで終了する。

  • 引き戻し元または差し戻し元への遷移時は,巡回部分内のすべての待合ノードが「待合中」状態でなく,かつ巡回部分内のすべての業務ステップが「実行中」状態でない。

  • 巡回部分内のすべての先着ノードには,後続停止が設定されていない。

●形態2

巡回部分に,「業務ステップ」または「後続停止が設定されていない先着ノード」だけが含まれる形態。

上記の形態でない場合,引き戻しまたは差し戻しが正しく動作しないおそれがあります。

引き戻しまたは差し戻しが正しく動作する例,および正しく動作しない例を,それぞれ次の図に示します。

図2‒27 引き戻しまたは差し戻しが正しく動作する例

[図データ]

図2‒28 引き戻しまたは差し戻しが正しく動作しない例

[図データ]

(2) 業務ステップおよび作業の評価要求

実行中の業務ステップおよびその業務ステップに含まれる各作業のデータ条件を,任意のタイミングで評価できます。

(a) 業務ステップの評価要求

業務ステップの評価要求のタイミングは,業務ステップの条件を評価するAPIが発行された時点です。

業務ステップの評価要求を実行したときの処理の順序を次の図に示します。

図2‒29 業務ステップの評価要求を実行したときの処理の順序

[図データ]

<説明>
  1. 業務ステップの完了条件を評価します。

    完了条件が成立した場合,業務ステップが完了し,案件は次に遷移します。

    完了条件が成立しない場合,2.の処理に進みます。

  2. 業務ステップに属する作業のうち,未発生の作業または条件再評価フラグが設定されていて,かつ完了状態にある作業の発生条件を評価します。

    一つも発生条件が成立しない場合,終了します。

    1つ以上の発生条件が成立した場合,3.の処理に進みます。

  3. 発生した作業の完了条件を評価します。

    一つも発生した作業の完了条件が成立しない場合,発生した作業は未実行の状態で終了します。

    1つ以上の発生した作業の完了条件が成立し,かつ業務ステップ内に完了していない作業がある場合,完了条件が成立した作業は終了状態となり,終了します。

    1つ以上の発生した作業の完了条件が成立し,かつ業務ステップ内のすべての作業が完了した場合,業務ステップが完了し,案件は次に遷移します。

(b) 作業の評価要求

作業の評価要求のタイミングは,作業の条件を評価するAPIが発行された時点です。

作業の評価要求を実行したときの処理の順序を次の図に示します。

図2‒30 作業の評価要求を実行したときの処理の順序

[図データ]

<説明>
  1. 作業の完了条件を評価します。

    完了条件が成立した場合,作業は完了状態となり,2.の処理に進みます。

    完了条件が成立しなかった場合,終了します。

  2. 業務ステップの完了条件を評価します。

    処理内容は,「2.5.2(2)(a) 業務ステップの評価要求」の図2-29の<説明>1.の処理になります。

(3) 案件の遷移依頼

案件の遷移依頼処理では,現在実行中の業務ステップを完了し,次の業務ステップを開始します。

案件の遷移依頼の流れを次の図に示します。

図2‒31 案件の遷移依頼の流れ

[図データ]

<説明>
  1. ユーザ(業務プログラム)は,現在実行中の業務ステップを終了し,次の業務ステップを開始するようCSCIWに要求します。

  2. ユーザ(業務プログラム)からの要求によって,CSCIWは,現在実行中の業務ステップを「完了」の状態にし,次の業務ステップを「実行中」の状態にします。

(4) アドホックAPIによる業務ステップの生成依頼と遷移依頼

アドホックAPIを使用して,業務ステップの生成と遷移を動的に制御できます。

(a) 生成依頼

アドホックAPIによる業務ステップの生成依頼処理では,ビジネスプロセスで定義されている任意の業務ステップを動的に生成できます。業務ステップは,「初期」状態で生成されます。

アドホックAPIによる業務ステップの生成依頼を次の図に示します。

図2‒32 アドホックAPIによる業務ステップの生成依頼

[図データ]

<説明>
  1. ユーザ(業務プログラム)は,動的に業務ステップを生成するようCSCIWに要求します。

  2. ユーザ(業務プログラム)からの要求によって,CSCIWは,指定された業務ステップを生成します。生成した業務ステップの状態は「初期」です。

(b) 遷移依頼

アドホックAPIによる遷移依頼処理では,現在実行中の業務ステップを完了し,遷移定義とは関係なく任意の「初期」状態の業務ステップを開始します。

アドホックAPIによる業務ステップの遷移依頼を次の図に示します。

図2‒33 アドホックAPIによる業務ステップの遷移依頼

[図データ]

<説明>
  1. ユーザ(業務プログラム)は,現在実行中の業務ステップを終了し,「初期」状態の指定の業務ステップを開始するようCSCIWに要求します。

  2. ユーザ(業務プログラム)からの要求によって,CSCIWは,現在実行中の業務ステップを「完了」の状態にし,指定された業務ステップを「実行中」の状態にします。通常の業務ステップの完了と異なり,次の業務ステップ(業務ステップ3)には遷移しないで,指定した業務ステップ(業務ステップ4)に遷移します。

(5) 条件に一致する作業の作業者割り当てと着手

指定された条件に一致する作業群から,ある1つの作業を取得し,作業者を割り当てて着手できます。また,割り当てた作業の返却と振り分けルールの再評価もできます。

(a) 条件に一致する作業の作業者割り当てと着手の処理の流れ

条件に一致する作業の作業者割り当てと着手の処理の流れを次の図に示します。

図2‒34 条件に一致する作業の作業者割り当てと着手の処理の流れ

[図データ]

<説明>
  1. ユーザ(業務プログラム)は,割り当てる作業者名と条件(割り当て元の作業者名や開始日)を指定して,CSCIWに「条件に一致する作業の作業者割り当て」を要求します。

  2. ユーザ(業務プログラム)からの要求によって,CSCIWは対象となる作業群(指定された条件と「実行開始可能」状態の両方を満たす作業)を検索します。条件に一致する作業の1つを「作業者実行」状態に変更し,作業者を指定された作業者名に変更します。

    変更に失敗した場合は,検索した作業群から別の作業を取得して変更を試みます。変更に成功するか,または対象の作業が存在しなくなるまで,作業の取得と変更を続けます。

    変更が完了した作業を,ユーザ(業務プログラム)に返します。

(b) 作業の返却と振り分けルールの再評価の処理の流れ

作業の返却と振り分けルールの再評価の処理は次の流れで実行します。

<説明>
  1. ユーザ(業務プログラム)は,条件に一致する作業の作業者割り当てと着手の処理によって作業を取得します。

  2. ユーザ(業務プログラム)は,CSCIWに「作業の返却と振り分けルールの再評価」を要求します。

  3. ユーザ(業務プログラム)からの要求によって,CSCIWは対象の作業を「作業者実行」状態から「実行開始可能」状態に変更し,振り分けルールを再評価します。

(c) 条件に一致する作業の作業者割り当てに関する注意事項

条件に一致する作業の作業者割り当てに関する注意事項を次に示します。

  • 「条件に一致する作業の作業者割り当て」を実行した直後に,トランザクションをコミットしてください。また,トランザクションをコミットする前に,業務テーブルの更新を実行しないでください。

  • 「作業の返却と振り分けルールの再評価」を実行する作業には,「条件に一致する作業の作業者割り当て」で取得した作業を指定してください。