ワークIDの形式は，ビジネスプロセスごとに指定します。

ビジネスプロセス定義でワークIDの形式を指定するときの注意事項について次に示します。

(a)　ワークIDの形式

ビジネスプロセス定義で指定できるワークIDの形式には，次の3通りがあります。

• ユーザ指定の形式でシステムが通し番号を自動的に与える（ここでは，「自動採番形式」と略します）。
• ワークフローシステムで与える（ここでは，「自動付与形式」と略します）。
• 案件投入時にユーザが任意の文字列を指定する（ここでは，「任意指定形式」と略します）。

次に，それぞれの形式について説明します。

自動採番形式

ユーザがビジネスプロセス定義で指定したプレフィックス（任意の文字列）に，システムが通し番号を与えてワークIDが生成されます。プレフィックスの指定は省略できます。

通し番号は，案件投入時にワークが生成されるごとに１から昇順で与えられ，ビジネスプロセス定義のバージョンアップによって引き継がれます。

システムが与える通し番号の規則として，次の3通りを指定できます。

• 通し番号が指定されたけた数を超えた場合，通し番号のけた数を拡張する。
• 通し番号が指定されたけた数を超えた場合，通し番号を１に戻す。
• 通し番号が指定された最大値を超えた場合，通し番号を１に戻す。

自動付与形式

案件投入時に，ビジネスプロセス定義内でユニークなワークIDがワークフローシステムによって生成されます。

なお，この形式を使用する場合，Groupmax Workflow Server - Libraryでアプリケーションを作成する場合を除いて，ワークIDをクライアントで扱うことはできません。

任意指定形式

案件投入時に，ユーザが任意の文字列を指定します。ビジネスプロセス定義内でユニークなワークIDを指定する必要があります。

(b)　ビジネスプロセス定義登録時の注意事項

ビジネスプロセス定義登録時の注意事項を次に示します。

• 通し番号の規則として，「通し番号が指定されたけた数を超えた場合，通し番号を１に戻す」又は「通し番号が指定された最大値を超えた場合，通し番号を１に戻す」を指定した自動採番形式を指定するときは，次に示すことに注意してください。
  
  • 通し番号が指定されたけた数又は指定された最大値を超えて１に戻され，ワークIDが生成されたとき，以前に投入した案件が削除されないで残っていると，ワークIDが重複します。その場合，案件投入でエラーとなります。このため，ワークが削除されるまでの期間を十分に考慮して，ワークIDの重複が起きないように，以下の見積もりを参考にして余裕を持って最大値を設定してください。
    1日当たりの投入案件数×（投入してから終了（シンク）するまでの最大日数＋終了してからワークを削除するまでの日数＋1）
    
  • 案件投入でワークID重複のエラーが発生した場合，バージョンが03-00以前のクライアントでは，「エラー種別（10630）のメッセージが取得できませんでした。」というメッセージが表示されます。上記の指定をする場合，バージョンが05-00以降のクライアントを使用することをお勧めします。
• ビジネスプロセス定義をバージョンアップするときは，次に示すことに注意してください。
  
  • 通し番号の規則として「通し番号が指定されたけた数を超えた場合，通し番号を１に戻す」又は「通し番号が指定された最大値を超えた場合，通し番号を１に戻す」を指定した自動採番形式のビジネスプロセス定義を，自動付与形式又は任意指定形式に変更できません。
  • 自動付与形式又は任意指定形式を指定したビジネスプロセス定義を，通し番号の規則として「通し番号が指定されたけた数を超えた場合，通し番号を１に戻す」又は「通し番号が指定された最大値を超えた場合，通し番号を１に戻す」を指定した自動採番形式に変更できません。
    上記の変更処理を実行したい場合は，変更前のビジネスプロセス定義を削除した後に，変更後のビジネスプロセス定義を登録してください。
    
• 自動採番形式で指定した最大値は，案件を投入できるビジネスプロセス定義のバージョンの中の，最新バージョンでの指定が有効となります。

ビジネスプロセス定義で，各フローモデルを使用する場合の注意事項を説明します。

(a)　ソースノード

複数ケースを定義したソースノードへの差し戻し，引き戻しはできません。詳細については，「3.9.5(1) 差し戻し」又は「3.9.5(2) 引き戻し」を参照してください。

「ワークIDを新規に設定しない」を指定したソースノードから案件投入するには，「ワークIDを新規に設定する」を指定したソースノードから案件を投入している必要があります。また，「ワークIDを新規に設定する」を指定したソースノードから案件を投入した後，「ワークIDを新規に設定しない」を指定したソースノードから案件投入するまでにビジネスプロセス定義をバージョンアップすると，「ワークIDを新規に設定しない」を指定したソースノードからの案件投入が失敗する場合があります。このため，ビジネスプロセス定義をバージョンアップする際は，Groupmax Workflow Monitorで「ワークIDを新規に設定しない」を指定したソースノードから案件投入されていることを確認してください。

(b)　複写ノード

複写後から複写前への差し戻し，引き戻しはできません。詳細については，「3.9.5(1) 差し戻し」又は「3.9.5(2) 引き戻し」を参照してください。

(c)　待ち合わせノード

待ち合わせ後から待ち合わせ前への差し戻し，引き戻しはできません。詳細については，「3.9.5(1) 差し戻し」又は「3.9.5(2) 引き戻し」を参照してください。

(d)　同報・回収ノード

• Groupmax Formを使用する場合，同報・回収は使用できません。詳細については，「3.9.6(1) ビジネスプロセス定義作成時の注意事項」を参照してください。
• 同報中に追加された文書やメモは，そのケースを操作するユーザだけがアクセスできます。その他の同報されているケースを操作するユーザは，アクセスできません。
• 同報ノード又は回収ノードをまたがった差し戻し，引き戻しはできません。詳細については，「3.9.5(1) 差し戻し」又は「3.9.5(2) 引き戻し」を参照してください。
• 同報中の案件の文書やメモは，その案件が流れているビジネスプロセス定義の登録サーバに置いて共用され，案件を開いたときや，保留したとき，遷移させたときに，登録サーバからダウンロード又はアップロードされます。このため，案件を操作するユーザのホームサーバが登録サーバと異なる場合は，案件操作時に時間がかかる場合があります。

(e)　統合ノード

• 統合後から統合前への差し戻し，引き戻しはできません。詳細については，「3.9.5(1) 差し戻し」又は「3.9.5(2) 引き戻し」を参照してください。
• Groupmax Formを使用する場合，統合ノードの定義で「メモと文書の統合」の「統合先ケースに添付されているメモと文書だけを残す」を指定して，統合後に残るケースの添付情報を参照するようにしてください。詳細については，「3.9.6(1) ビジネスプロセス定義作成時の注意事項」を参照してください。
• ドメイン間連携機能の連携先のビジネスプロセス定義に使用した場合，ソースノード定義したケースを統合元ケースに指定すると，ドメイン間連携機能により投入された案件が遷移エラーになります。ドメイン間連携機能を使用する場合は，統合先ケースに指定してください。
• 本文メモが添付されていないケースを含む場合，統合後の作業机で終端の本文メモを参照できるようにするために，内部的に空の本文メモを補完した上で統合処理をすることがあります。
• 統合前の各ケースの添付情報（文書やメモ情報）は，削除されないで統合後に残るケースに移されます。このため，統合を繰り返すようなフローを使用すると添付情報が増え続けることになりますので，注意してください。このような場合，統合ノードの定義で「メモと文書の統合」に「統合先ケースに添付されているメモと文書だけを残す」を指定して使用するか，又は分割ノード及びシンクノードを使用して，不要になったケースを削除することをお勧めします。

(f)　分割ノード

分割後から分割前への差し戻し，引き戻しはできません。詳細は，「3.9.5(1) 差し戻し」「3.9.5(2) 引き戻し」を参照してください。

(g)　処理ノードで処理できる案件の大きさ

ソースノードでケースを複数個定義したり，複写した案件を待ち合わせノードで待ち合わせたりすると，1案件中に複数のケースが存在することになります。このケース数が多くなると，ワークフローで処理できる通信データ長を超え，正常に処理できなくなる場合があります。案件に添付されたデータ量にもよりますが，1案件中のケース数の上限は50個程度を目安にしてください。50個以上になる場合は，処理ノードに到着する前に分割ノードで不要なケースを分割して終了させてください。

処理ノードにロールを割り当てる場合の注意事項を説明します。

• ロールトレー配布の場合，マルチサーバ構成では振り替えに制限があります。詳細については，「3.9.5(5) 振り替え」を参照してください。
• 組織ロールを使用すると，組織変更に影響があります。詳細については，「3.9.2 ユーザ，ロールの登録内容の変更」を参照してください。

ユーザ処理リストでは，案件作業用の各種の情報を定義します。定義する情報は，どのように処理されるかによって，次のように分類できます。

• Groupmax Workflow Serverが自動的に処理するもの
• Groupmax Integrated Desktopをクライアントで使用する場合に，Groupmax Integrated Desktopが自動的に処理するもの
• Groupmax Workflow - Libraryで作成したアプリケーションプログラムをクライアントで使用する場合に，アプリケーションが処理するようにコーディングする必要があるもの
• Groupmax Formをクライアントで使用する場合に，Groupmax Formが自動的に処理するもの，及びスクリプトで処理を定義する必要があるもの

Groupmax Workflow Definerでのユーザ処理リストの定義内容と対応する処理方法を，表3-2に示します。

表3-2　ユーザ処理リストの定義内容と対応する処理方法

ユーザ処理リストの定義内容	対応する処理方法
属性値の直接入力 属性値の選択更新 属性値の参照	Groupmax Integrated Desktopの場合。案件エディタでユーザ属性を参照・設定します。 アプリケーションやGroupmax Formの場合，ユーザ属性を操作するときに，これらのユーザ処理リストが必要です。
予約値の自動設定	Groupmax Workflow Serverが処理します。
文書の登録	アプリケーション用の補助情報です。 Groupmax Integrated Desktop及びGroupmax Formの場合は，使用しません。
複写先選択	Groupmax Integrated Desktopの場合，案件エディタで複写先選択ができるようになります。 アプリケーションの場合，複写先情報を作成し，指定された属性に設定する必要があります。 Groupmax Formの場合，投入・遷移時にこのユーザ処理リストがあれば，自動的に画面を表示させることができます。
作業者の指定	Groupmax Integrated Desktopの場合，案件エディタで作業者指定ができるようになります。 アプリケーションの場合，作業者を選択し，指定された属性に設定する必要があります。 Groupmax Formの場合，投入・遷移時にこのユーザ処理リストがあれば，自動的に作業者指定画面を表示させることができます。
作業者の自動指定	Groupmax Workflow Serverが処理します。
配布先ロールの指定	Groupmax Integrated Desktopの場合，案件エディタで配布キー指定ができるようになります。 アプリケーション及びGroupmax Formの場合，配布キーを取得し，該当する属性に設定する必要があります。
任意データの参照	アプリケーション用の補助情報です。 Groupmax Integrated Desktop及びGroupmax Formの場合は，使用しません。
AP起動 Groupmaxフォーム表示	Groupmax Integrated DesktopのINBOXや帳票棚を使用する場合，Groupmax Integrated Desktopが登録ファイルをダウンロードして起動します。 アプリケーションでINBOXや帳票棚を作成する場合，登録ファイルを取得し，起動処理・終了確認処理などを作成する必要があります。アプリケーションやフォームをサーバに登録しないときは，これらのユーザ処理リストは使用しません。 Groupmax Formの場合，これらのユーザ処理リストに基づいて帳票が起動されます。
案件の文書DB格納	Groupmax Integrated Desktopの場合，案件エディタで自動的に処理されます。 アプリケーションの場合，Groupmax Document Manager - Development Kitを使用して作成する必要があります。 Groupmax Formの場合，文書操作コマンドで処理する必要があります。
作業状態の選択更新	Groupmax Integrated Desktopの案件エディタ用の情報です。 アプリケーション及びGroupmax Formの場合は，使用しません。

マルチサーバ構成では，ビジネスプロセス定義を登録するサーバを指定する必要があります。ビジネスプロセス登録サーバを決めるときは，次の点を考慮してください。

• ビジネスプロセスを登録するサーバと処理ユーザが所属するサーバの関係を考慮する
  ビジネスプロセス登録サーバは，登録されたビジネスプロセスのワーク及び案件を管理し，案件のノード間の遷移を制御します。案件は，ビジネスプロセス登録サーバを中心に制御され，他のサーバへは，マルチサーバ機能によって案件の実体が転送されます。例えば，次のノードの処理ユーザが同じサーバのユーザであっても，ビジネスプロセス登録サーバ以外のサーバであれば，案件は一度ビジネスプロセス登録サーバに転送され，次のノードに遷移し，再び元のサーバに転送されます。
  このため，ビジネスプロセス登録サーバ以外のサーバで案件を処理するユーザが多いと，案件の転送が多くなり，遷移に時間がかかる場合があります。また，ビジネスプロセス登録サーバでは，すべてのワークや案件を管理するため，必要なデータベースの容量が大きくなります。
  
• 将来のサーバ構成の変更を考慮する
  ビジネスプロセス定義をサーバに登録した後，ビジネスプロセスに案件を一つでも投入すると，登録サーバを別のサーバに変更できなくなります。新しいバージョンのビジネスプロセス定義として登録しても，登録サーバは変更できません。
  ビジネスプロセス定義の登録サーバを変更したい場合は，登録済みのサーバから削除して，別のサーバに登録し直す必要があります。このとき，ビジネスプロセスに案件があると，ビジネスプロセス定義を削除できません。したがって，案件がある間は登録サーバを変更できません。
  ビジネスプロセス定義が登録されているサーバを削除する場合，ビジネスプロセス定義の登録サーバを変更する必要があります。しかし，ビジネスプロセスに案件がある間は，登録サーバを変更できないので，サーバを削除できません。
  このように，サーバに一度ビジネスプロセスを登録すると，サーバ構成の変更が困難になる場合があります。したがって，Workflow管理サーバ以外のサーバをビジネスプロセス登録サーバにする場合は，将来のサーバ構成の変更を考慮して，登録サーバを決めてください。
  ビジネスプロセス登録サーバの変更については，「3.9.7(6) 各種登録サーバの変更」を参照してください。
  

バージョン1で作成したビジネスプロセス定義の名称が，バージョン2以降で作成した拡張ビジネスプロセス定義の名称と同じ名称になっている場合，Groupmax Integrated Desktopの案件エディタ，Groupmax Formからバージョン1で作成したビジネスプロセス定義に案件を投入できなくなります。

バージョン1，バージョン2で作成したビジネスプロセス定義の名称は，重複しないようにしてください。