JP2005056115A - ワークフロー間連携装置とそのプログラム、及びワークフロー処理方法 - Google Patents

Abstract

【課題】複数のワークフローシステム間でシステムの依存性を排除し、これによりシステムごとに独立して設定したライフサイクルの異なるセッションを自在に連携可能にする。
【解決手段】発注側システムＡＳと受注側システムＢＳ１〜ＢＳｎとの間に、受信口ＲＸ１〜ＲＸｍと、送信口ＴＸ１〜ＴＸｍと、セッション管理テーブルＤＢと、サーバ選択部ＳＳとを備えた受注側連携装置ＷＲａ，ＷＲｂを設ける。そして、セッション抽出ルールにより抽出した情報をもとに発注側システムＡＳが使用するセッションを特定し、この情報をキーとしてセッション管理テーブルＤＢから受注側システムＢＳ１〜ＢＳｎのセッション識別子を読み出して、接続先のサーバ装置ＳＶ１〜ＳＶｉ，ＳＶ１〜ＳＶｊにセッションの実行を要求するようにしている。
【選択図】 図２

Description

この発明は、互いに独立したセッションを使用してワークフロー処理を実行する第１及び第２のシステム間で例えば商取引に関する処理を実行する場合に、上記第１及び第２のシステム間に介在配置されるワークフロー間連携装置とそのプログラム、及びこの装置を使用したワークフロー処理方法に関する。

現在、ウエブサービス等の分野を中心に、企業間の取引における定型業務の自動化を目的とした商取引の電子化が進んでいる。例えば、企業Ａが発注側となり、企業Ｂが受注側となって受発注処理を行う場合、先ず企業Ａが見積依頼を行い、次に企業Ｂがこれに応じ見積書を送り、その後企業Ａが発注書を送付し、それを受けた企業Ｂが受注確認書を送付し、最終的に納品書と共に納品を行う処理になる。

上記処理は企業Ａ−Ｂ間の文書交換手順であるが、企業Ａの観点で見ると、見積依頼に先立ち購入に関する社内決裁等があるのが一般的である。社内決裁は、一般に起票者→決裁者１→決裁者２のように、いわゆるワークフローを伴う。同様に企業Ｂの観点で見ると、見積依頼書を受けた場合、割引率の決定等に社内決裁が必要となる場合や、在庫確保のための処理や決裁が必要となる場合がある。
このように企業間取引は、企業Ａ内のワークフロー、企業Ｂ内のワークフロー及び企業Ａ−Ｂ間のワークフローが互いに連携しながら、一連の処理を達成していくものであると言える。

ここにワークフローとは、ある仕事を複数回の通信により達成することが特徴であり、通常、複数の人物が同一の仕事に対し次々と関与する。このため、ワークフロー処理システムは、ある仕事に関連する情報をシステム内に保持し、一連の通信において各処理が同一の仕事に関する情報を共有する機能を備える。この複数の通信を束ねる単位をセッションと呼び、ある仕事に付随する情報をセッション情報と呼ぶ。セッション情報は、セッション識別子やサーバ識別子、業務固有の情報等を含む。

以下、文書の交換において、文書を送る側を送信側、受ける側を受信側とそれぞれ呼ぶものとする。先に述べた見積依頼書の場合、企業Ａが送信側となり、企業Ｂが受信側となっており、見積書の場合には反対に企業Ａが受信側、企業Ｂが送信側となっている。上記のように一連の仕事が複数回の通信によって達成される処理を行う場合、従来では通信に先立ち予め送信側がセッションの発行を受信側に依頼し、セッション識別子と呼ばれる識別子を取得する。そして、次回以降の通信において、送信側は通信プロトコル上のヘッダ領域に上記セッション識別子を挿入することにより、ある通信が特定のセッションに関連したものであることを識別していた。

すなわち、受信側システムのセッションの生成及び削除を、送信側システムが明示的に制御していた。さらに換言すると、受信側システムの設計を送信側システムが意識し、明示的にセッションのライフサイクル管理を行う必要がある。例えば、送信側システムは、受信側となるサーバに対しオブジェクト（セッション）の生成を依頼し、その結果のオブジェクト・リファレンス（セッション識別子）を受け取る。次回以降の通信では、この受け取ったオブジェクト・リファレンスを受信側に渡すことにより、一連の通信が互いに関連したものであることを識別する（例えば、非特許文献１を参照。）。

「Common Object Request Broker Architecture:Core Specification Version3.0.2」、ＯＭＧ、［online］、２００２年１２月２日掲載、［２００３年５月６日検索］、インターネット<URL:http://www.omg.org/cgi-bin/doc?formal/02-12-02.pdf>

ところが、このような従来のシステムでは以下の問題点がある。
（１）処理に先立ちセッション生成という前処理が必要であるため、通信のオーバヘッドが存在する。
（２）従来のシステムでは、クライアントがセッション発行要求を行い、サーバがセッション発行を行っていた。つまり、セッションには主従関係があり、相手システムのセッションのライフサイクルを意識してクライアント側のプログラムを作る必要がある。

例えば、図１１及び図１２に示す例は、受注側のシステムが一つのモジュールの場合と、二つのモジュールで構成されている場合を示すものであるが、発注側のシステムが受注側のシステムに合わせてセッション発行要求を行う必要があることを示している。図１１の場合、発注側システムではnew OrderServiceというセッション確立処理を実行しているが、図１２の場合、受注側システムに合わせてnew EstimateService，new OrderServiceなる二つのセッションを発注側システムが意識する必要がある。
本来、対等な立場である企業間の取引において、セッション管理に関しては相手システムの設計を意識する必要があるため、たとえ文書の交換手順が同一であっても、取引先のシステム設計毎に自社システムの設計を変更する必要がある。

（３）セッション識別子発行や、セッションに関連した処理要求等のセッション管理の仕組みは、一般に利用するミドルウェア（例えばＣＯＲＢＡ）に依存する。そのため、各企業で使用するミドルウェアの選定に制限があった。
この発明は上記事情に着目してなされたもので、その目的とするところは、複数のワークフローシステム間で、互いのシステムの依存性を排除して互いが独立してセッションを設定できるようにしたワークフロー間連携装置とそのプログラム、及びワークフロー処理方法を提供することにある。

上記目的を達成するためにこの発明は、互いに独立したセッションを使用してワークフロー処理を実行する第１及び第２のシステム間に、ワークフロー間連携装置を介在設置し、このワークフロー間連携装置に、セッション生成の要否が予め設定されかつ上記第２のシステムが実行する複数の処理にそれぞれ対応して設けられた複数の受信部と、上記複数の受信部により共有されるセッション管理テーブルとを設ける。
そして、上記各受信部において、第１のシステムから送信された第１のファイルを受信し、受信された第１のファイル中から予め定めたルールに従い第１のシステムが使用するセッションに相当する情報を抽出する。また、セッションの生成が必要な場合に、第２のシステムに対しセッションの生成を要求して当該第２のシステムから第２のシステムが使用するセッションを示す情報を取得し、この取得された第２のシステムが使用するセッションを示す情報と、上記抽出された第１のシステムが使用するセッションに相当する情報とを相互に対応付けて、上記セッション管理テーブルに記憶させる。一方、セッションの生成が不要な場合には、上記抽出された第１のシステムが使用するセッションに相当する情報をもとに上記セッション管理テーブルを検索して、第２のシステムが使用するセッションを示す情報を読み出し、この読み出された第２のシステムが使用するセッションを示す情報に従い、セッションの実行要求及び上記受信された第１のファイルを第２のシステムに対し送信するようにしたものである。

したがってこの発明によれば、ワークフロー間連携装置において、第１のシステムから送信された文書等の第１のファイルから所定のセッション抽出ルールにより第１のシステムが使用するセッションに相当する情報が抽出され、この抽出された情報が第２のシステムが使用するセッションと対応付けられる。そして、以後この対応をもとにセッションの連携を保ちつつ第１のシステムから第２のシステムへのファイル転送が行われる。このため、第１のシステムは、送受信するファイルのフォーマットについてのみ合意すればよく、セッション識別子を明示的に意識する必要がなくなる。その結果、第１のシステムは第２のシステムの構成を意識する必要がなくなり、互いのシステムの独立性を保つことができる。

またこの発明は、ワークフロー間連携装置に、上記複数の受信部と対をなしかつセッション管理テーブルを共有するように設けられる複数の送信部をさらに設ける。そして、これらの送信部において、第２のシステムから送信された第２のファイルを受信し、受信された第２のファイル中から予め定めたルールに従い第１のシステムが使用するセッションに相当する情報を抽出する。そして、この抽出された第１のシステムが使用するセッションを示す情報と、第２のシステムが使用するセッションを示す情報とを相互に対応付けてセッション管理テーブルに記憶させ、以後この記憶された情報をもとに第１のシステムと第２のシステムとの間のファイル転送を実施することも特徴とする。
このように各送信部にもセッション相当情報の抽出機能を持たせることで、第２のシステムが複数種の処理を共通のセッションを用いて実行する場合でも、第１のシステムはそのことを意識することなくファイルの送受信が可能となる。

さらにこの発明は、第２のシステムが複数のコンピュータを備える場合に、これらのコンピュータを所定の負荷分散アルゴリズムに従い選択する機能を有するコンピュータ選択部をさらに設ける。そして、各受信部において、セッションの生成が必要な場合に上記コンピュータ選択部に対しコンピュータの選択を要求して、選択されたコンピュータを示す情報を受け取り、この受け取った情報をもとに、上記選択されたコンピュータに対しセッションの生成を要求して、当該コンピュータから第２のシステムが使用するセッションを示す情報を受け取ることも特徴とする。
このようにコンピュータ選択部をさらに設けることで、第１のシステムからの処理要求が複数のコンピュータに均等に分散されることになり、これにより第２のシステムにおいて処理要求が特定のコンピュータに集中する不具合を解消して、ワークフローの処理効率を高めることができる。

要するにこの発明によれば、複数のワークフロー処理システム間で複数回の通信を行うことで一つの仕事を達成する場合に、各システムが独立して設定したライフサイクルの異なるセッションを自在に連携させることができ、これにより互いのシステムの依存性を排除してシステムの独立性を保持することを可能にしたワークフロー間連携装置とそのプログラム、及びワークフロー処理方法を提供することができる。

図１は、この発明に係わるワークフロー処理システムの一実施形態である企業間受発注処理システムを示す概略構成図である。
このシステムは、発注側システムＡＳと、複数の受注側システムＢＳ１〜ＢＳｎとの間を、通信ネットワークＮＷを介して相互に接続すると共に、発注側システムＡＳ及び受注側システムＢＳ１〜ＢＳｎに対応付けて連携装置ＷＲａ，ＷＲｂを設けたものである。

発注側システムＡＳは、企業内における発注者や決裁者等が使用する複数のクライアント端末ＣＬ１〜ＣＬｋを有し、これらのクライアント端末ＣＬ１〜ＣＬｋは例えばＬＡＮ介して上記通信ネットワークＮＷに接続される。受注側システムＢＳ１〜ＢＳｎはそれぞれ見積管理や受注管理等の異なるアプリケーションを実行するもので、いずれも複数のサーバ装置ＳＶ１〜ＳＶｉ，ＳＶ１〜ＳＶｊを備える。

発注側連携装置ＷＲａ及び受注側連携装置ＷＲｂはそれぞれ、通信の相手側となる受注側システムＢＳ１〜ＢＳｎ及び発注側システムＡＳとの間でセッションの連携をとるもので、例えば次のような機能を備えている。図２はその構成を示すブロック図である。なお、発注側連携装置ＷＲａ及び受注側連携装置ＷＲｂは同一構成なので、ここでは受注側連携装置ＷＲｂを例にとって説明する。

受注側連携装置ＷＲｂは、複数の受信口ＲＸ１〜ＲＸｍと、これらの受信口ＲＸ１〜ＲＸｍと対をなす複数の送信口ＴＸ１〜ＴＸｍと、上記受信口ＲＸ１〜ＲＸｍ及び送信口ＴＸ１〜ＴＸｍにより共有されるセッション管理テーブルＤＢと、サーバ選択部ＳＳとを備えている。

受信口ＲＸ１〜ＲＸｍは、発注側システムＡＳから送られた文書を受信して受注側システムＢＳ〜ＢＳｎへ転送するもので、各受信口ＲＸ１〜ＲＸｍにはそれぞれ受信された文書中の特定の位置から文字列を抽出するためのセッション抽出ルールが対応付けられている。また受信口ＲＸ１〜ＲＸｍには、セッション生成の要否を表すセッション生成フラグと、受注側システムＢＳ１〜ＢＳｎが実行する複数のアプリケーションを表すアプリケーション識別子も対応付けられている。

送信口ＴＸ１〜ＴＸｍは、受注側システムＡＳから送り出された文書を受け取って発注側システムに向け送信するもので、各送信口ＴＸ１〜ＴＸｍにはそれぞれ受注側システムＡＳから受け取った文書中の特定の位置から文字列を抽出するためのセッション抽出ルールが対応付けられている。

上記受信口ＲＸ１〜ＲＸｍ及び送信口ＴＸ１〜ＴＸｍに対するセッション抽出ルール、セッション生成フラグ及びアプリケーション識別子の対応付けは、システム管理者により予め設定される。また、上記受信口ＲＸ１〜ＲＸｍ及び送信口ＴＸ１〜ＴＸｍに対しＵＲＩ（Uniform Resource Identifier）等により割り当てられるアドレス、受信口ＲＸ１〜ＲＸｍ及び送信口ＴＸ１〜ＴＸｍに向けて受発注側システムが送信する文書の種類、フォーマット及び交換手順等についても、受発注側システム双方のシステム管理者間で事前に設定される。

セッション抽出ルールは、例えばＸＭＬ文書ではＸＭＬ文書の特定の位置を抽出するための文法を持つXPathにより表現される。また、例えばＥＤＩ（Electronic Data Interchange）等で交換されるバイナリデータの場合には、抽出開始位置から抽出終了位置を示すルールが使用される。交換される文書がテキスト文書の場合には、正規表現等が抽出ルールとして使用される。

サーバ選択部ＳＳは、受信口ＲＸ１〜ＲＸｍからのサーバ選択要求に応じ、ラウンドロビン等の負荷分散アルゴリズムに従い、受注側システムＢＳ１〜ＢＳｎごとにその各サーバ装置ＳＶ１〜ＳＶｉ，ＳＶ１〜ＳＶｊ間の負荷が均等になるようにサーバ装置の一つを選択する。そして、選択されたサーバ装置の識別情報を要求元の受信口ＲＸ１〜ＲＸｍに返送する。

セッション管理テーブルＤＢには、図２に示すように一つのセッションごとに、発注側システムＡＳのセッション識別子、アプリケーション識別子、受注側システムのセッション識別子、及び受注側システムの接続先サーバの識別情報が相互に対応付けられて格納される。

上記発注側システムＡＳのセッション識別子は、上記受信口ＲＸ１〜ＲＸｍ及び送信口ＴＸ１〜ＴＸｍにおいて、文書中から上記セッション抽出ルールにより抽出される。アプリケーション識別子は受信口ＲＸ１〜ＲＸｍに予め対応付けられたものである。受注側システムのセッション識別子は受注側システムＢＳ１〜ＢＳｎのサーバ装置において生成される。受注側システムの接続先サーバを示す情報は、上記サーバ選択部ＳＳにより選択されて通知される。

また、上記発注側連携装置ＷＲａ及び受注側連携装置ＷＲｂは具体的にはサーバにより実現されるもので、その構成は以下のようになる。図３はその構成を示すブロック図である。すなわち、連携装置ＷＲａ，ＷＲｂは中央処理ユニット（ＣＰＵ：Central Processing Unit）１１を備える。このＣＰＵ１１には、バス１２を介してプログラムメモリ１３と、データメモリ１４と、受信口ユニット１５と、送信口ユニット１６がそれぞれ接続されている。

データメモリ１４は、記憶媒体として例えばハードディスクまたはＲＡＭを使用したもので、制御データ記憶領域と、前述したセッション管理テーブルＤＢの記憶領域とを備える。制御データ記憶領域には、各受信口ＲＸ１〜ＲＸｍ及び送信口ＴＸ１〜ＴＸｍに対応付けてシステム管理者により予め設定された上記セッション抽出ルール、セッション生成フラグ及びアプリケーション識別子が記憶される。

受信口ユニット１５は、前記受信口ＲＸ１〜ＲＸｍに対応する複数の受信インタフェース１５１〜１５ｍを有する。これらの受信インタフェース１５１〜１５ｍはそれぞれ上記ＣＰＵ１１の制御の下、受発注側システムから到来した文書を受信する。送信口ユニット１６は、前記送信口ＴＸ１〜ＴＸｍに対応する複数の送信インタフェース１６１〜１６ｍを有する。これらの送信インタフェース１６１〜１６ｍはそれぞれ上記ＣＰＵ１１の制御の下、送信対象の文書を受発注側システムへ向け送信する。

プログラムメモリ１３には、受信制御プログラム１３ａと、送信制御プログラム１３ｂと、セッション確立制御プログラム１３ｃと、セッション管理制御プログラム１３ｄが格納されている。
受信制御プログラム１３ａは、上記各受信インタフェース１５１〜１５ｍを制御することにより、通信相手側のシステムから送られた文書を受信口ＲＸ１〜ＲＸｍごとに受信する。このとき、受信口ＲＸ１〜ＲＸｍに対応付けて予め設定されたセッション抽出ルールをデータメモリ１４の制御データ記憶領域から読み出し、この読み出されたセッション抽出ルールに従い上記受信された文書中から相手側システムが使用するセッションに相当する情報を抽出する。

また受信制御プログラム１３ａは、受信口ＲＸ１〜ＲＸｍに対応するセッション生成フラグをデータメモリ１４の制御データ記憶領域から読み出し、セッション生成フラグが“オフ”であれば、セッション生成「不要」と判断する。そして、上記抽出された情報をキーとしてデータメモリ１２のセッション管理テーブルＤＢから、自己側システムのセッション識別子及び接続先の識別情報を読み出し、この読み出されたセッション識別子及び接続先情報をもとに、上記受信された文書を自己側のシステムへ送信する。

送信制御プログラム１３ｂは、上記各送信インタフェース１６１〜１６ｍを制御することにより、自己側のシステムから送られた文書を送信口ＴＸ１〜ＴＸｍごとに受信する。このとき、システム管理者によりセッション識別子の抽出が事前に設定されている場合には、送信口ＴＸ１〜ＴＸｍに対応付けて予め設定されたセッション抽出ルールをデータメモリ１４の制御データ記憶領域から読み出し、この読み出されたセッション抽出ルールに従い上記送信対象の文書中から相手側システムが使用するセッションに相当する情報を抽出する。そして、抽出された情報をキーとしてデータメモリ１２のセッション管理テーブルＤＢから、相手側システムのセッション識別子を読み出し、この読み出されたセッション識別子をもとに、上記受信された文書を相手側のシステムへ送信する。

セッション確立制御プログラム１３ｃは、上記受信口ＲＸ１〜ＲＸｍで文書が受信された場合に、当該受信口ＲＸ１〜ＲＸｍに対応付けて予め設定されたセッション生成フラグをデータメモリ１４の制御データ記憶領域から読み出し、セッション生成の要否を判定する。そして、セッション生成フラグが“オン”であれば、つまりセッション生成「要」であれば接続先となるサーバ装置の選択処理を実行する。このサーバ装置の選択処理は、ラウンドロビン等の負荷分散アルゴリズムを用いて、サーバ装置間の負荷が均等になるように行われる。続いて、上記選択されたサーバ装置に対しセッション生成要求を送り、当該サーバ装置から新たに生成されたセッションの識別子を受け取る。

セッション管理制御プログラム１３ｄは、上記受信口ＲＸ１〜ＲＸｍ及び送信口ＴＸ１〜ＴＸｍにおいて新たなセッションによる文書の送受信が行われる場合に、相手側のセッションに相当する情報を、アプリケーション識別子、自己側のセッション識別子及び自己側の接続先情報に対応付けて、上記セッション管理テーブルＤＢに記憶させる。また、セッションが解消された場合に、上記セッション管理テーブルＤＢから該当する情報を削除する。

次に、以上のように構成されたワークフロー処理システムの動作を、受注側システム及び受注側連携装置ＷＲｂを例にとって説明する。
（１）受注側システムが２つのシステムＢＳ１，ＢＳ２により構成され、これらのシステムＢＳ１，ＢＳ２ごとに独立してセッションを使用する場合
図５はこのときの受注側連携装置ＷＲｂの動作手順を示すシーケンス図、図４は受注側連携装置ＷＲｂの受信口ＲＸ１〜ＲＸｍの制御手順と制御内容を示すフローチャートである。

受注側連携装置ＷＲｂの各受信口ＲＸ１〜ＲＸ４にはそれぞれ、図５に示すようにセッション生成フラグ、セッション抽出ルール及びアプリ識別子がシステム管理者により予め設定されている。
発注側システムＡＳは、受注側システムＢＳ１に向けて見積依頼書（新規見積）を送信する際に、上記受注側連携装置ＷＲｂの受信口ＲＸ１のアドレスを宛先アドレスとして設定して送信する。

受注側連携装置ＷＲｂの受信口ＲＸ１は、図４に示すようにステップ３ａにおいて文書の到来を監視しており、文書が受信されるとステップ４において受信口ＲＸ１に対応付けられたアプリケーション識別子をデータメモリ１４から読み出す。続いて受注側連携装置ＷＲｂの受信口ＲＸ１は、当該受信口ＲＸ１に対応付けられたセッション抽出ルールをデータメモリ１４の制御データ記憶領域から読み出し、このセッション抽出ルールにより上記受信された文書を評価し、当該受信文書から発注側システムのセッションに相当する情報を抽出する。例えば、いま図６（ａ）に示すような文書が受信されたとすると、抽出ルール「/見積依頼書/弊社見積番号/＠ｎｏ」により「A12345678」を、発注側システムのセッションに相当する情報として抽出する。

次に受注側連携装置ＷＲｂの受信口ＲＸ１は、受信口ＲＸ１に対応付けられたセッション生成フラグをデータメモリ１４から読み出し、このセッション生成フラグをもとにセッション生成の要否をステップ４ｄで判定する。本例では、受信口ＲＸ１のセッション生成フラグは図５に示すように“オン”に設定されている。このため受信口ＲＸ１は、セッション生成「要」と判断してセッション確立処理を以下のように実行する。セッション確立処理は、サーバ選択処理とセッション生成処理とからなる。

すなわち、先ずステップ４ｅにおいてサーバ選択部ＳＳに対しサーバの選択を要求する。このときサーバ選択部ＳＳには、上記読み出されたアプリケーション識別子を通知する。サーバ選択部ＳＳは、通知されたアプリケーション識別子をもとに対応する受注側システムを選択する。そして、この選択された受注側システムを構成する複数のサーバ装置の中から、接続先として適切なサーバ装置（例えばＳＶ１）を選択する。例えば本例では、アプリケーション識別子が「EstimateService」であるため、受注側システムＢＳ１が選択される。また、いま仮に２台のサーバ装置ＳＶ１，ＳＶ２のうちサーバＳＶ１の負荷が少ないとすれば、サーバ装置ＳＶ１が選択される。なお、このサーバ装置の選択はラウンドロビン等の負荷分散アルゴリズムに従い行われる。

次に受信口ＲＸ１は、上記サーバ選択部ＳＳにより選択されたサーバ装置ＳＶ１に対し、ステップ４ｆにより上記アプリケーション「EstimateService」用のセッションの生成要求を送信する。サーバ装置ＳＶ１は、上記セッションの生成要求に応じて、上記アプリケーション「EstimateService」用の新たな格納領域を設定すると共に、セッション識別子を発行して受信口ＲＸ１に返送する。ここでは、例えばセッション識別子として「E00000001」が発行される。

受信口ＲＸ１は、ステップ４ｇにおいて、上記ステップ４ｃにより抽出された発注側システムのセッションに相当する情報「A12345678」と、上記アプリケーション識別子「EstimateService」と、上記発行された受注側システムＢＳ１のセッション識別子「E00000001」と、接続先のサーバ装置ＳＶ１を示すサーバ識別情報「E1」とを相互に対応付けて、セッション管理テーブルＤＢに格納する。図９（１）にこれらの情報が記憶された状態を示す。

上記セッション管理テーブルＤＢへの情報の格納を終了すると受信口ＲＸ１は、ステップ４ｈにより、先に受信された文書を接続先のサーバ装置ＳＶ１に転送し、セッション「E00000001」の実行を要求する。サーバ装置ＳＶ１は、上記要求に応じ見積処理を行う。なお、この見積処理では、担当者による見積書の発行処理に加え、上長等による決裁処理も含まれる。上記発行された見積書は、サーバ装置ＳＶ１から送信口ＴＸ１に返送される。送信口ＴＸ１は、上記サーバ装置ＳＶ１から返送された見積書を、見積依頼元の発注側システムＡＳへ向け送信する。

一方、上記見積書で提示された価格で折り合わず、発注側において再見積を依頼するための処理が行われたとする。この場合発注側システムＡＳは、受注側連携装置ＷＲｂの受信口ＲＸ２を宛先として、図６（ｂ）に示す見積依頼書（再見積）を送信する。
上記見積依頼書（再見積）を受信すると受信口ＲＸ２は、図４に示すようにステップ４ｂで受信口ＲＸ２に対応するアプリケーション識別子「EstimateService」を取得し、さらにステップ４ｃによりセッション抽出ルールに従い受信文書中から発注側システムのセッションに相当する情報「A12345678」を抽出したのち、ステップ４ｄにおいてセッション生成フラグをもとにセッション生成の要否を判定する。

このとき、受信口ＲＸ２には図５に示すようにセッション識別子“オフ”が設定されている。このため、受信口ＲＸ２はセッション生成「不要」と判断してステップ４ｉに移行する。そして、このステップ４ｉにより、上記抽出された発注側システムのセッションに相当する情報「A12345678」と、上記取得されたアプリケーション識別子「EstimateService」をキーとして、受注側システムＢＳ１のセッション識別子「E00000001」と、接続先のサーバ装置ＳＶ１を示すサーバ識別情報「E1」をセッション管理テーブルＤＢから読み出す。そしてステップ４ｈにより、サーバ識別情報「E1」をもとに上記受信文書を受信側システムＢＳ１のサーバ装置ＳＶ１へ転送し、上記読み出されたセッション識別子「E00000001」に従いセッション「E00000001」の実行を要求する。

サーバ装置ＳＶ１では、上記要求に応じて再見積処理が行われ、これにより再度見積書が作成される。この発行された見積書は、サーバ装置ＳＶ１から送信口ＴＸ２に返送される。送信口ＴＸ２は、上記サーバ装置ＳＶ１から返送された見積書を、見積依頼元の発注側システムＡＳへ向け送信する。

上記再見積の結果、価格が折り合い、発注側において発注するための処理が行われたとする。この場合発注側システムＡＳは、受注側連携装置ＷＲｂの受信口ＲＸ３を宛先として、図６（ｃ）に示す発注書を送信する。
上記発注書を受信すると受信口ＲＸ３は、先に述べた見積書（新規見積）を受信した場合と同様に、ステップ４ｂで受信口ＲＸ３に対応するアプリケーション識別子「orderService」を取得し、さらにステップ４ｃによりセッション抽出ルールに従い受信文書中から発注側システムのセッションに相当する情報「A23456789」を抽出する。そして、ステップ４ｄにおいてセッション生成フラグをもとにセッション生成の要否を判定する。

このとき、受信口ＲＸ３には図５に示すようにセッション識別子“オン”が設定されている。このため、受信口ＲＸ３はセッション生成「要」と判断してステップ４ｅに移行する。そして、このステップ４ｅ及びステップ４ｆによりセッション確立処理を次のように実行する。

すなわち、先ずステップ４ｅにおいてサーバ選択部ＳＳにサーバの選択要求をアプリケーション識別子と共に送る。サーバ選択部ＳＳは、通知されたアプリケーション識別子をもとに対応する受注側システムを選択する。そして、この選択された受注側システムを構成する複数のサーバ装置の中から、接続先として適切なサーバ装置（例えばＳＶ２）を選択する。例えば本例では、アプリケーション識別子が「OrderService」であるため、受注側システムＢＳ２が選択される。また、いま仮に２台のサーバ装置ＳＶ１，ＳＶ２のうちサーバＳＶ２の負荷が少ないとすれば、サーバ装置ＳＶ２が選択される。

次に受信口ＲＸ３は、上記サーバ選択部ＳＳにより選択された受注側システムＢＳ２のサーバ装置ＳＶ２に対し、ステップ４ｆにより上記アプリケーション「OrderService」用のセッションの生成要求を送信する。受注側システムＢＳ２のサーバ装置ＳＶ２は、上記セッションの生成要求に応じて、上記アプリケーション「OrderService」用の新たな格納領域を設定すると共に、セッション識別子を発行して受信口ＲＸ３に返送する。ここでは、例えばセッション識別子として「O00000005」が発行される。

受信口ＲＸ３は、ステップ４ｇにおいて、上記ステップ４ｃにより抽出された発注側システムのセッションに相当する情報「A23456789」と、上記アプリケーション識別子「OrderService」と、上記発行された受注側システムＢＳ２のセッション識別子「O00000005」と、接続先のサーバ装置ＳＶ１を示すサーバ識別情報「O2」とを相互に対応付けて、セッション管理テーブルＤＢに格納する。図９（２）にこれらの情報が記憶された状態を示す。

上記セッション管理テーブルＤＢへの情報の格納を終了すると受信口ＲＸ３は、ステップ４ｈにより、先に受信された文書を受注側システムＢＳ２のサーバ装置ＳＶ２に転送し、セッション「O00000005」の実行を要求する。サーバ装置ＳＶ２は、上記要求に応じて発注確認書の発行処理を行う。上記発行された発注確認書は、受注側システムＢＳ２のサーバ装置ＳＶ２から送信口ＴＸ３に返送され、この送信口ＴＸ３から発注元の発注側システムＡＳへ向け送信される。

以後同様に、受注側システムＢＳ２のサーバ装置ＳＶ２では、納品と共に納品書が発行され、この納品書は、受注側システムＢＳ２のサーバ装置ＳＶ２から送信口ＴＸ４に送られ、この送信口ＴＸ４から発注元の発注側システムＡＳへ向け送信される。
また、上記納品書を受信すると発注側システムＡＳからは、受注側連携装置ＷＲｂの受信口ＲＸ４を宛先として、図６（ｄ）に示す検収通知が送信される。受信口ＲＸ４では、図４に示すようにステップ４ｂで受信口ＲＸ４に対応するアプリケーション識別子「OrderService」を取得し、さらにステップ４ｃによりセッション抽出ルールに従い受信文書中から発注側システムのセッションに相当する情報「A23456789」を抽出したのち、ステップ４ｄにおいてセッション生成フラグをもとにセッション生成の要否を判定する。

このとき、受信口ＲＸ４には図５に示すようにセッション識別子“オフ”が設定されているため、受信口ＲＸ４はセッション生成「不要」と判断してステップ４ｉに移行する。そして、このステップ４ｉにより、上記抽出された発注側システムＡＳのセッションに相当する情報「A23456789」と、上記取得されたアプリケーション識別子「OrderService」をキーとして、受注側システムＢＳ２のセッション識別子「O00000005」と、接続先のサーバ装置ＳＶ２を示すサーバ識別情報「O2」をセッション管理テーブルＤＢから読み出す。そしてステップ４ｈにより、サーバ識別情報「O2」をもとに上記受信文書を受信側システムＢＳ２のサーバ装置ＳＶ２へ転送し、上記読み出されたセッション識別子「O00000005」に従いセッション「O00000005」の実行を要求する。

以上述べたように、受注側連携装置ＷＲｂを設けたことにより、受注側システムが２つのシステムＢＳ１，ＢＳ２により構成され、かつこれらのシステムＢＳ１，ＢＳ２ごとに異なるセッションが生成されてワークフロー処理が実行される場合でも、発注側システムＡＳはこのような受注側システムの運用状態を意識することなく、文書の送受信を実行することができる。

また、受注側連携装置ＷＲｂにおいては、セッション抽出ルールにより抽出した情報から、発信側システムＡＳが使用するセッションが特定され、この情報をキーとしてセッション管理テーブルＤＢから受注側システムＢＳ１，ＢＳ２のセッション識別子を読み出して、接続先のサーバ装置にセッションの実行を要求するようにしている。このため、伝送プロトコル上で明示的にセッション識別子を伝播していないにも拘わらず、受注側システムＢＳ１，ＢＳ２にセッションを実行させることができる。

さらに、受注側連携装置ＷＲｂにおいて新たなセッションを確立する際に、サーバ選択部ＳＳにより、受注側システムＢＳ１，ＢＳ２ごとにそのサーバ装置ＳＶ１〜ＳＶｉ，ＳＶ１〜ＳＶｊの負荷が均等に分散されるように接続先のサーバ装置が選択されるので、発注側システムから要求された処理が特定のサーバ装置に集中する不具合を回避して、効率の良いワークフロー処理を実現できる。

（２）受注側システムが１つのシステムＢＳ１により構成され、このシステムＢＳ１が一つのセッションを使用して一連の文書交換処理を実行する場合
図８はこのときの受注側連携装置ＷＲｂの動作手順を示すシーケンス図、図７は受注側連携装置ＷＲｂの受信口ＲＸ１〜ＲＸｍの制御手順と制御内容を示すフローチャートである。

受注側連携装置ＷＲｂの各受信口ＲＸ１〜ＲＸ４にはそれぞれ、図８に示すようにセッション生成フラグ、セッション抽出ルール及びアプリ識別子がシステム管理者により予め設定されている。そして、発注側システムＡＳから到来する各種文書に対しては、上記設定された各情報と、受注側システムのサーバ装置ＳＶ１，ＳＶ２で生成される受注側システムのセッションと、セッション管理テーブルＤＢに記憶された情報とをもとに、先に（１）で述べた受信制御動作と同様の動作が実行される。

一方、各送信口ＴＸ１〜ＴＸ４のうち送信口ＴＸ１，ＴＸ２には、図８に示すようにセッション抽出ルールがシステム管理者により予め設定されている。そして、受注側システムＢＳ１が文書を送信した場合に、上記送信口ＴＸ１，ＴＸ２により次のような送信制御が実行される。

すなわち、いま仮に受注側システムＢＳ１が、受注側連携装置ＷＲｂの送信口ＴＸ１に対し、図６（ｂ）に示す見積書の送信依頼を送ったとする。そうすると受注側連携装置ＷＲｂの送信口ＴＸ１は、図７に示すようにステップ７ａからステップ７ｂに移行し、ここで先ず当該送信口ＴＸ１に対応付けられたセッション抽出ルールをデータメモリ１４の制御データ記憶領域から読み出す。そして、この読み出されたセッション抽出ルール「/見積書/弊社見積番号/＠ｎｏ」に従い上記送られた見積書を評価して、「E00000001」を抽出する。

次に、次回の受信に備えるため、ステップ７ｃにおいて、上記抽出された「E00000001」を発注側システムのセッションに相当する情報とし、この情報「E00000001」と、アプリケーション識別子（OrderService）と、内部システムのセッション識別子「E00000001」と、内部システムの識別子「O1」とを相互に対応付けて、セッション管理テーブルＤＢに書き込む。図１０の（２）はこのとき記憶された情報を示す。そして、その書き込みが終了したのち、ステップ７ｄにより上記見積書を発注側システムＡＳに向け送信する。

一方、この状態で発注側システムＡＳから受信口ＲＸ３に対し発注書が送られたとする。そうすると受信口ＲＸ３は、先に（１）で述べた場合と同様に、図４に示すようにステップ４ｂで受信口ＲＸ３に対応するアプリケーション識別子「OrderService」を取得し、さらにステップ４ｃによりセッション抽出ルールに従い受信文書中から発注側システムのセッションに相当する情報「E00000001」を抽出する。そして、ステップ４ｄにおいてセッション生成フラグをもとにセッション生成の要否を判定する。

このとき、受信口ＲＸ３には図８に示すようにセッション識別子“オフ”が設定されている。このため、受信口ＲＸ３はセッション生成「不要」と判断してステップ４ｉに移行する。そして、このステップ４ｉにより、上記抽出された発注側システムのセッションに相当する情報「E00000001」と、上記取得されたアプリケーション識別子「OrderService」をキーとして、受注側システムＢＳ１のセッション識別子「E00000001」と、接続先のサーバ装置ＳＶ１を示すサーバ識別情報「O1」をセッション管理テーブルＤＢから読み出す。そしてステップ４ｈにより、サーバ識別情報「O1」をもとに上記受信文書を受信側システムＢＳ１のサーバ装置ＳＶ１へ転送し、上記読み出されたセッション識別子「E00000001」に従いセッション「E00000001」の実行を要求する。

サーバ装置ＳＶ１は、上記要求に応じて発注確認書の発行処理を行う。上記発行された発注確認書は、受注側システムＢＳ１のサーバ装置ＳＶ１から送信口ＴＸ３に返送され、この送信口ＴＸ３から発注元の発注側システムＡＳへ向け送信される。以後、納品書の送信処理及び研修所の受信処理については、先に述べた（１）の場合と同じである。

以上述べたように受注側システムが１つのシステムＢＳ１により構成され、このシステムＢＳ１が一つのセッションを使用して一連の文書交換処理を実行する場合でも、発注側システムＡＳはこのような受注側システムの運用状態を意識することなく、文書の送受信を実行することができる。

なお、この発明は上記実施形態に限定されるものではない。例えば、前記実施形態では各連携装置ＷＲａ，ＷＲｂを通信ネットワークＮＷを介して発注側及び受注側システムＡＳ，ＢＳ１〜ＢＳｎに接続するようにしたが、連携装置ＷＲａ，ＷＲｂを通信ネットワークＮＷを介さずに企業内通信路を介して発注側及び受注側システムＡＳ，ＢＳ１〜ＢＳｎに接続するように構成してもよい。

また前記実施形態では、発注側システムＡＳ及び受注側システムＢＳ１〜ＢＳｎにそれぞれ対応させて連携装置ＷＲａ，ＷＲｂを設けたが、例えば１個のサーバ装置に、発注側連携装置ＷＲａの機能及び受注側連携装置ＷＲｂの機能をそれぞれ持たせるように構成してもよい。

その他、ワークフロー間連携装置の構成やその制御手順と内容、取引の種類、交換される文書の種類とその構成等についても、この発明の要旨を逸脱しない範囲で種々変形して実施できる。
要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。

この発明に係わるワークフロー処理システムの一実施形態である企業間受発注処理システムを示す概略構成図。 図１に示したワークフロー間連携装置の機能構成を示すブロック図。 図１に示したワークフロー間連携装置の具体的構成を示すブロック図。 図２及び図３に示したワークフロー間連携装置の受信口の制御手順と制御内容を示すフローチャート。 図１に示したシステムにおける受発注処理の第１の動作を説明するための図。 発注側システムと受注側システムとの間で伝送される文書の一例を示す図。 図２及び図３に示したワークフロー間連携装置の送信口の制御手順と制御内容を示すフローチャート。 図１に示したシステムにおける受発注処理の第２の動作を説明するための図。 図２及び図３に示したワークフロー間連携装置に設けられるセッション管理テーブルに記憶される情報の一例を示す図。 図２及び図３に示したワークフロー間連携装置に設けられるセッション管理テーブルに記憶される情報の他の例を示す図。 従来システムにおける動作シーケンスの一例を示す図。 従来システムにおける動作シーケンスの他の例を示す図。

符号の説明

ＡＳ…発注側システム、ＢＳ１，ＢＳ２…受注側システム、ＮＷ…通信ネットワーク、ＷＲａ…発注側連携装置、ＷＲｂ…受注側連携装置、ＣＬ１〜ＣＬｋ…クライアント端末、ＳＶ１〜ＳＶｉ，ＳＶ１〜ＳＶｊ…サーバ装置、ＲＸ１〜ＲＸｍ…受信口、ＴＸ１〜ＴＸｍ…送信口、ＤＢ…セッション管理テーブル、ＳＳ…サーバ選択部、１１…ＣＰＵ、１２…バス、１３…プログラムメモリ、１３ａ…受信制御プログラム、１３ｂ…送信制御プログラム、１３ｃ…セッション確立制御プログラム、１３ｄ…セッション管理制御プログラム、１４…データメモリ、１５…受信口ユニット、１５１〜１５ｍ…受信インタフェース、１６…送信口ユニット、１６１〜１６ｍ…送信インタフェース。

Claims (9)

1. 互いに独立したセッションを使用してワークフロー処理を実行する第１及び第２のシステム間に介在配置されるワークフロー間連携装置であって、
   セッション生成の要否が予め設定され、かつ前記第２のシステムが実行する複数の処理にそれぞれ対応して設けられた複数の受信部と、
   前記複数の受信部により共有されるセッション管理テーブルと
   を具備し、
   前記複数の受信部は、
   第１のシステムから送信された第１のファイルを受信する手段と、
   前記受信された第１のファイル中から、予め定めたルールに従い第１のシステムが使用するセッションに相当する情報を抽出する手段と、
   セッションの生成が必要な場合に、前記第２のシステムに対しセッションの生成を要求し、当該第２のシステムから第２のシステムが使用するセッションを示す情報を取得する取得手段と、
   前記取得された第２のシステムが使用するセッションを示す情報と、前記抽出された第１のシステムが使用するセッションに相当する情報とを相互に対応付けて、前記セッション管理テーブルに記憶させる手段と、
   セッションの生成が不要な場合に、前記セッション管理テーブルから、前記抽出された第１のシステムが使用するセッションに相当する情報に対応付けて記憶されている第２のシステムが使用するセッションを示す情報を読み出す手段と、
   前記読み出された第２のシステムが使用するセッションを示す情報に従い、セッションの実行要求及び前記受信された第１のファイルを第２のシステムに対し送信する手段と
   を備えることを特徴とするワークフロー間連携装置。
2. 前記複数の受信部と対をなしかつ前記セッション管理テーブルを共有するように設けられる複数の送信部を、さらに具備し、
   前記複数の送信部は、
   前記第２のシステムから送信された第２のファイルを受信する手段と、
   前記受信された第２のファイル中から、予め定めたルールに従い第１のシステムが使用するセッションに相当する情報を抽出する手段と、
   前記抽出された第１のシステムが使用するセッションを示す情報と、前記第２のシステムが使用するセッションを示す情報とを相互に対応付けて、前記セッション管理テーブルに記憶させる手段と、
   前記受信された第２のファイルを前記第１のシステムへ送信する手段と
   を備えることを特徴とする請求項１記載のワークフロー間連携装置。
3. 前記第２のシステムが複数のコンピュータを備える場合に、
   前記複数のコンピュータを所定の負荷分散アルゴリズムに従い選択する機能を有するコンピュータ選択部を、さらに具備し、
   前記複数の受信部の取得手段は、
   セッションの生成が必要な場合に、前記コンピュータ選択部に対しコンピュータの選択を要求して、選択されたコンピュータを示す情報を受け取る手段と、
   前記受け取った情報をもとに、前記選択されたコンピュータに対しセッションの生成を要求して、当該コンピュータから第２のシステムが使用するセッションを示す情報を受け取る手段と
   を備えることを特徴とする請求項１又は２記載のワークフロー間連携装置。
4. 互いに独立したセッションを使用してワークフロー処理を実行する第１及び第２のシステム間に介在配置され、セッション生成の要否が予め設定されかつ第２のシステムが実行する複数の処理にそれぞれ対応して設けられる複数の受信部と、これらの受信部により共有されるセッション管理テーブルとを具備するワークフロー間連携装置で使用されるプログラムであって、
   第１のシステムから送信された第１のファイルを受信する処理と、
   前記受信された第１のファイル中から、予め定めたルールに従い第１のシステムが使用するセッションに相当する情報を抽出する処理と、
   セッションの生成が必要な場合に、前記第２のシステムに対しセッションの生成を要求し、当該第２のシステムから第２のシステムが使用するセッションを示す情報を取得する処理と、
   前記取得された第２のシステムが使用するセッションを示す情報と、前記抽出された第１のシステムが使用するセッションに相当する情報とを相互に対応付けて、前記セッション管理テーブルに記憶させる処理と、
   セッションの生成が不要な場合に、前記セッション管理テーブルから、前記抽出された第１のシステムが使用するセッションに相当する情報に対応付けて記憶されている第２のシステムが使用するセッションを示す情報を読み出す処理と、
   前記読み出された第２のシステムが使用するセッションを示す情報に従い、セッションの実行要求及び前記受信された第１のファイルを前記第２のシステムに対し送信する処理と
   を、前記各受信部に実行させるプログラム。
5. 前記ワークフロー間連携装置が、複数の受信部と対をなしかつセッション管理テーブルを共有する複数の送信部をさらに具備する場合に、
   前記第２のシステムから送信された第２のファイルを受信する処理と、
   前記受信された第２のファイル中から、予め定めたルールに従い第１のシステムが使用するセッションに相当する情報を抽出する処理と、
   前記抽出された第１のシステムが使用するセッションを示す情報と、前記第２のシステムが使用するセッションを示す情報とを相互に対応付けて、前記セッション管理テーブルに記憶させる処理と、
   前記受信された第２のファイルを前記ワークフロー間連携装置から第１のシステムへ送信する処理と
   を、前記各送信部に実行させる請求項４記載のプログラム。
6. 前記第２のシステムが複数のコンピュータを備え、かつ前記ワークフロー間連携装置が前記複数のコンピュータを所定の負荷分散アルゴリズムに従い選択するコンピュータ選択部をさらに具備する場合に、
   前記第２のシステムが使用するセッションを示す情報を取得する処理は、
   セッションの生成が必要な場合に、前記コンピュータ選択部に対しコンピュータの選択を要求して、選択されたコンピュータを示す情報を受け取る処理と、
   前記受け取った情報をもとに、前記選択されたコンピュータに対しセッションの生成を要求して、当該コンピュータから第２のシステムが使用するセッションを示す情報を受け取る処理と
   を、前記各受信部に実行させる請求項４又は５記載のプログラム。
7. 互いに独立したセッションを使用してワークフロー処理を実行する第１及び第２のシステム間で、ワークフロー間連携装置を介して取引に関する処理を実行するワークフロー処理方法であって、
   前記第１のシステムから送信された第１のファイルを、前記ワークフロー間連携装置で受信する過程と、
   前記ワークフロー間連携装置が、前記受信された第１のファイル中から予め定めたルールに従い第１のシステムが使用するセッションに相当する情報を抽出する過程と、
   前記ワークフロー間連携装置が、セッションの生成が必要な場合に、前記第２のシステムに対しセッションの生成を要求し、当該第２のシステムから第２のシステムが使用するセッションを示す情報を取得する過程と、
   前記ワークフロー間連携装置が、前記取得された第２のシステムが使用するセッションを示す情報と、前記抽出された第１のシステムが使用するセッションに相当する情報とを相互に対応付けてセッション管理テーブルに記憶させる過程と、
   前記ワークフロー間連携装置が、セッションの生成が不要な場合に、前記セッション管理テーブルから、前記抽出された第１のシステムが使用するセッションに相当する情報に対応付けて記憶されている第２のシステムが使用するセッションを示す情報を読み出す過程と、
   前記読み出された第２のシステムが使用するセッションを示す情報に従い、セッションの実行要求及び前記受信された第１のファイルを前記ワークフロー間連携装置から前記第２のシステムに対し送信する過程と
   を備えることを特徴とするワークフロー処理方法。
8. 前記第２のシステムから送信された第２のファイルを、前記ワークフロー間連携装置で受信する過程と、
   前記ワークフロー間連携装置が、前記受信された第２のファイル中から予め定めたルールに従い第１のシステムが使用するセッションに相当する情報を抽出する過程と、
   前記抽出された第１のシステムが使用するセッションを示す情報と、前記第２のシステムが使用するセッションを示す情報とを相互に対応付けて前記セッション管理テーブルに記憶させる過程と、
   前記受信された第２のファイルを前記ワークフロー間連携装置から第１のシステムへ送信する過程と
   を、さらに備えることを特徴とする請求項７記載のワークフロー処理方法。
9. 前記第２のシステムが複数のコンピュータを備える場合に、
   前記第２のシステムが使用するセッションを示す情報を取得する処理は、
   セッションの生成が必要な場合に、所定の負荷分散アルゴリズムに従い前記複数のコンピュータの中から一つを選択する処理と、
   前記選択されたコンピュータに対しセッションの生成を要求して、当該コンピュータから第２のシステムが使用するセッションを示す情報を受け取る処理と
   を備えることを特徴とする請求項７又は８記載のワークフロー処理方法。

Images