Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Im workflow説明資料(patch01対応）
Similaire à Im workflow説明資料(patch01対応） (20)
Im workflow説明資料(patch01対応）
- 1. IM-Workflow - The Next Generation - 2010/6/23 ©Copyright NTT DATA INTRAMART CORPORATION 2010
- 2. ドキュメントワークフロー(BPW）が抱える問題 • ワークフローを使用するユーザ様の規模の拡大 – 現行のワークフローを設計した当初想定していないような規 模で、ワークフローが使用される。 • 申請件数：1万件／月 • ユーザ数：20万人 • 要望追加による仕様の矛盾 – 相反する要望を追加 一気に解決しましょう • 機能を追加したくてもできない。 • 更なる機能追加の要望 – もっと柔軟なワークフローがよい • 稟議を行いたい！！（要望大）
- 3. ワークフローの位置づけ
- 4. 現行イントラマート製品で実現している領域 標準で提供する機能で 実現できない領域
- 6. 基本コンセプト • 自由 – 柔軟性 • 柔軟なルート変更、案件操作での自由なノード移動など • シンプル – 例外的な仕様は排除 • ある条件の場合にだけ例外的に振る舞う仕様は排除する。 • 優しさ – 使い勝手 • 標準で提供できる機能は出来るだけ提供する。
- 7. 機能説明-管理者向け機能 以降、IM-Workflowが実現する領域、 及びコンセプトをベースとした提供機能の説明 ポイント – マスタメンテナンスの負荷軽減、マスタの再利用性UP • コンテンツ、ルート、フロー – ルートの再利用 • ルートテンプレート – あたらしいノードで柔軟性UP • 動的承認、テンプレート置換など
- 8. フロー定義 • コンテンツ定義：承認の処理内容 – ユーザアプリケーションの情報（ユーザ業務画面、プログラムなど） • ルート定義：承認の経路情報と申請者、承認者の情報 • フロー定義：コンテンツ定義とフロー定義を紐づける情報
- 9. コンテンツ定義・ルート定義・フロー定義の関係 • コンテンツとルートはフローを介して疎結合 • N対Nの組み合わせ – 互いの修正の影響を最小限にとどめる。 – コンテンツ、ルートの再利用性を向上させる。
- 10. ルートテンプレート定義 承認順序の再利用を目的にルートを部品化した情報 – ルート定義に組み込むことで部品を再利用できる。 – 申請時に設定元のルート定義に展開される。
- 11. ノード ルート上の１つの申請や承認処理を表す単位 • 開始 • テンプレート置換 • 終了 – テンプレート開始 – テンプレート終了 • 申請 • 承認 • 動的承認 動的承認ノード、横配置ノード、縦配置ノードを • システム 使用することで申請者や承認者による柔軟な • 確認 ルート選択を実現できる。 • 同期開始 テンプレート置換ノードにルートテンプレートを設 • 同期終了 定することでルートを再利用できる。 • 分岐開始 • 分岐終了 ルート上のノード名は任意の名称に変更できる。 • 横配置 • 縦配置
- 12. バージョン コンテンツ／ルート／フローがそれぞれ持つ期間情報 – 申請時に指定する「申請基準日」によって申請で利用できる フロー／コンテンツ／ルートのバージョンが決まる。
- 13. モニタリング • 完了した案件の処理状態を集計 – システム全体（ログイングループ） • システムで集計 – フロー単位 • フロー毎に集計
- 14. アラート • エラー／ワーニング等を検出し、その内容を画面上から参照す ることができる。 • 標準提供のアラート機能（バッチ処理） – ノードの対象者が設定されていない – 分岐開始ノードで停止している – 分岐終了ノードで停止している – ノードに到達してから指定日時経過しても処理されていない – 案件が開始してから指定日時経過しても終了していない • ユーザが任意のアラート検出プログラムを作成することもでき る。
- 15. 機能説明-利用者向け機能 ポイント – 柔軟なルート変更 • 管理者が決めた範囲で申請者、承認者がルートを変更でき る。（稟議などを想定） – 案件プロパティ • ユーザアプリケーションの業務情報を保持するKey&Valueス トアを用意 – 案件操作・参照 • 付与された権限の範囲で本人以外のワークフローを参照、操 作できる。
- 16. 案件 利用者が扱うワークフローの処理（トランザクション情報）のこと – 申請者がフロー定義を選択して申請すると、 IM-Workflowは フロー定義のコピーを元に案件を開始する。
- 18. ユーザアプリケーションと案件 ワークフローとユーザアプリケーションから案件を特定 するための仕組み • システム案件ID – ワークフロー内で案件を一意に特定するためのキー • ワークフロー側で採番する。 （発行） • 処理を行うために使用するもので、画面に表示するための情報ではない。 • ユーザデータID – ユーザアプリケーション側から案件を一意に特定するためのキー • ユーザアプリケーション側で採番する。 （発行） • 処理を行うために使用するもので、画面に表示するための情報ではない。 • 案件番号 – 案件を視覚的に判断するための値 • ユーザアプリケーション側で採番する。 （発行） • 画面等に表示する。
- 19. ユーザアプリケーションと案件
- 20. 案件プロパティ 案件毎に指定可能なユーザアプリケーションで指定 できる「Key&Value」ストア – ユーザアプリケーション側で制御を行う。 • 任意のタイミングで登録／更新が可能
- 21. 案件プロパティ 「案件プロパティ定義」としてKeyをマスタ設定すると – 一覧画面の一覧表示項目として使用できる。 – 「ルール」機能の比較用の変数として使用できる。 – 「メールテンプレート」の置換文字列として使用できる。
- 22. ワークフローの処理 • 申請 • 引戻し • 再申請 • 振替 • 取止め • 一時保存 – 同じフローを複数件一時保存ができる。 • 一時保存 – 一時保存データは何回でも更新できる。 • 差戻し – 差戻し先を任意に指定できる。 • 承認 • 保留解除 • 差戻し – 保留状態を解除し、保留したユーザ以外も処理 • 承認終了 できる状態にする。 • 否認 • 引き上げ – 処理としてはないが、 “案件操作”機能で同様の • 保留 機能を実現することはできる。 • 保留解除 処理の名前はフロー単位で変更できる。
- 23. 案件操作・参照 申請者、承認者になっている案件以外を参照・操作 できる機能 – フロー単位に案件操作権限を設定できる。 – 権限レベルを個別に設定できる。 • 案件を見ることが出来ない。 • 案件を見ることが出来る。 • 承認者を追加・変更できる。 • 処理中ノードの移動が出来る。（進む、戻る、終了）
- 24. 案件操作・ノード移動 ルート上の位置を変更する。 – 原則どのノードにも移動できる。 • 戻す • 進める • 終わる
- 25. 確認 申請者や承認者以外の利用者が案件を確認できる • 確認とは – 処理（承認等）を行うことはできない。 – 確認（案件の内容を）したと言うことを残すことができる。 – コメントを入力することができる。 • 確認は – 確認ノードに紐づくノードが処理済となると確認が可能となる。 – 何回でも行うことができる。 – いつまで確認が行えるか設定することができる。 • 案件が処理中の場合のみ行える。 （案件が終了するとできなくなる） • 案件が完了しても行える。 （案件が退避されるまで可能）
- 26. 処理対象の設定 ユーザを申請者、承認者にする設定 – 対象者を複数設定（or条件）可能とする。 – ユーザ – 申請者 – 組織 – 申請者の組織 – 役職 – 申請者の組織＋役職 – パブリックグループ – 申請者の上位組織 – 申請者の下位組織 – 役割 – 申請者の組織＋役職 – ロール – 申請者の上位組織＋役職 – 組織＋役職 – 申請者の下位組織＋役職 – 組織＋ロール – 前処理者の組織 – 役職＋ロール – 前処理者の上記組織 – パブリックグループ＋役割 – 前処理者の下位組織 – パブリックグループ＋ロール – 前処理者の組織＋役職 – 役割＋ロール – 前処理者の上記組織＋役職 – 前処理者の下位組織＋役職 – ユーザ拡張 ※ 上位組織／下位組織の場合、１つ上位なのか、 上位全てなのかは、別途指定可能とする
- 28. 代理設定 • 代理設定は即時に反映される。 – 申請中の案件に対しても反映 • 代理元に対して代理先を複数設定できる。 • 申請と承認を分けて設定できる。 • 設定の種類 – ユーザ対ユーザの代理設定 – ユーザに加え、指定したフロー定義のみへの代理設定
- 29. 代理期間 代理先は代理期間が案件処理の現在日時点で有効 な場合に代理処理できる。 基準日 3月1日 7月1日 11月1日 3月1日 × × × 現在 7月1日 ○ ○ ○ 日付 11月1日 × × ×
- 30. 振替 案件の処理権限を持つ利用者が別の利用者に権限を 完全に移譲する。 – 振替は何回でもできる。 – 代理先が代理元の振替を行える。
- 31. 一括処理・連続処理 • 一括処理 – 選択した複数の案件を一括で承認できる。 • 一括確認 – 選択した複数の案件を一括で確認できる。 ※一括処理／一括確認は使用の可否を選択可能とする →内部統制上好ましくないとの指摘が多い • 連続処理 – 選択した複数の案件を連続的に処理できる。 • 連続確認 – 選択した複数の案件を連続的で確認できる。
- 32. 自動処理 ノードの状態がある条件に合致した場合にノードを 自動で処理する。 – 自動処理の種類 • 処理期限自動処理 • 既処理者自動承認 • 連続自動承認 • 再処理自動承認
- 33. ユーザプログラム 案件の処理時に実行するアプリケーションプログラム • 以下のイベントに対してそれぞれ複数個のプログラムを設定できる。 – 案件開始処理 – 案件終了処理 – アクション処理 • 申請や承認などの処理が実行された場合 – 到達処理 • 処理が進みノードに到達した場合 – 分岐処理 • どの分岐先の判断としてプログラムが実行される場合 – 結合処理 • 分岐後に進む判断としてプログラムが実行される場合 – 案件退避処理 • 案件がアーカイブされる場合 – 未完了案件削除 – 完了案件削除 – 過去案件削除
- 34. ルール 分岐や結合処理において、ルールを使用できる – １つのルール内に１０個まで条件を設定できる。 • すべての条件に一致（AND） • 何れかの条件に一致（OR) – 案件プロパティの値で比較できる。
- 35. 分岐 • 分岐開始処理 – 種類 • 分岐開始プログラム（ユーザプログラム） • 画面でのルート選択（申請者／承認者が進むルートを選択） • ルール（設定画面で条件を指定可能） • 設定なし • 分岐内の全てのルートに進む。 • 分岐終了処理 – 種類 • 分岐開始プログラム（ユーザプログラム） • ルール（設定画面で条件を指定可能） • 設定なし • 分岐内の到達ルート上のノードが全て処理済みとなった場合、分岐の 外に進む。
- 36. 機能説明-大量データ、レスポンス ポイント – 小規模から大規模までを対象とする。 – データ増加によるレスポンス低下を考慮 • 申請数：100万件／年間 • データを退避する仕組みを提供 – 管理業務の負荷軽減
- 37. 大規模への対応（案件データ量の増加） • 完了した案件を別テーブルに移動する仕組み • 過去の案件データを退避する仕組み（アーカイブバッチ） ※小規模ではアーカイブを行わなくて良い。
- 38. 大規模への対応（管理業務） ワークフロー運用管理者 – 権限を譲渡し、ワークフロー運用管理者を複数配置できる ※小規模では運用管理者を配置しなくともよい。
- 40. 大規模への対応（フロー図） 案件の進捗状況を示すフロー図をHTML画面に書き込 む方式に変更(Draw2D) • ノードの個数が増えても旧来のビットマップ方式で発生した速度 低下はない ※オプション設定を有効化すれば、ビットマップ画像をファイルに出力することもできます。
- 43. ワークフロー側の申請／承認画面 ユーザ画面から呼び出す – ユーザ画面に申請や承認画面用のタグリブを埋め込む方式 ※一時保存など、使用しない場合はタグを埋め込まなければよい
- 44. ワークフロー側の申請／承認画面
- 45. BPWとの一覧画面を統合-パッチ01リリース BPW側のメニューを基準としてIM-Workflow側と 一覧画面を統合する。 • 対象メニュー • 一覧画面はタブ切り替え方式 – 申請 – 申請済 – 未処理 – 処理済 – 参照 – 代理申請 – 代理申請済 – 代理未処理 – 代理処理済
- 46. インポート／エクスポート機能-パッチ01リリース 開発環境で作成したマスタデータを本番環境へ移行 することを想定（※） • 対象データ – コンテンツ定義 – ルート定義 – フロー定義 – 案件プロパティ定義 – ルール定義 – メール定義 – 一覧表示パターン定義 – フローグループ定義 ※インポート用のファイルをクライアントPC上で作成するようなことや、エクスポート したファイルを編集してインポートするような使用方法は想定していません。 （編集を想定した機能は今後リリース予定のWorkflowDesignerで提供予定）
- 48. ContentsSearch-パッチ01リリース • 検索対象データ – 完了した案件 – アーカイブした過去案件 • 検索結果を閲覧できる利用者 – 完了した案件 – 申請者、（承認などの）処理者、参照者、確認者 – アーカイブした過去案件 – 処理者 ※カスタマイズにより、案件を参照できるユーザを独自に追加している 場合は、全文検索側のインデックス作成処理のカスタマイズも必要です 。
- 49. APIのWEBサービス化-パッチ01リリース 利用者系のAPIをWebサービスとして提供する – 提供するAPI • 申請・承認等のアクション系API • 申請や承認等を行うために必要な情報を取得 するAPI（所属など） • 一覧を取得するAPI
- 50. IM-共通マスタとのマスタ連携-パッチ01リリース IM-共通マスタ側の操作でユーザや組織情報に変更が発生した場 合、IM-Workflow側は変更に対する同期処理を実行する。 – 同期の対象 • IM-Workflow側のマスタに設定されているユーザや組織の情報 – 対象のマスタ情報 • ノードの処理対象の設定（固定指定） • 確認者の設定 • 代理先の設定 • 案件操作権限者の設定 • 代理設定権限者の設定 • 管理グループの設定 • 標準組織の設定
- 51. 細かい機能 • メール – メールテンプレート • カスタマイズを容易にする。 – 置換文字列の充実 – CC／BCCの利用 – URL • 記述されるURLは、基本直接案件へ遷移する。 – メール送信ログ • To,Cc,Bccの内容と件名、本文をログに出力 • 添付ファイル – 承認時でも追加／更新／削除ができる。 • クライアント通知機能（パッチ01リリース） – 新規に到達した案件の件数を通知
- 53. プラグイン化 プラグインを差し込んで機能を追加できる – IWPのプラグインマネージャで実現 処理対象 – 例 • 申請者や承認者として、標準(IM-共通マスタ）で用意しているユーザ以外を利用する 場合 • 申請者や承認者になれるユーザに独自の絞り込み条件を加えたい場合 ユーザプログラム – 例 • 「アクション処理」や「到達処理」にて実行する処理として、標準で用意されているプラ グイン（スクリプト開発モデル／J2EE開発モデル）以外の独自プログラムを利用した い場合