(57)【要約】【課題】  連携先のワークフローシステムを柔軟に選択可能で、ソフトウェア開発における不具合管理システムに好適なワークフロー連携技術を提供する。【解決手段】  外部遷移元ワークフローシステムは、外部遷移を行う場合（Ｓ５０１のＹＥＳ）に、外部遷移先を選択する（Ｓ５０２）。すなわち、ワークフローシステムを特定するための情報および接続するための情報を含む外部遷移先定義情報を予め用意しておき、この外部遷移先定義情報に基づいて外部遷移先を選択する。次に、フィールド限定した汎用データ形式の帳票データを作成して（Ｓ５０３）、外部遷移依頼を行い、外部遷移先の情報を記録する（Ｓ５０４）。外部遷移先ワークフローシステムは、外部遷移依頼受付時（Ｓ５１１のＹＥＳ）に、外部遷移元の情報を記録し（Ｓ５１２）、帳票データを自システム用に変換し（Ｓ５１３）、外部遷移に対応するワークフローを開始する（Ｓ５１４）。【選択図】  図５
2005190280.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ利用により通信ネットワークを介して複数のワークフローシステムを連携させるワークフロー連携方法において、
前記複数のワークフローシステムの各々に関する情報として、当該ワークフローシステムを特定するための情報および当該ワークフローシステムと接続するための情報を含む外部遷移先定義情報を格納することで、各ワークフローシステムを予め登録した記憶手段を使用すると共に、
前記複数のワークフローシステム中の１つを外部遷移元としてその状態を外部遷移させる場合に、当該外部遷移元のワークフローシステム側で、
前記記憶手段に格納されている前記外部遷移先定義情報に基づき、他のワークフローシステムを外部遷移先として選択する遷移先選択ステップと、
選択された前記外部遷移先に対して前記通信ネットワークを介して前記外部遷移元の状態を外部遷移させる外部遷移ステップを行う、
ことを特徴とするワークフロー連携方法。
【請求項２】
前記遷移先選択ステップは、
前記外部遷移元のワークフローシステムのユーザに対して、前記記憶手段に登録されている他のワークフローシステムを提示して外部遷移先をユーザに直接選択させる直接選択ステップ、
前記外部遷移元のワークフローシステムで管理している帳票データのフィールドの値と前記記憶手段に登録されている他のワークフローシステムとを予め関連付けた情報に基づき、帳票データのフィールドの値に応じて外部遷移先を選択する自動選択ステップ、
前記外部遷移元のワークフローシステムのユーザからの指示に基づき、前記記憶手段に新たなワークフローシステムが登録された場合に、その新たに登録されたワークフローシステムを外部遷移先として選択する登録選択ステップ、
という３種類のステップのうち、少なくとも１つ以上のステップを含む、
ことを特徴とする請求項１に記載のワークフロー連携方法。
【請求項３】
前記外部遷移または外部遷移戻りを依頼しようとしている依頼元のワークフローシステム側で、
選択された前記外部遷移先のワークフローシステムに送信するフィールドを予め定義した複数の選択ルールの中から、前記外部遷移または前記外部遷移戻りの依頼先のワークフローシステムに対して、前記記憶手段に格納されている当該依頼先のワークフローシステムに関する前記外部遷移先定義情報に基づき、使用する選択ルールを選択する選択ルール選択ステップと、
選択された前記選択ルールに基づき、前記外部遷移または前記外部遷移戻りの依頼時に送信する帳票データのフィールドを限定して送信用の帳票データを作成するデータ作成ステップ、
を行うことを特徴とする請求項１または請求項２に記載のワークフロー連携方法。
【請求項４】
前記複数の選択ルールの各々は、ルールの適用先となりうるワークフローシステムの条件を表現するワークフロー条件情報をルール定義に対応付けたものである、
ことを特徴とする請求項３に記載のワークフロー連携方法。
【請求項５】
帳票データが添付された前記外部遷移または外部遷移戻りの依頼を受け付けた受付ワークフローシステム側で、
前記複数のワークフローシステム中におけるワークフローシステム間のフィールドの対応関係を予め定義した複数の変換ルールの中から、前記外部遷移または外部遷移戻りの依頼元のワークフローシステムに対して、前記記憶手段に格納されている当該依頼元のワークフローシステムに関する前記外部遷移先定義情報または別の記憶手段に格納されている当該依頼元のワークフローシステムに関する情報に基づき、使用する変換ルールを選択する変換ルール選択ステップと、
選択された前記変換ルールに基づき、添付された前記帳票データを変換して前記受付ワークフローシステム側で利用可能な帳票データを生成するデータ変換ステップ、
を行うことを特徴とする請求項１乃至請求項４のいずれかに記載のワークフロー連携方法。
【請求項６】
前記複数の変換ルールの各々は、ルールの適用先となりうる外部遷移先と外部遷移元のワークフローシステムの組み合わせ条件を表現する組み合わせ条件情報をルール定義に対応付けたものである、
ことを特徴とする請求項５に記載のワークフロー連携方法。
【請求項７】
前記選択ルールまたは前記変換ルールの前記ワークフロー条件情報または前記組み合わせ条件情報は、読み替え可能な部分を含む文字列で表現される、
ことを特徴とする請求項４または請求項６に記載のワークフロー連携方法。
【請求項８】
前記選択ルール選択ステップまたは前記変換ルール選択ステップは、前記ワークフローシステムに関する前記外部遷移先定義情報が、当該ワークフローシステムを特定する複数種類の特定情報を含む場合に、特定情報毎の重要度に応じた重み付けを行って各ルールの重み値を算出し、その合計が最大であるルールを選択するステップを含む、
ことを特徴とする請求項３乃至請求項７のいずれかに記載のワークフロー連携方法。
【請求項９】
前記複数のワークフローシステムは不具合管理システムである、
ことを特徴とする請求項１乃至請求項８のいずれかに記載のワークフロー連携方法。
【請求項１０】
コンピュータ利用により通信ネットワークを介して複数のワークフローシステムを連携させるワークフロー連携システムにおいて、
前記複数のワークフローシステムの各々に関する情報として、当該ワークフローシステムを特定するための情報および当該ワークフローシステムと接続するための情報を含む外部遷移先定義情報を格納することで、各ワークフローシステムを予め登録した記憶手段を備え、
前記複数のワークフローシステム中の少なくとも１つは、自ワークフローシステムを外部遷移元としてその状態を外部遷移させる場合に、前記記憶手段に格納されている前記外部遷移先定義情報に基づき、他のワークフローシステムを外部遷移先として選択し、選択した外部遷移先に対して前記通信ネットワークを介して外部遷移元である自ワークフローシステムの状態を外部遷移させる外部遷移先管理システムとして構成されている、
ことを特徴とするワークフロー連携システム。
【請求項１１】
前記外部遷移先管理システムは、前記記憶手段に格納された前記外部遷移先定義情報を管理するように構成されている、
ことを特徴とする請求項１０に記載のワークフロー連携システム。
【請求項１２】
前記記憶手段には、前記外部遷移先定義情報に加えて、帳票データに関する共通フィールドを定義した共通フィールド定義情報、定義された共通フィールドと前記複数のワークフローシステムでそれぞれ使用している個別のフィールドとの対応関係に関するフィールド関係情報が格納され、
前記記憶手段に格納された前記外部遷移先定義情報、共通フィールド定義情報、フィールド関係情報、という３種類の情報を管理することにより外部遷移先の設定に関する各種の情報を一元管理する外部遷移先管理サーバが設けられた、
ことを特徴とする請求項１０に記載のワークフロー連携システム。
【請求項１３】
通信ネットワークを介して複数のワークフローシステムを連携させるために、少なくとも１つのワークフローシステムを実現するコンピュータに適用されるワークフロー連携プログラムにおいて、
前記複数のワークフローシステムの各々に関する情報として、当該ワークフローシステムを特定するための情報および当該ワークフローシステムと接続するための情報を含む外部遷移先定義情報を格納することで、各ワークフローシステムを予め登録した記憶手段を管理する情報管理機能と、
前記コンピュータにより実現される自ワークフローシステムを外部遷移元としてその状態を外部遷移させる場合に、前記記憶手段に格納されている前記外部遷移先定義情報に基づき、他のワークフローシステムを外部遷移先として選択する遷移先選択機能と、
選択された前記外部遷移先に対して前記通信ネットワークを介して前記外部遷移元である自ワークフローシステムの状態を外部遷移させる外部遷移機能、
を前記コンピュータに実現させることを特徴とするワークフロー連携プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のワークフローシステムを連携させるワークフロー連携技術に関するものであり、特に、ソフトウェア開発における不具合管理システムに好適なワークフロー連携技術に関する。
【背景技術】
【０００２】
ソフトウェア開発のテスト工程では、発見された不具合を管理するために、不具合管理システムが利用されている。不具合管理システムでは、発見された個々の不具合の状態遷移（確認中、修正中など）と不具合情報の管理が主目的である。不具合の状態遷移を制御する仕組みとして、ワークフローシステムを利用することが有効であり、実際に、多くの不具合管理システムにおいて、何らかのワークフローシステムが導入されている。
【０００３】
一方、ソフトウェアの大規模化に伴い、汎用的な機能（例えば、ブラウザ、漢字変換など）は、汎用的なソフトウェア部品として開発され、多種多様な製品で流用されるようになってきた。図１０は、このような汎用的なソフトウェア部品を含むソフトウェア製品の一例を示す図であり、「ブラウザ」α１、「メーラー」α２、「漢字変換」α３、等のソフトウェア部品が、携帯電話Ａ１やデジタル家電Ａ２等の製品に組み込まれた状態を示している。
【０００４】
［単体独立のワークフローシステム］
図１１は、このような開発形態において、複数製品の不具合管理システムと開発者との関係の一例を示す図である。この図１１に示すように、開発者１１０１により開発されたソフトウェア部品αが複数製品Ａ，Ｂに組み込まれている場合、それらの製品Ａ，Ｂの各不具合管理システム１１１０，１１２０は、単体独立のワークフローを個別に実行する単体独立のワークフローシステムであるため、ソフトウェア部品αの開発者１１０１は、それら複数製品Ａ，Ｂの開発者１１１１，１１２１によるテスト工程に参加し、複数の不具合管理システム１１１０，１１２０を参照する必要があった。
【０００５】
また、各不具合管理システム１１１０，１１２０で製品Ａ，Ｂについて発見された不具合は、各不具合管理システム１１１０，１１２０で管理している不具合データベース１１１２，１１２２等の記憶手段にそのまま蓄積される。そのため、ソフトウェア部品αの不具合情報がばらばらになり、ソフトウェア部品αの開発者１１０１が不具合情報を統計的に分析することは困難であった。このように、製品に汎用的なソフトウェア部品を組み込む場合における不具合管理システムの問題を整理すると、次のような３つの問題点１〜３が導出される。
【０００６】
［問題点１：  複数の不具合管理システムを参照する必要がある。］
一般的に、総合テストなどは、全てのソフトウェアを組み込んだ製品の品質を確認するために行われる。したがって、不具合管理も製品ごとに実施されるため、ソフトウェア部品の開発者は、個々の製品の不具合管理システムにアクセスする必要がある。その結果、利用される製品が増えるにつれて、参照する不具合管理システムの数が多くなり、システム全体にかかるオーバーヘッドも増えてしまう。
【０００７】
［問題点２：  ソフトウェア部品の不具合データが集中管理できない。］
上記の問題点１の理由から、不具合データは、各製品の不具合管理システムに蓄積されるため、ソフトウェア部品の不具合データも、製品の不具合管理システムに埋もれてしまう。そのため、ソフトウェア部品の不具合データを集中管理して有効活用することができない。
【０００８】
［問題点３：  ソフトウェア部品の開発グループ固有の不具合管理フローが定義できない。］
不具合のワークフローは、個々の製品ごとに決められているため、ソフトウェア部品の開発グループは、不具合管理のワークフローを各製品のフローに合わせる必要があり、独自のワークフローを定義することができない。
【０００９】
［ワークフローの連携］
以上のような単体独立のワークフローシステムの問題点１〜３を解決するためには、不具合管理システム間でワークフローを連携させることが有効である。図１２は、このような複数の不具合管理システムの連携例を示す図である。この図１２に示すように、開発者１２０１により開発されたソフトウェア部品αが複数製品Ａ，Ｂに組み込まれている場合に、ソフトウェア部品αの不具合管理システム１２００を、それらの製品Ａ，Ｂの各不具合管理システム１２１０，１２２０と連携させるようになっている。
【００１０】
図１３は、図１２に示すように連携した不具合管理システム間のワークフローの連携例を示す図である。この図１３に示すように、例えば、ソフトウェア部品αについての基本的な不具合管理ワークフローの処理手順は、次の通りである。
【００１１】
まず、ソフトウェア部品αの不具合管理システム１２００において、ソフトウェア部品αについて、その開発者１２０１またはその他の担当者により何らかの不具合が「発見」される（１３０１）と、その「発見」された不具合は、その不具合の重要度に応じて修正すべきか否かに「振分け」られる（１３０２）。なお、この場合に、一般的には、修正すべきか否かの判断だけでなく、修正担当者の振分けを行う。
【００１２】
そして、ソフトウェア部品αについて、修正すべき不具合として振分けられた不具合については、その開発者１２０１により「修正」される（１３０３）。なお、このような不具合の修正（１３０３）後、振分け（１３０２）、修正（１３０３）が繰り返される場合もある。いずれの場合でも、不具合の修正後、不具合の発見者である開発者１２１１（または１２２１）またはその他の担当者により、不具合が修正されていることが「確認」された（１３０４）時点で、処理を完了する（１３０５）。
【００１３】
また、「発見」された不具合の重要度が低く、特に修正する必要がない場合、仕様上の制約で不具合とならない場合、あるいは、報告済みの不具合が登録された場合等には、「ノーバグ」として、何ら対処することなしに処理を完了する（１３０６）。なお、実際上は、重要度が低くてもこの段階でノーバグにすることは稀である。
【００１４】
なお、製品Ａ，Ｂの不具合管理システム１２１０，１２２０における基本的な不具合管理ワークフローの処理手順も、ソフトウェア部品αの不具合管理システム１２００における基本的な不具合管理ワークフローの処理手順と同様である。
【００１５】
図１３においては、ソフトウェア部品αの不具合管理システム１２００における不具合管理ワークフローを、ソフトウェア部品αを組み込んだ製品Ａ，Ｂの不具合管理システム１２１０，１２２０における不具合管理ワークフローと連携させるために、製品Ａ，Ｂの不具合管理システム１２１０，１２２０における不具合管理ワークフローには、「ソフトウェア部品αに関する不具合」の処理（１３０７）が追加されている。
【００１６】
この「ソフトウェア部品αに関する不具合」の処理（１３０７）は、製品Ａや製品Ｂで発見された不具合のうち、ソフトウェア部品αに関する不具合がある場合に、その不具合を、ソフトウェア部品αの不具合管理システム１２００に転送する処理である。また、ソフトウェア部品αの不具合管理システム１２００においては、転送されてきた不具合について、不具合管理ワークフロー（１３０１〜１３０７）を行い、不具合を修正した時点で、転送元の不具合管理システム１２１０，１２２０に戻す。
【００１７】
従来、このようにワークフローを連携させる技術としては、他のワークフロー管理システム間と連携する連携ワークを一元的に記述し、一元的に記述された連携ワークから各ワークフロー管理システムで実行するワーク定義部分を取り出して、ワーク定義部分を実行可能な形態に変換し、実行するワークフロー管理システムにロードし、実行する技術が提案されている（特許文献１参照）。
【００１８】
また、他の装置とプロセス実行用のデータを交換する手段と、自装置によって実行されるべきプロセスと他装置によって実行されるプロセスとを関連付けるプロセス間関連付け情報を他装置との間で交換する手段とを備えたプロセス実行装置により、プロセス実行用データの交換とプロセス間関連付け情報との交換を非同期のタイミングで行う技術なども提案されている（特許文献２参照）。
【００１９】
【特許文献１】特開平１０−３０２００２号公報
【特許文献２】特開２００２−２０３０８７号公報
【発明の開示】
【発明が解決しようとする課題】
【００２０】
以上のように、不具合管理システム間でワークフローを連携させることにより、前述した問題点１〜３は解決できるが、不具合管理という特殊分野では、さらに、以下の問題点４〜６が発生する。
【００２１】
［問題点４：  連携するワークフローを柔軟に選択できる必要がある。］
業務システムなどのワークフローシステムでは、どのワークフローシステムと連携するかは、設計時に予め決めるが、不具合管理システムの場合は、製品のライフサイクルや製品投入のサイクルで、さまざまな不具合管理システムと連携する必要が出てくる。そのためには、連携先が柔軟に設定できる必要がある。
【００２２】
［問題点５：  データの秘匿性が要求される。］
製品Ａの開発者とその製品Ａに組み込むソフトウェア部品αの開発者とは、組織や会社が異なる可能性がある。不具合情報は、秘匿性の高いデータであるため、不具合修正に必要な最低限のデータだけを送付し、他のデータを保護したい場合も多い。
【００２３】
［問題点６：  フィールドが異なる。］
不具合データは、集計／分析される。そのようなデータの集計／分析を行うためには、データベースのテーブルのような形式で、正規化して蓄積しておく必要がある。しかし、異なる開発者により開発された製品Ａ，製品Ｂに関する不具合データは、ソフトウェア部品αに関する不具合データと異なる帳票フィールドを持つ可能性があり、単純なデータコピーでは、ソフトウェア部品αの不具合データベースに格納できない可能性がある。
【００２４】
なお、上記のような問題点４〜６は、不具合管理の分野に限らず、同様に、連携先が予め確定していない場合や、異なる組織や会社間でデータを送信する場合における各種のワークフローの連携において同様に発生する問題点である。
【００２５】
本発明は、以上のような従来技術の問題を解決するために提案されたものであり、その目的は、連携先のワークフローシステムを柔軟に選択可能で、特に、ソフトウェア開発における不具合管理システムに好適なワークフロー連携方法とシステム、プログラムを提供することである。
【００２６】
また、別の目的は、異なる組織や会社間でデータを送信する場合においてもデータの秘匿性を確保すること、および、連携するシステム間で異なる帳票フィールドを持つ場合においても連携先のデータを利用可能とすることである。
【課題を解決するための手段】
【００２７】
本発明は、複数のワークフローシステムの各々に関する情報として、当該ワークフローシステムを特定するための情報および当該ワークフローシステムと接続するための情報を含む外部遷移先定義情報を予め用意しておき、この外部遷移先定義情報に基づいて外部遷移先を選択することにより、連携先のワークフローシステムを柔軟に選択できるようにしたものである。
【００２８】
なお、本発明において、重要な用語の定義は次の通りである。
「ワークフローシステム」は、不具合管理システムに限らず、多種多様なワークフローを実行する各種のワークフローシステムを含む広い概念である。
「外部遷移」は、１つのワークフローシステムから他のワークフローシステムに状態が遷移することを意味している。
「外部遷移戻り」は、外部遷移した状態が外部遷移先のワークフローシステムで終了状態に達し、外部遷移元のワークフローシステムに戻されることを意味している。
【００２９】
請求項１に記載の発明は、コンピュータ利用により通信ネットワークを介して複数のワークフローシステムを連携させるワークフロー連携方法において、次のような技術的特徴を有するものである。すなわち、まず、複数のワークフローシステムの各々に関する情報として、当該ワークフローシステムを特定するための情報および当該ワークフローシステムと接続するための情報を含む外部遷移先定義情報を格納することで、各ワークフローシステムを予め登録した記憶手段を使用する。そして、複数のワークフローシステム中の１つを外部遷移元としてその状態を外部遷移させる場合に、当該外部遷移元のワークフローシステム側で、遷移先選択ステップと外部遷移ステップを行う。ここで、遷移先選択ステップは、記憶手段に格納されている外部遷移先定義情報に基づき、他のワークフローシステムを外部遷移先として選択するステップである。また、外部遷移ステップは、選択された外部遷移先に対して通信ネットワークを介して外部遷移元の状態を外部遷移させるステップである。
【００３０】
以上のような発明によれば、外部遷移先となりうる各ワークフローシステムについて、当該ワークフローシステムの外部遷移先定義情報を記憶手段に格納することで、各ワークフローシステムを予め登録することにより、いずれかのワークフローシステムの状態を外部遷移させる場合には、外部遷移先定義情報に基づいて外部遷移先を柔軟に選択することができる。この手法は、各種の分野におけるワークフローシステムの連携に適用可能であるが、特に、ソフトウェア開発における不具合管理システムに好適であり、製品に組み込まれたソフトウェア部品の不具合管理を、製品の不具合管理と連動して効率よく行うことができる。
【発明の効果】
【００３１】
以上説明したように、本発明によれば、複数のワークフローシステムの各々に関する情報として、当該ワークフローシステムを特定するための情報および当該ワークフローシステムと接続するための情報を含む外部遷移先定義情報を予め用意しておき、この外部遷移先定義情報に基づいて外部遷移先を選択することにより、連携先のワークフローシステムを柔軟に選択可能で、特に、ソフトウェア開発における不具合管理システムに好適なワークフロー連携方法とシステム、プログラムを提供することができる。
【発明を実施するための最良の形態】
【００３２】
以下に、本発明の実施形態を図面に沿って具体的に説明する。ただし、ここで記載する実施形態は、本発明を何ら限定するものではなく、本発明の一態様を例示するものにすぎない。
【００３３】
本発明は、典型的には、コンピュータをソフトウェアで制御することにより実現される。この場合のソフトウェアは、コンピュータのハードウェアを物理的に活用することで本発明の作用効果を実現するものであり、また、従来技術を適用可能な部分には好適な従来技術が適用される。さらに、本発明を実現するハードウェアやソフトウェアの具体的な種類や構成、ソフトウェアで処理する範囲などは自由に変更可能であり、例えば、本発明を実現するプログラムは本発明の一態様である。
【００３４】
［１．システム構成］
図１、図２は、本発明を適用した１つの実施形態に係るワークフロー連携システムの構成を示すブロック図であり、図１は外部遷移時のデータの流れを示しており、図２は、外部遷移戻り時のデータの流れを示している。これらの図１、図２に示すように、自ワークフローシステム１００は、通信ネットワークＮを介して他ワークフローシステム２００と連携するようになっている。
【００３５】
ここで、通信ネットワークＮは、ワークフローシステム間の接続に利用する通信媒体であり、ＴＣＰ／ＩＰや専用線などのネットワークのほか、マシンローカルのローカルループバックでも同様のことが実現できる。また、他ワークフローシステム２００は、自ワークフローシステム１００と同様の機能を備え、外部遷移の相手先となるワークフローシステムである。なお、図中では、簡略化の観点から、他ワークフローシステム２００として単一のシステムのみを示しているが、実際には、複数の他ワークフローシステム２００が存在している。
【００３６】
自ワークフローシステム１００はまず、ワークフローシステムとしての機能を実現するための基本的な構成として、ワークフロー駆動部１０１、ワークフロー定義１０２、状態管理データベース（ＤＢ）１０３、帳票データベース（ＤＢ）１１０、等を備えている。
【００３７】
ここで、ワークフロー駆動部１０１は、ワークフロー定義１０２に従って不具合の状態の制御を行う装置であり、ワークフロー定義１０２は、ワークフローの状態と状態遷移を定義した情報である。また、状態管理データベース１０３は、ワークフロージョブ（ワークフローの実行単位）の現在の不具合の状態を記録するデータベースである。一方、帳票データベース１１０は、ワークフローシステムが状態を操作する対象となるデータが格納されたデータベースであり、不具合管理システムの場合には、不具合の詳細情報等が記録されたデータなどが格納されている。
【００３８】
本実施形態において、自ワークフローシステム１００は、以上のようなワークフローシステムとしての基本的な構成に加えて、本発明に従い、外部遷移を管理する機能を実現するための特徴的な構成を備えている。すなわち、自ワークフローシステム１００は、外部遷移送信部１１１、外部遷移受信部１１２、送信データ選択部１１３、帳票データ変換部１１４、外部遷移先定義データベース（ＤＢ）１２０、外部遷移先管理データベース（ＤＢ）１２１、外部遷移元管理データベース（ＤＢ）１２２、選択ルール群１２３、変換ルール群１２４、等を備えている。
【００３９】
ここで、外部遷移送信部１１１は、他ワークフローシステム２００に外部遷移を行うと共に、他ワークフローシステム２００から受付けた外部遷移を外部遷移元に戻す装置である。また、外部遷移受信部１１２は、他ワークフローシステム２００からの外部遷移を受付けると共に、他ワークフローシステム２００からの外部遷移戻りを受付ける装置である。
【００４０】
送信データ選択部１１３は、選択ルール１２３に従って、遷移先への遷移時、および遷移元への戻り時に送信される帳票データを選択し、送信する汎用データ形式を作成する部分である。帳票データ変換部１１４は、変換ルールに従って、遷移先からの受信時や、遷移元からの戻り時に、汎用データ形式で帳票データを受信し、自システムのデータ形式に変換する部分である。
【００４１】
外部遷移先定義データベース１２０は、外部遷移先となりうるワークフローシステムを定義する外部遷移先定義情報を格納するデータベースである。ここで、外部遷移先定義情報は、遷移先と遷移先サーバ等のワークフローシステムを特定するための情報と、ログイン情報等のワークフローシステムと接続するための情報を含む。また、外部遷移先管理データベース１２１は、ワークフロージョブと遷移先サーバ、遷移先のワークフロージョブとの関係に関する情報を格納するデータベースである。さらに、外部遷移元管理データベース１２２は、遷移元のワークフロージョブ、遷移元サーバ、ワークフロージョブとの関係に関する情報を格納するデータベースである。
【００４２】
選択ルール群１２３は、帳票データ中の送信するフィールドを予め定義した複数の選択ルールに関する情報である。また、変換ルール１２４群は、汎用データ形式から、自システムの帳票フィールドに合わせてフィールドを変換するための複数の変換ルールに関する情報である。
【００４３】
なお、図示していないが、他ワークフローシステム２００も、ワークフローシステムとしての機能および外部遷移を管理する機能を実現するために、自ワークフローシステム１００と同様の構成を備えている。
【００４４】
また、本実施形態に係るワークフロー連携システムにおいて、ワークフローシステム１００，２００を構成する各部１０１〜１０３，１１０〜１１４，１２０〜１２４は、コンピュータのメインメモリとそれに記憶されたワークフロー実行用および外部遷移管理用として特化されたプログラム、そのプログラムによって制御されるＣＰＵなどの演算処理部、必要なデータを記憶する補助記憶装置、等により実現される。なお、ここで挙げたメインメモリ、ＣＰＵ、補助記憶装置、等のハードウェア資源は、コンピュータが一般的に備えている基本的な構成要素であるため、これ以上の説明は省略する。
【００４５】
［２．ワークフローシステムの定義］
「ワークフローシステム」は、決められた順序に従って、対象となる帳票データの状態遷移を管理するシステムである。例えば、不具合管理システムでは、対象となる帳票データは不具合データである。
【００４６】
ワークフローシステムにおける「ワークフロー定義」は、前述したように、状態と状態遷移を定義した情報であり、具体的には、個々の状態、状態遷移の順序などを定義したものである。「状態」には、「開始状態」、「途中状態」、「終了状態」、がある。「開始状態」から遷移を開始し、「終了状態」で遷移を終える。例えば、各状態はそれぞれ次のような情報を持つ。
「開始状態：  状態名、遷移先の状態、分岐条件」、
「途中状態：  状態名、遷移先の状態、分岐条件」、
「終了状態：  状態名」
【００４７】
ここで、各情報「状態名」、「遷移先の状態」、「分岐条件」、の定義は次の通りである。
「状態名」は、状態を識別する情報であり、実際の名称に限らず、簡略化された名称やその状態を示す番号や記号等、状態を識別可能な情報を広く含む概念である。
「遷移先の状態」（以降では単に「遷移先」と呼ぶが、同じ意味である）は、次に遷移する状態の候補を示す情報である。該当する状態にある遷移先候補のいずれに遷移するかは、分岐条件により決定される。
「分岐条件」は、遷移する分岐先を決定するロジック（条件）である。この分岐条件は、複雑な判断や、帳票データやアプリケーションから渡されたデータの参照を含む場合がある。
【００４８】
このような「状態名」、「遷移先の状態」、「分岐条件」等の情報により定義される状態を組み合わせることで、様々な処理手順のワークフロー定義を得ることができる。図３は、このようなワークフロー定義の一例を示す状態遷移図である。この図３においては、１つの開始状態３１０、４つの途中状態３２１〜３２４、３つの終了状態３３１〜３３３、という合計８個の状態とその状態遷移が表現されている。
【００４９】
この図３において、途中状態４（３２４）以外の３つの途中状態３２１〜３２３はいずれも、遷移先の状態としてそれぞれ２つの状態が定義されているため、分岐条件を評価して次の状態を決定することになる。この図３においては、一例として、途中状態１（３２１）に対して、「承認なら途中状態２へ、否認なら終了状態３へ」という分岐条件が定義され、また、途中状態２（３２２）に対して、「『金額』フィールドの値が１０万未満なら途中状態３へ、１０万以上なら途中状態４へ」という分岐条件が定義されている。
【００５０】
なお、このようなワークフロー定義は、図１、図２に示すように、ワークフロー駆動部１０１と別に独立して定義され、論理的または物理的に独立して存在している場合もあるが、ワークフロー駆動部１０１に組み込まれている場合もある。
【００５１】
一方、ワークフローシステムで処理される個々の案件（実行単位）を「ワークフロージョブ」と呼び、ワークフロージョブに対応する帳票データベース１１０中のデータ単位を「帳票レコード」と呼ぶ。「帳票レコード」は複数の「フィールド」から構成される。また、「ワークフロージョブ」と「帳票レコード」との対応付けは、状態管理データベース１０３中の個々のワークフロージョブに帳票レコードのＩＤを記録するか、帳票データベース１１０中の個々の帳票レコードにワークフロージョブのＩＤを記録することにより行われる。
【００５２】
［３．ワークフローシステム連携技術の定義］
背景技術について前述したように、ワークフローシステムを連携させることで、単体独立のワークフローシステムにおける前述した問題点１〜３を解決することができる。本発明においては、前述した通り、１つのワークフローシステムから他のワークフローシステムに状態が遷移することを「外部遷移」と呼んでおり、この外部遷移によってワークフローシステムを連携させることができる。
【００５３】
このようなワークフローシステム連携を実現するために、具体的には、以下の４つの機能Ｆ１〜Ｆ４が使用される。
「外部遷移送信機能Ｆ１：
他のワークフローシステムに状態を外部遷移させる機能」、
「外部遷移受付機能Ｆ２：
他のワークフローシステムから状態の外部遷移を受け付ける機能」、
「外部遷移戻り送信機能Ｆ３： 
外部遷移先のワークフローシステムで終了状態に達した場合に、外部遷移元に状態を戻す機能」、
「外部遷移戻り受付機能Ｆ４： 
外部遷移先のワークフローシステムから状態の戻りを受け付ける機能」
【００５４】
図４は、このような機能Ｆ１〜Ｆ４を用いたワークフローシステムの連携例を示す図である。この図４の連携例は、ソフトウェア部品αの不具合管理システムを外部遷移先ワークフローシステム４００とし、そのソフトウェア部品αが組み込まれた製品の不具合管理システムを外部遷移元ワークフローシステム４１０とした場合を示しており、図１３に示したワークフローシステムの連携例に対応している。したがって、ワークフローの処理手順４０１〜４０７は、図１３に示したワークフローの処理手順１３０１〜１３０７に対応している。
【００５５】
なお、図１、図２に示すワークフロー連携システムにおいては、外部遷移送信部１１１により、外部遷移送信機能Ｆ１と外部遷移戻り送信機能Ｆ３が実現され、また、外部遷移受信部１１２により、外部遷移受付機能Ｆ２と外部遷移戻り受付機能Ｆ４が実現されるようになっている。
【００５６】
また、外部遷移を行うためには、ワークフロー定義で、どの状態に達したら状態を遷移させるかを定義する必要がある。そのため、ワークフロー定義においては、前述した「開始状態」、「途中状態」、「終了状態」、の他に、外部遷移を行う状態：「外部遷移状態」を定義する。すなわち、この「外部遷移状態」に達したときに外部遷移が行われる。例えば、「外部遷移状態」は次のような情報を持つ。
「外部遷移状態：  状態名、遷移先の状態、分岐条件」
なお、この「外部遷移状態」において、「遷移先の状態」、「分岐条件」は、外部遷移先から状態が戻ってきた場合の外部遷移戻り時に次の状態に遷移するための情報である。
【００５７】
［４．外部遷移の概略］
以下には、図１、図２に示すワークフロー連携システムにより、ワークフローシステム間で外部遷移を行うための基本的なデータとシステム動作について説明する。
【００５８】
まず、外部遷移を行うためには、「どこに外部遷移しているか」、および「どこから外部遷移されているか」、を記録する必要がある。図１、図２に示すワークフロー連携システムにおいては、外部遷移先管理データベース１２１と外部遷移元管理データベース１２２がその役目を果たすようになっている。以下には、これらのデータベース１２１，１２２に格納する具体的なデータ例について順次説明する。
【００５９】
［４−１．外部遷移先管理データベース］
外部遷移先管理データベース１２１は、「どこに外部遷移しているか」を示す情報を記録するデータベースである。外部遷移先管理データベース１２１は、外部遷移依頼時にその情報を記録し、外部遷移戻り受付時に対応するワークフロージョブや帳票レコードを特定するために利用される。この外部遷移先管理データベース１２１に記録されるデータには、例えば、以下のような項目が含まれる。
【００６０】
「ワークフロージョブＩＤ：
外部遷移しているワークフロージョブを識別するＩＤ」、
「外部遷移先サーバアドレス：
外部遷移先のサーバアドレスやワークフローシステム名など外部遷移先を特定する情報」、
「外部遷移先のワークフロージョブＩＤ：
外部遷移先の対応するワークフロージョブを識別するＩＤ」
【００６１】
なお、これらの項目は、データベースの設計により異なってくる。また、外部遷移先からの戻り時に直接ワークフロージョブが特定できるデータが含まれている場合は、外部遷移先管理データベース１２１が不要となる場合もある。
【００６２】
次の表１は、外部遷移先管理データベース１２１に記録されるデータの具体的なデータ構造の一例を示している。
【表１】
2005190280.tif 000003
【００６３】
［４−２．外部遷移元管理データベース］
外部遷移元管理データベース１２２は、「どこから外部遷移されているか」を示す情報を記録するデータベースである。外部遷移元管理データベース１２２は、外部遷移受付時にその情報を記録し、外部遷移戻り時に接続する外部遷移元のワークフローシステムを特定するために利用される。この外部遷移元管理データベース１２２に記録されるデータには、例えば、以下のような項目が含まれる。
【００６４】
「ワークフロージョブＩＤ：
外部遷移されているワークフロージョブを識別するＩＤ」、
「外部遷移元ワークフローシステム：
外部遷移元のサーバアドレスやワークフローシステム名など外部遷移元を特定する情報」、
「外部遷移元のワークフロージョブＩＤ：
外部遷移元の対応するワークフロージョブを識別するＩＤ」
【００６５】
なお、これらの項目は、データベースの設計により異なってくる。
【００６６】
次の表２は、外部遷移元管理データベース１２２に記録されるデータの具体的なデータ構造の一例を示している。
【表２】
2005190280.tif 000004
【００６７】
［４−３．外部遷移の動作フロー］
図５は、図１、図２に示すワークフロー連携システムにおいて、ワークフローシステム間で外部遷移させる場合の処理手順を示すフローチャートである。以下には、この図５を参照しながら、外部遷移の処理手順について説明する。
【００６８】
なお、図１、図２のワークフローシステム１００，２００と、図５に示す外部遷移元／外部遷移先ワークフローシステムとの関係を説明すれば、自ワークフローシステム１００が外部遷移元ワークフローシステムである場合には、他ワークフローシステム２００が外部遷移先ワークフローシステムとなる。逆に、自ワークフローシステム１００が外部遷移先ワークフローシステムである場合には、他ワークフローシステム２００が外部遷移元ワークフローシステムとなる。
【００６９】
まず、外部遷移元ワークフローシステムにおいて、ワークフローの実行中にワークフロージョブが外部遷移状態に達した場合（Ｓ５０１のＹＥＳ）には、外部遷移先を選択し（Ｓ５０２）、フィールド限定した汎用データ形式の送信用の帳票データを作成して（Ｓ５０３）、外部遷移先に外部遷移依頼を行うと共に、外部遷移先に関する情報を記録する（Ｓ５０４）。外部遷移元ワークフローシステムによるこの一連の処理（Ｓ５０１〜Ｓ５０４）の詳細は次の通りである。
【００７０】
まず、外部遷移元ワークフローシステムのワークフロー駆動部１０１において、ワークフロージョブが外部遷移状態に達した場合（Ｓ５０１のＹＥＳ）に、ワークフロー駆動部１０１は、外部遷移することを外部遷移送信部１１１に指示する（図１の(1)）。この指示により、外部遷移送信部１１１は、外部遷移先定義データベース１２０から外部遷移先候補となるワークフローシステムの外部遷移先定義情報を読み込み、この外部遷移先定義情報に基づき、外部遷移先ワークフローシステムを決定する（図１の(2)）。（Ｓ５０２）
【００７１】
次に、外部遷移送信部１１１は、送信データ選択部１１３に送信用の帳票データの作成を指示する（図１の(3)）。この指示により、送信データ選択部１１３は、外部遷移先ワークフローシステムの外部遷移先定義情報に基づき、選択ルール群１２３から適用する選択ルールを選択、取得する（図１の(4)）。送信データ選択部１１３は、取得した選択ルールに従って、帳票データベース１１０から送信する帳票レコードのフィールドを取得した（図１の(5)）後、取得した帳票レコードのフィールドを汎用データ形式に変換し、送信用の帳票データを作成して、外部遷移送信部に返す（図１の(6)）。（Ｓ５０３）
【００７２】
続いて、外部遷移送信部１１１は、外部遷移先定義データベース１２０に記録されている外部遷移先ワークフローシステムのサーバアドレスを利用して、通信ネットワークＮを通じて外部遷移先ワークフローシステムに接続し、外部遷移依頼を行う。このとき、送信データ選択部１１３が作成した汎用データ形式の帳票データを添付する（図１の(7)）。外部遷移送信部１１１はまた、外部遷移先ワークフローシステムのサーバアドレスやワークフロージョブＩＤなどを、外部遷移先管理データベース１２１に記録する（図１の(8)）。（Ｓ５０４）
【００７３】
また、外部遷移先ワークフローシステムにおいて、外部遷移元ワークフローシステムからの外部遷移依頼を受け付けた場合（Ｓ５１１のＹＥＳ）には、外部遷移元に関する情報を記録し（Ｓ５１２）、受け付けた汎用データ形式の帳票データを自システム用に変換する（Ｓ５１３）と共に、受け付けた外部遷移に対応するワークフロージョブの遷移を開始する（Ｓ５１４）。外部遷移先ワークフローシステムによるこの一連の処理（Ｓ５１１〜Ｓ５１４）の詳細は次の通りである。
【００７４】
まず、外部遷移先ワークフローシステムの外部遷移受信部１１２において、外部遷移元ワークフローシステムからの外部遷移依頼（図１の(9)）を受け付けた場合（Ｓ５１１のＹＥＳ）には、外部遷移受信部１１２は、外部遷移元ワークフローシステムのサーバアドレスやワークフロージョブＩＤなどを、外部遷移元管理データベース１２２に記録する（図１の(10)）。（Ｓ５１２）
【００７５】
次に、外部遷移受信部１１２は、受け付けた汎用データ形式の帳票データを帳票データ変換部１１４に渡す（図１の(11)）。帳票データ変換部１１４は、外部遷移元管理データベース１２２に記録された外部遷移元ワークフローシステムの情報に基づき、変換ルール群１２４から適用する変換ルールを選択、取得する（図１の(12)）。帳票データ変換部１１４は、取得した変換ルールに従って、受け付けた帳票データを、自システムの帳票データベース１１０に適合する形式やフィールドに変換し、帳票データベース１１０に格納する（図１の(13)）。（Ｓ５１３）
【００７６】
続いて、外部遷移受信部１１２は、受け付けた外部遷移に対応するワークフロージョブを作成し、ワークフロージョブの遷移を開始するようワークフロー駆動部１０１に指示する（図１の(14)）。（Ｓ５１４）
【００７７】
また、外部遷移先ワークフローシステムにおいて、外部遷移依頼の受け付けによるワークフロージョブが終了状態に達した場合（Ｓ５１５のＹＥＳ）には、外部遷移元の情報を取得し（Ｓ５１６）、フィールド限定した汎用データ形式の送信用の帳票データを作成して（Ｓ５１７）、外部遷移元に外部遷移戻り依頼を行う（Ｓ５１８）。外部遷移先ワークフローシステムによるこの一連の処理（Ｓ５１５〜Ｓ５１８）の詳細は次の通りである。
【００７８】
まず、外部遷移先ワークフローシステムのワークフロー駆動部１０１において、外部遷移依頼の受け付けにより開始したワークフロージョブが終了状態に達した場合（Ｓ５１５のＹＥＳ）には、ワークフロー駆動部１０１は、外部遷移を戻すことを外部遷移送信部１１１に指示する（図２の(1)）。この指示により、外部遷移送信部１１１は、外部遷移元管理データベース１２２から外部遷移元ワークフローシステムの情報を取得する（図２の(2)）。（Ｓ５１６）
【００７９】
次に、外部遷移送信部１１１は、送信データ選択部１１３に送信用の帳票データの作成を指示する（図２の(3)）。この指示により、送信データ選択部１１３は、外部遷移元ワークフローシステムの情報に基づき、選択ルール群１２３から適用する選択ルールを選択、取得する（図２の(4)）。送信データ選択部１１３は、取得した選択ルールにしたがって、帳票データベース１１０から送信する帳票レコードのフィールドを取得した（図２の(5)後、取得した帳票レコードのフィールドを汎用データ形式に変換し、送信用の帳票データを作成して、外部遷移送信部に返す（図２の(6)）。（Ｓ５１７）
【００８０】
続いて、外部遷移送信部１１１は、外部遷移元管理データベース１２２に記録されている外部遷移元ワークフローシステムのサーバアドレスを利用して、通信ネットワークＮを通じて外部遷移元ワークフローシステムに接続し、外部遷移戻り依頼を行う。このとき、送信データ選択部１１３が作成した汎用データ形式の帳票データを添付する（図２の(7)）。（Ｓ５１８）
【００８１】
また、外部遷移元ワークフローシステムにおいて、外部遷移先ワークフローシステムからの外部遷移戻り依頼を受け付けた場合（Ｓ５０５のＹＥＳ）には、外部遷移先の情報を取得し（Ｓ５０６）、受け付けた汎用データ形式の帳票データを自システム用に変換する（Ｓ５０７）と共に、受け付けた外部遷移戻りに対応するワークフロージョブの遷移を開始する（Ｓ５０８）。外部遷移元ワークフローシステムによるこの一連の処理（Ｓ５０５〜Ｓ５０８）の詳細は次の通りである。
【００８２】
まず、外部遷移元ワークフローシステムの外部遷移受信部１１２において、外部遷移先ワークフローシステムからの外部遷移戻り依頼（図２の(8)）を受け付けた場合（Ｓ５０５のＹＥＳ）には、外部遷移受信部１１２は、外部遷移先管理データベース１２１から、受け付けた外部遷移戻りに対応するワークフロージョブＩＤや外部遷移先ワークフローシステムの情報を取得する（図２の(9)）。（Ｓ５０６）
【００８３】
次に、外部遷移受信部１１２は、受け付けた汎用データ形式の帳票データを帳票データ変換部１１４に渡す（図２の(10)）。帳票データ変換部１１４は、外部遷移先定義データベース１２０と外部遷移先管理データベース１２１に記録された外部遷移先ワークフローシステムの情報に基づき、変換ルール群１２４から適用する変換ルールを選択、取得する（図２の(11)）。帳票データ変換部１１４は、取得した変換ルールに従って、受け付けた帳票データを、自システムの帳票データベース１１０に適合する形式やフィールドに変換し、帳票データベース１１０に格納する（図２の(12)）。（Ｓ５０７）
【００８４】
続いて、外部遷移受信部１１２は、受け付けた外部遷移戻りに対応するワークフロージョブを次の状態に遷移させるようワークフロー駆動部１０１に指示する（図２の(13)）。（Ｓ５０８）
【００８５】
［５．外部遷移先の選択］
以下には、図５に示す外部遷移の動作フローのうち、外部遷移先を選択する処理（Ｓ５０２）を行うための具体的なデータとそれに基づく選択方法について説明する。
【００８６】
［５−１．外部遷移先定義データベース］
外部遷移先を選択するために、本実施形態においては、前述したように、外部遷移先定義データベース１２０を使用している。すなわち、本実施形態のワークフロー連携システムは、連携が必要となるワークフローシステムが流動的であり、ワークフロー定義などで固定的に定義できない場合に対応するために、外部遷移を行うために必要なワークフローシステムの情報を、外部遷移先定義情報として、外部遷移先定義データベース１２０に格納したものである。
【００８７】
次の表３は、外部遷移先定義データベース１２０に記録されるデータの具体的なデータ構造の一例を示している。
【表３】
2005190280.tif 000005
【００８８】
この外部遷移先定義データベース１２０には、外部遷移先のワークフローシステムのサーバにネットワークを介して接続するためのサーバアドレス、サーバ内に複数のワークフローシステムが存在する場合に目的のワークフローシステムを識別するための識別情報、ワークフローシステムと接続するためのログインＩＤ／パスワード、などが定義されている。ここで、サーバアドレスは、ワークフローシステムと接続するための情報として使用されるが、それに加えて、ワークフローシステムの識別情報と共に、ワークフローシステムを特定するための情報としても使用される。
【００８９】
［５−２．外部遷移先の具体的な選択方法］
ワークフロージョブを外部遷移する際に、外部遷移先定義データベース１２０に基づいて外部遷移先ワークフローシステムを選択するための方法としては、多様な方法が考えられるが、代表的な方法としては、次のような３つの選択方法（１）〜（３）が挙げられる。外部遷移先を選択する処理においては、これらの選択方法のいずれかを使用してもよいし、あるいはまた、３つの選択方法（１）〜（３）の中から、状況に応じた選択方法の使用を決定してもよい。
【００９０】
（１）ユーザが外部遷移先定義データベース１２０から直接選択する方法：
ワークフロージョブが外部遷移する際に、ユーザに外部遷移先定義データベース１２０に格納されているワークフローシステムを提示し、遷移先を直接選択させる方法である。
【００９１】
（２）帳票データベース１１０と外部遷移先定義データベース１２０との関連付けをする方法：
帳票データベース１１０のあるフィールドの値と外部遷移先定義データベース１２０のワークフローシステムを関連付けることにより、帳票データベース１１０のフィールドの値から、自動的に外部遷移先定義データベース１２０のワークフローシステムを選択する方法である。
【００９２】
例えば、帳票データベース１１０にフィールド「原因モジュール」の値が「ブラウザ」と登録されており、外部遷移先定義データベース１２０にブラウザチームのワークフローシステムが定義されている場合には、その帳票データベース１１０のフィールド「原因モジュール」の値から、ブラウザチームのワークフローシステムを自動的に選択する。
【００９３】
（３）外部遷移先ワークフローシステムを直接登録する方法：
外部遷移先定義データベース１２０に未登録のワークフローシステムに外部遷移させたいユーザが、その未登録のワークフローシステムを新規に登録した場合に、登録されたワークフローシステムを自動的に選択する方法である。
【００９４】
［６．送信用の帳票データの作成］
以下には、図５に示す外部遷移の動作フローのうち、送信用の帳票データを作成する処理（Ｓ５０３、Ｓ５１７）を行うための具体的な選択ルールとその選択方法について説明する。
【００９５】
［６−１．選択ルール］
外部遷移先に送信するデータの秘匿性を確保するためには、外部遷移先ごとに送信できるフィールドを定義することにより秘匿性は守られるが、外部遷移先を個別に定義する場合に、個々の遷移先ごとに送信するフィールドを定義することはメンテナンス性を低下させる。
【００９６】
そのため、本実施形態においては、前述したように、選択ルール群１２３として、送信するフィールドをルールとして予め定義し、ワークフロー条件情報に対応付けた複数の選択ルールを使用し、外部遷移先に適用される選択ルールを外部遷移先ワークフローシステム（外部遷移の戻り時は外部遷移元ワークフローシステム）の情報に基づいて選択するようにしている。なお、「ワークフロー条件情報」は、選択ルールの適用先となりうるワークフローシステムの条件を表現する情報を意味している。
【００９７】
次の表４は、選択ルール群１２３として使用される選択ルールの具体的なデータ構造の一例を示している。
【表４】
2005190280.tif 000006
【００９８】
この表４に示すように、選択ルールに対応付けるワークフロー条件情報として、ワイルドカード「＊」などの読み替え可能な部分を含む文字列を用いることにより、個々の外部遷移先に１対１に対応するルール定義ではなく、複数の遷移先をカバーする柔軟な選択ルールを定義することができる。
【００９９】
［６−２．選択ルールの選択方法］
上記のように、ワイルドカードなどの読み替え手法を用いた場合には、単一の外部遷移先に対して複数の選択ルールが候補となる可能性がある。以下には、そのような場合に、より適切な選択ルールを選択する方法について説明する。
【０１００】
一般的に、外部遷移先を特定するための情報としては、複数種類の情報が存在している。例えば、表２の例において、外部遷移先は、外部遷移先サーバアドレス、ワークフローシステムの識別情報、という２種類の情報によって特定されているが、１台のサーバに複数のシステムがあり、各システムが複数のワークフローを持っている可能性もある。このように、１つの外部遷移先ワークフローシステムを表すデータは、一般的に、複数存在する。このような場合には、対象となるワークフローシステムを最も特徴付ける情報が最優先されることが望ましい。
【０１０１】
そのため、ワークフローシステムを特定する情報の順序付けは、利用者によって定義される必要がある。そのような順序付けが行われた段階で、次に示すような数式を用いて、外部遷移先ワークフローシステム（外部遷移の戻り時は外部遷移元ワークフローシステム）に対する、ルール定義の情報の重み値を算出し、その合計を求める。合計が最大であるルールが最も有効なルールとなる。
【数１】
2005190280.tif 000007
【０１０２】
このようなルールの選択方法について、図６に示す例を用いて具体的に説明する。図６に示す例において、ワークフローシステムは、サーバ、システム、ワークフローシステムという３つの情報から定義される。ここでは、
サーバ  ＞  システム  ＞  ワークフローシステム、
の順で、情報が重要視されるものとする。
【０１０３】
図６に示すワークフローシステムの各情報の重み値を、上記の数式に従って算出すると、次の表５に示すようになる。
【表５】
2005190280.tif 000008
【０１０４】
次に、これらの重み値を用いて、各選択ルールの重み値を計算する。ここでは、一例として、次の表６に示すような選択ルールが定義されているものとする。
【表６】
2005190280.tif 000009
【０１０５】
これらの選択ルールについて、図６に示すワークフローシステムwf_β(サーバ=wf.toshiba.co.jp、システム=system_A)に外部遷移する際に各選択ルールの重み値を算出した結果は、次の表７に示すようになる。
【表７】
2005190280.tif 000010
【０１０６】
なお、このように重み値を算出する際、一つでも一致しない項目があれば、そのルールは選択候補から除外するものとする。そして、残った候補のうち、もっとも重み値の合計が大きいルールが選択される。図６、表６、表７に示す例では、選択ルールrule_2が選択される。
【０１０７】
なお、以上のような手法で選択ルールを選択するためには、外部遷移先ワークフローシステム（外部遷移の戻り時は外部遷移元ワークフローシステム）の情報を得る必要がある。本実施形態において、外部遷移時の外部遷移先ワークフローシステムについての情報は、外部遷移先定義データベース１２０から取得することができる。また、外部遷移の戻り時における外部遷移元ワークフローシステムの情報は、外部遷移の受付時に、外部遷移元ワークフローシステムの情報を記録しておき、そのデータを用いる必要がある。本実施形態では、前述したように、このような外部遷移元ワークフローシステムの情報を、外部遷移の受付時に外部遷移元管理データベース１２２に記録しているため、この外部遷移元管理データベース１２２に記録されたデータを外部遷移の戻り時に利用することができる。
【０１０８】
［７．受け付けた帳票データの変換］
以下には、図５に示す外部遷移の動作フローのうち、受け付けた帳票データを変換する処理（Ｓ５０７、Ｓ５１３）を行うための具体的な変換ルールとその選択方法について説明する。
【０１０９】
［７−１．変換ルール］
外部遷移先と外部遷移元のワークフローシステムは、概して、異なるシステムであるため、帳票データベース１１０のフィールドやデータ型などが同じであるとは限らない。そのため、本実施形態においては、外部遷移時や外部遷移戻り時に、送信する帳票データを、汎用データ形式の帳票データに変換すると共に、外部遷移受付時や、外部遷移戻り受付時には、受け取った帳票データを、自システムの帳票データベースに格納できる形式に変換するようにしている。
【０１１０】
すなわち、本実施形態においては、帳票データを自システムの帳票データベース１１０に格納できる形式に変換するために、変換ルールとして、次のような２種類の変換「フィールドのマッピング」、「データ型の変換」を、外部遷移先と外部遷移元の組み合わせに関する組み合わせ条件情報と対応付けて定義している。なお、「組み合わせ条件情報」は、変換ルールの適用先となりうる外部遷移先と外部遷移元のワークフローシステムの組み合わせ条件を表現する情報を意味している。
【０１１１】
（１）フィールドのマッピング：
外部遷移元のフィールドと外部遷移先のフィールドのマッピングである。
（２）データ型の変換：
外部遷移元と外部遷移先のマッピングされたフィールドで、フィールド型が異なる場合のデータ型の変換である。
【０１１２】
このうち、「データ型の変換」についてより詳細に説明する。例えば、外部遷移元における「数値型」のフィールドのデータを、外部遷移先で「文字列型」のフィールドに代入する場合には、数値を文字列に変換する必要がある。また、図７に示すような選択型（複数の選択候補から１つを選択し、ＩＤでデータを格納するようなデータ型）のフィールドを文字列型のフィールドに格納する場合は、表示値を格納したい場合もあるし、ＩＤを格納したい場合もある。さらに、フィールドの組合せによっては変換できないものもある。例えば、文字列を数値型のフィールドには格納できない。そのような場合は、「Null」データにするか、エラーにするなど対応もさまざまである。
【０１１３】
［７−２．変換ルールの選択方法］
前述した選択ルールと同様に、変換ルールについても、変換ルールに対応付ける組み合わせ条件情報として、ワイルドカード「＊」などの読み替え可能な部分を含む文字列を用いることで、柔軟に設定できる。複数の変換ルールから適用するルールを選択する手順は、選択ルールと同様である。
【０１１４】
次の表８は、ワイルドカード「＊」を用いた変換ルールの定義の一例を示している。
【表８】
2005190280.tif 000011
【０１１５】
なお、変換ルールを選択するには、外部遷移元ワークフローシステム（外部遷移戻り受付時は外部遷移先ワークフローシステム）の情報を得る必要がある。本実施形態においては、前述したように、外部遷移受付時には、外部遷移元管理データベース１２２を利用することができる。また、外部遷移戻り受付時には、外部遷移先管理データベース１２１と外部遷移先定義データベース１２０を利用することができる。
【０１１６】
また、変換ルールにより上記のようなような２種類の変換「フィールドのマッピング」、「データ型の変換」を変行うためには、送信される帳票データは、以下のデータを持った汎用的なデータ形式である必要がある。
「帳票データ：
フィールド名、フィールド型、値、表示値」
【０１１７】
すなわち、本実施形態における「汎用データ形式の帳票データ」はも、少なくとも、このようなデータを持った汎用的なデータ形式の帳票データを意味している。
【０１１８】
［８．実施形態の作用効果］
以上のような本実施形態のワークフロー連携システムによれば、外部遷移先となりうる各ワークフローシステムについて、当該ワークフローシステムの外部遷移先定義情報を外部遷移先定義データベース１２０に格納することで、各ワークフローシステムを予め登録することにより、いずれかのワークフローシステムの状態を外部遷移させる場合には、外部遷移先定義情報に基づいて外部遷移先を柔軟に選択することができる。このような本実施形態の手法は、各種の分野におけるワークフローシステムの連携に適用可能であるが、特に、ソフトウェア開発における不具合管理システムに好適であり、製品に組み込まれたソフトウェア部品の不具合管理を、製品の不具合管理と連動して効率よく行うことができる。
【０１１９】
また、外部遷移時または外部遷移戻り時には、複数の選択ルールの中から送信先のワークフローシステムに応じた適切な選択ルールを選択して、フィールドを限定した帳票データを送信することができるため、異なる組織や会社間でデータを送信する場合においても、データの秘匿性を確保することができる。
【０１２０】
また、外部遷移依頼または外部遷移戻り依頼の受付時には、複数の変換ルールの中から依頼元のワークフローシステムと自ワークフローシステムの組み合わせに応じた適切な変換ルールを選択して、受け付けた帳票データを自システムで利用可能な帳票データに変換することができるため、連携するシステム間で異なる帳票フィールドを持つ場合においても、連携先のデータを確実に利用することができる。
【０１２１】
さらに、選択ルールや変換ルールについては、個々の外部遷移先または外部遷移元ごとに個別のルールを定義するのではなく、適用先となりうるワークフローシステムやその組み合わせの条件と対応付けして、それらの条件に、ワイルドカードなどの読み替え手法を用いることにより、複数の適用先をカバーする柔軟なルールを定義することができる。したがって、適用するルールを柔軟に選択することができるため、送信する帳票データの作成や受け付けた帳票データの変換を柔軟に行うことができる。
【０１２２】
［９．外部遷移先管理サーバを用いた変形例］
前記の実施形態の変形例として、外部遷移に必要な各種の情報を個々のワークフローシステムで管理する代わりに、複数のワークフローシステムに共通の外部遷移先管理サーバで一元的に管理する構成も可能である。
【０１２３】
図８は、そのような外部遷移先管理サーバ８００の一例を示す図であり、この外部遷移先管理サーバ８００は、外部遷移先定義データベース８０１、共通フィールド定義データベース８０２、共通フィールドとのマッピングデータベース８０３、共通フィールドの選択肢データベース８０４、等を備えている。外部遷移先管理サーバ８００は、それらのデータベース８０１〜８０４に格納された情報を管理することにより、外部遷移元８１０と外部遷移先８２０との間の外部遷移を管理するようになっている。各データベース８０１〜８０４の詳細は次の通りである。
【０１２４】
外部遷移先定義データベース８０１には、外部遷移先となりうるワークフローシステムを定義した外部遷移先定義情報が格納されることで、各ワークフローシステムが予め登録されている。この外部遷移先定義情報には、外部遷移先のワークフローシステムのＵＲＬや認証情報などが含まれる。なお、個々のワークフローシステムは、外部遷移先管理サーバへのアクセス認証だけできれば、外部遷移先の他サーバへの認証情報を個々に管理する必要がなくなる。
【０１２５】
共通フィールド定義データベース８０２には、外部遷移先定義データベース８０１に登録されたワークフローシステムをカバーするための汎用的な共通フィールドを定義した共通フィールド定義情報が格納されることで、各共通フィールドが登録されている。共通フィールドとのマッピングデータベース８０３には、共通フィールド定義データベース８０２に登録された共通不イールド定義と個々のワークフローシステムで使用されている個別のフィールドとのマッピングが定義されている。
【０１２６】
すなわち、前記実施形態について説明したように、個々のワークフローシステムが持つ帳票データベースのフィールドは、ワークフローシステムごとに異なる可能性があるため、外部遷移時に変換する必要がある。図８の外部遷移先管理サーバ８００においては、変換元と変換先の組み合わせごとにフィールドをマッピングすることによる設定の複雑化を回避するために、共通フィールドを定義し、共通フィールドと個別のフィールドのマッピングのみを定義している。
【０１２７】
共通フィールドの選択肢定義データベース８０４には、共通フィールド定義データベース８０２に登録された共通フィールドの共通の選択肢が定義されている。選択肢を共通にしないと分析ができない場合があるため、確実に分析できるようにするために定義された情報である。
【０１２８】
次の表９〜表１１は、各データベース８０１〜８０３に保存されるデータ構造の一例を示しており、表９は、外部遷移先定義情報の例、表１０は、共通フィールド定義情報の例、表１１は、共通フィールドとのマッピング定義の例、をそれぞれ示している。
【０１２９】
【表９】
2005190280.tif 000012
【０１３０】
【表１０】
2005190280.tif 000013
【０１３１】
【表１１】
2005190280.tif 000014
【０１３２】
なお、外部遷移元８１０または外部遷移先８２０となるワークフローシステムと外部遷移先管理サーバ８００との間の具体的な動作は次の通りである。
【０１３３】
外部遷移時において、外部遷移元８１０となるワークフローシステムは、外部遷移先管理サーバ８００にアクセスして、外部遷移先８２０となりうるワークフローシステムの外部遷移先定義情報を取得する。また、外部遷移先８２０のワークフローシステムは、外部遷移受付時において、外部遷移先管理サーバ８００にアクセスして、変換ルールを取得する。
【０１３４】
外部遷移先８１０のワークフローシステムは、外部遷移戻り時において、外部遷移先管理サーバ８００にアクセスして、外部遷移戻り先の外部遷移先定義情報を取得する。また、外部遷移元８２０のワークフローシステムは、外部遷移戻り受付時において、外部遷移先管理サーバ８００にアクセスして、変換ルールを取得する。
【０１３５】
さらに、ソフトウェア開発における不具合管理システムに適用する場合には、その不具合管理システムは、不具合登録時に、外部遷移先管理サーバ８００にアクセスして、共通フィールドの選択肢を取得し、自システムにコピーする。
【０１３６】
なお、外部遷移先管理サーバ８００から取得される変換ルールは、図９に示すようにして、「共通フィールド定義」、「共通フィールドとのマッピング」から生成される。
【０１３７】
以上のような図８の外部遷移先管理サーバ８００によれば、次のような作用効果が得られる。すなわち、前記の実施形態においては、外部遷移先の定義として、サーバごとに遷移先を設定していたことから、同様の設定を複数のサーバに設定する必要があり、設定が複雑になる。これに対して、図８の外部遷移先管理サーバ８００によれば、外部遷移先の設定を一元管理することができるため、多数のワークフローシステム間における外部遷移を実現するための情報設定を簡略化することができ、個々のワークフローシステムにおいて管理するデータ量を少なくすることができる。したがって、ワークフロー連携システム全体として、ワークフロー連携を効率よく実現することが可能となる。
【０１３８】
［１０．他の実施形態］
なお、本発明は、前述した実施形態に限定されるものではなく、本発明の範囲内で他にも多種多様な変形例が実施可能である。すなわち、前記実施形態で示したワークフロー連携システムの構成や処理手順、データ構造等は、一例にすぎず、具体的な構成や処理手順、データ構造等は自由に変更可能である。
【０１３９】
また、本発明は、前述した通り、ソフトウェア開発における不具合管理システムに好適であるが、それに限らず、他の各種の分野のワークフローシステム間の連携に同様に適用可能である。すなわち、他の分野のワークフローシステム間の連携においても、連携先のワークフローシステムが予め確定していない場合や、異なる組織や会社間でデータを送信する場合における各種のワークフローシステムを連携させる場合には、本発明を適用することで同様に優れた作用効果が得られるものである。
【図面の簡単な説明】
【０１４０】
【図１】本発明を適用した１つの実施形態に係るワークフロー連携システムの構成と外部遷移時のデータの流れを示すブロック図。
【図２】図１に示すワークフロー連携システムにおける外部遷移戻り時のデータの流れを示すブロック図。
【図３】図１に示すワークフロー定義の一例を示す状態遷移図。
【図４】図１に示すワークフロー連携システムによるワークフローシステムの連携例を示す図。
【図５】図１に示すワークフロー連携システムにおいて、ワークフローシステム間で外部遷移させる場合の処理手順を示すフローチャート。
【図６】図５に示す「送信用の帳票データの作成」時における選択ルールの選択方法を説明するためにワークフローシステムの階層情報の一例を示す図。
【図７】図５に示す「受け付けた帳票データの変換」時において使用する変換ルールを説明するために、選択型のデータの一例を示す図。
【図８】図１に示すワークフロー連携システムの変形例に使用される外部遷移先管理サーバの一例を示すブロック図。
【図９】図８に示す外部遷移先管理サーバによる変換ルールの生成例を示す図。
【図１０】汎用的なソフトウェア部品を含むソフトウェア製品の一例を示す図。
【図１１】図１０に示す製品の開発形態において、複数製品の不具合管理システムと開発者との関係の一例を示す図。
【図１２】複数の不具合管理システムの連携例を示す図。
【図１３】図１２に示すように連携した不具合管理システム間のワークフローの連携例を示す図。
【符号の説明】
【０１４１】
Ｎ…通信ネットワーク
１００…自ワークフローシステム
１０１…ワークフロー駆動部
１０２…ワークフロー定義
１０３…状態管理データベース（ＤＢ）
１１０…帳票データベース（ＤＢ）
１１１…外部遷移送信部
１１２…外部遷移受信部
１１３…送信データ選択部
１１４…帳票データ変換部
１２０…外部遷移先定義データベース（ＤＢ）
１２１…外部遷移先管理データベース（ＤＢ）
１２２…外部遷移元管理データベース（ＤＢ）
１２３…選択ルール群
１２４…変換ルール群
【図１】
2005190280.tif 000015
【図２】
2005190280.tif 000016
【図３】
2005190280.tif 000017
【図４】
2005190280.tif 000018
【図５】
2005190280.tif 000019
【図６】
2005190280.tif 000020
【図７】
2005190280.tif 000021
【図８】
2005190280.tif 000022
【図９】
2005190280.tif 000023
【図１０】
2005190280.tif 000024
【図１１】
2005190280.tif 000025
【図１２】
2005190280.tif 000026
【図１３】
2005190280.tif 000027