JP2005092423A

JP2005092423A - ワークフローシステムおよびその方法

Info

Publication number: JP2005092423A
Application number: JP2003323074A
Authority: JP
Inventors: Shigeru Furuta; 茂古田
Original assignee: Nihon Unisys Ltd
Current assignee: Nihon Unisys Ltd
Priority date: 2003-09-16
Filing date: 2003-09-16
Publication date: 2005-04-07

Abstract

【課題】ワークフローアプリケーション21の開発者は、ワークフローソフトウェア11a-11nそれぞれに依存した、異なる処理を行うプログラムを開発しなければならない。
【解決手段】ワークフローアプリケーション21からメッセージを受信するWebサービスインタフェイス13、並びに、複数のワークフローソフトウェア11a-11nと一対一に対応する複数のアダプタ12a-12nをワークフローサーバ1に備える。Webサービスインタフェイス13は、受信したメッセージの解析結果に基づき、複数のアダプタの一つにメッセージを渡し、そのアダプタは、メッセージに基づく処理を対応するワークフローソフトウェアに実行させる。
【選択図】図3

Description

本発明はワークフローシステムおよびその方法に関し、例えば、ユーザ独自のインタフェイスをもつアプリケーションからワークフローソフトウェアを利用するシステムに関する。

ワークフローソフトウェアの利用形態は、ワークフローソフトウェアの販売者から提供される既製品のワークフローアプリケーション、例えば休暇申請などの人事申請系ワークフローアプリケーション、購買申請など多数部門が関与するワークフローアプリケーションなど伝票回覧型ワークフローの利用である。しかし、Webブラウザからの利用やユーザのポータルサイトの普及に伴い、ユーザ独自のユーザインタフェイスの利用が要求されている。このような利用形態に対応するために、ワークフローソフトウェアの販売者は、ワークフロー機能のアプリケーションインタフェイス(API)による公開、さらにワークフロー機能のオブジェクトを公開するようになった。そして、ユーザは、ユーザ独自のインタフェイスをもつアプリケーションからワークフローソフトウェアを呼び出すというアプリケーション主体のワークフローアプリケーションを構築するようになってきた。

ワークフローシステムの開発作業におけるワークフローの定義部（ルートの定義、フォームの定義）と、ワークフローの実行部（処理手続の開始、処理状況の取得）の開発量の比率は一対五から一対十程度である。WebブラウザのHTML (Hypertext Markup Language)、DHTML (Dynamic Hypertext Markup Language)、CSS (Cascading Style Sheet)に対する標準仕様の高機能化とともに、Webブラウザからの入出力を中心とするワークフローの実行部の開発量の比率が上がっている。ワークフローの実行部では処理手続きの開始、処理状況の取得、処理件数表示、一覧表示、詳細表示などの処理を行うが、このようなワークフロー関連技術はWeb関連技術、データベース関連技術とは異なり、市販の技術解説本に記載されているような汎用的なものではなく、ワークフローソフトウェアごとに大きく異なっている。

ワークフローソフトウェアは、WfMC (Work flow Management Coalition)において、基本機能について標準が設定されているが、機能の実現の仕方、使い方については、各ワークフローソフトウェアの販売者ごとに独自性がある。すなわち、あるワークフローソフトウェアに精通しているからといって、他のワークフローソフトウェアをすぐに利用するようなことはできない。そのために、開発時には利用する個別のワークフローソフトウェアに詳しい専門家の育成が必要であり、また改善作業の間も、使用しているワークフローソフトウェアに精通する要員を確保しておく必要がある。

また、SOAP（Simple Object Access Protocol、例えば非特許文献2参照）、UDDI（Universal Description, Discovery and Integration、例えば非特許文献3参照）、WSDL（Web Service Description Language、例えば、非特許文献4参照）といった技術を使用して、ネットワークを通して、アプリケーションプログラムを公開、配置し、利用可能にするWebサービスが開始されはじめている（例えば、特許文献1参照）。

特開2003-36197公報（第4-8頁、第1-6図）速水治夫「ここまで来たワークフロー管理システム(1) ワークフロー入門」情報処理、情報処理学会、1998年11月、39巻11号、1160-1165頁 Simple Object Access Protocol (SOAP) 1.1、[online]、W3C Note 08 May 2000、[平成15年8月25日検索]、インターネット＜URL http://www.w3.org/TR/2000/NOTE-SOAP-20000508/＞ UDDI Version 3.0 UDDI Spec Technical Committee Specification、[online]、19 July 2002、UDDI Spec TC、[平成15年8月25日検索]、インターネット＜URL http://uddi.org/pubs/uddi-v3.00-published-20020719.htm＞ Web Services Description Language (WSDL) 1.1、[online]、W3C Note 15 March 2001、[平成15年8月25日検索]、インターネット＜URL http://www.w3c.org/TR/wsdl＞

本発明は、上述の問題を個々にまたはまとめて解決するもので、ワークフローソフトウェアの利用に、ユーザ独自のインタフェイスを提供するアプリケーションソフトウェアの開発を容易にすることを目的とする。

本発明は、前記の目的を達成する一手段として、以下の構成を備える。

本発明は、複数のワークフローソフトウェアによるワークフロー処理を一括して提供するワークフローシステムであって、ワークフローアプリケーションからメッセージを受信するインタフェイス、並びに、複数のワークフローソフトウェアと一対一に対応する複数のアダプタとを有し、インタフェイスは、メッセージの解析結果に基づき、複数のアダプタの一つにメッセージを渡し、そのアダプタは、メッセージに基づく処理を対応するワークフローソフトウェアに実行させることを特徴とする。

本発明によれば、ワークフローソフトウェアの利用に、ユーザ独自のインタフェイスを提供するアプリケーションソフトウェアの開発を容易にすることができる。その結果、例えば、ワークフローシステムの開発量のうち大きな割合を占めるワークフローの実行部の開発において、開発者はワークフローソフトウェアそれぞれに依存した、異なる技術の修得が不要になる。さらに、運用時においても、各ワークフローソフトウェアの詳しい知識をもつ要員の長期間に渡る確保が不要になる、などの効果がある。

以下、本発明にかかる実施例のワークフローシステムおよび方法を図面を参照して詳細に説明する。

［ワークフローシステム］
ワークフローシステムは、複数の担当者がネットワークを介して仕事をする際に、担当者間で受け渡される情報の流れを管理し、自動化する情報処理装置上で稼動するシステムである。ワークフローシステムの開発は、ワークフローの定義部の開発、および、ワークフロー実行部の開発に分けられる。

開発者は、ワークフロー定義部において、ワークフローにおける作業単位であるアクティビティごとに作業内容、開始と終了の条件、担当者、データなどを定義し、アクティビティ間の順序関係も定義する。開発者は、定義に当たり、ワークフローソフトウェアが提供するプロセス定義ツールを使用し、グラフィカルユーザインタフェイス(GUI)を利用して作業を行うのが一般的である。

プロセス定義ツールは、開発者によるワークフロー定義を受け付けて、外部記憶装置にプロセス定義データとして保存する。図1はグラフィカルユーザインタフェイスによる休暇申請処理（処理手続名APHLDY）のワークフロー定義画面の一例を示す図で、申請伝票の起票処理（アクティビティ名：STEP0101）、上司の承認処理（アクティビティ名：STEP0102）、および、人事関連データベースの更新処理（アクティビティ名：ASTEP01）の三つのアクティビティがあることが示されている。

アクティビティの実行順序は、組織に属する担当者の役割に依存して決まる。このため、ワークフローシステムは、人事関連データベースから抽出した組織/役割データを作成して外部記憶装置にもつ。図2は、組織/役割データの一部である、処理手続名と役割との関係例を示す図で、処理手続名APHLDYを実行可能な申請者、および、対応する承認者のユーザIDが示されている。

［システム構成］
開発者は、担当者の作業を支援するワークフローアプリケーションのワークフロー実行部を、クライアントサーバ方式におけるサーバ側のアプリケーションとして、あるいは、Web方式によるCGI (Common Gateway Interface)アプリケーションとして開発する。以降、Web方式によるCGIアプリケーションを事例に説明する。

図3はワークフローシステムを実現するコンピュータシステムの構成例を示す図で、ワークフローサーバ1、アプリケーションサーバ2、複数のクライアント4、および、上述した人事関連データベースなどを含むデータベース5がネットワーク3を介して通信できるようになっている。ワークフローサーバ1上では、販売者が提供する複数のワークフローソフトウェア11a-11nが稼動し、アプリケーションサーバ2上では、開発者が記述するワークフローアプリケーション21が稼動する。また、クライアント4上では、一般に使用されるブラウザ41が稼動する。

さらに、ワークフローサーバ1上では、汎用的な、ワークフローWebサービスインタフェイス（以降「Webサービスインタフェイス13」と呼ぶ）と、ワークフローソフトウェア11a-11nそれぞれとの間をインタフェイスするワークフローソフトウェアアダプタ（以降「アダプタ12a-12n」と呼ぶ）が稼動する。

なお、図3に破線で囲むWebサービスインタフェイス13およびアダプタ12a-12nは部品群として提供される。また、図3には、ワークフローサーバ1が一台の例を示したが、ワークフローサーバ1を複数台として、ワークフローソフトウェアごとに処理を分散させてもよい。また、図3には、アプリケーションサーバ2、ワークフローサーバ1およびデータベース5がネットワーク3を介して通信する例を示したが、所定のインタフェイスおよび通信線を介して直接通信してもよいし、あるいは、ワークフローサーバ1、アプリケーションサーバ2、データベース5の機能を一台のサーバにもたせてもよい。

［Webサービスインタフェイスとアダプタ］
ワークフローソフトウェア11a-11nの販売者は、ワークフロー機能のオブジェクトとアプリケーションインタフェイス(API)を公開することで、ワークフローアプリケーション21からワークフローソフトウェア11a-11nを呼び出すことを可能にしている。しかし、APIやオブジェクトは、ワークフローソフトウェア11a-11nごとに異なるのが実状で、ワークフローアプリケーション2の開発者は、利用するワークフローソフトウェア11a-11nについて詳細な知識をもって作業する必要がある。

言い換えれば、図3に示すWebサービスインタフェイス13とアダプタ12a-12nが無ければ、ワークフローアプリケーション21を開発する開発者は、ワークフローソフトウェアそれぞれに依存するAPIをそのまま呼び出す必要があった。例えば、ワークフローシステムにログインするために開発が必要なワークフローアプリケーション21の処理の流れは図4に一例を示すようになる。

図4において、ワークフローアプリケーション21は、クライアント4のブラウザ41からワークフローアプリケーションのURL (Uniform Resource Locator)を受信すると(S11)、ログイン画面を返す(S12)。そして、ブラウザ41からユーザID、パスワードなどを受信すると(S13)、要求されたワークフローソフトウェアに対応するオブジェクトを生成し、そのワークフローソフトウェアのログイン用のAPIを呼び出す(S14)。そして、ワークフローソフトウェアから処理結果をオブジェクトとして取得し(S15)、以降の処理のためにそのオブジェクトを記憶するとともに、ワークフローソフトウェアの処理結果に応じた画面を生成し(S16)、その画面をブラウザ41に送信する(S17)。

図5は上記のやり方で記述したログイン用のワークフローアプリケーションの記述例を示す図である。図5に示すように、開発者は、（イ）行でワークフローエンジンのオブジェクトを、（ロ）行でログイン先オブジェクトを、（ハ）行でユーザ情報オブジェクトをそれぞれ生成し関連付けなければならない。さらに、（ニ）行でログイン用APIの呼出結果もオブジェクトとして取得する。この場合、開発者は、オブジェクトごとに予め決まっている関数名、変数名を使用しなければならない。また、オブジェクト、関数名、変数名はワークフローソフトウェア11a-11nごとに異なり、開発者は、利用するワークフローソフトウェアの詳しい知識をもつか、あるいは、習得しなければならない。

一方、図3に示すWebサービスインタフェイス13とアダプタ12a-12nがある場合、開発者は、Webサービスインタフェイス13あてに、ワークフローソフトウェアそれぞれに依存しないXML (eXtensible Markup Language)形式のSOAPメッセージを送信するようなワークフローアプリケーション21を記述すればよい。従って、個別のワークフローソフトウェアに依存したAPIを開発者が知る必要は無くなる。例えば、ワークフローシステムにおいてログインする場合のワークフローアプリケーション21の処理の流れは、図6に一例を示すようになる。

図6において、ワークフローアプリケーション21は、ブラウザ41からワークフローアプリケーションのURLを受信すると(S11)、ログイン画面を返す(S12)。そして、ブラウザ41からユーザID、パスワードなどを受信する(S13)。ここまでは図4の処理と同じである。

次に、ワークフローアプリケーション21は、個別のワークフローソフトウェアに依存しない文字列によるSOAPメッセージを作成し、ログイン用のWebサービスインタフェイス13に送信する(S21)。SOAPメッセージを受信したWebサービスインタフェイス13は、そのメッセージを解析し、要求されたワークフローソフトウェアに対応するアダプタを呼び出す(S22)。呼び出されたアダプタは、ワークフローソフトウェアに対応するオブジェクトを生成し、ワークフローソフトウェアのログイン用のAPIを呼び出し(S23)、ワークフローソフトウェアから処理結果をオブジェクトとして取得し(S24)、オブジェクトを変数に変換した結果をWebサービスインタフェイス13に返す(S25)。Webサービスインタフェイス13は、変数の値を文字列に変換した結果のSOAPメッセージをワークフローアプリケーション21に返す(S26)。ワークフローアプリケーション21は、処理結果として文字列によるSOAPメッセージが返されるので、その結果に応じた画面をブラウザ41に送信する(S27)。

図7はワークフローアプリケーション21からログイン用のWebサービスインタフェイス13に送信するSOAPメッセージの記述例を示す図である。なお、送信先のログイン用のWebサービスインタフェイス13の名称は、図7に示す（チ）行に設定されている。

また、アダプタが稼動するサーバ名（図7に示す（ワ）行）、ワークフローソフトウェアの識別名（図7に示す（カ）行）は、ワークフロー定義部の開発時に使用したワークフローソフトウェアに対応するものでなければならない。開発者は、このような文字列によるSOAPメッセージを生成するワークフローアプリケーション21を開発すればよく、利用するワークフローソフトウェアの詳細な知識を必要としない。

［Webサービスインタフェイスの処理］
図8はWebサービスインタフェイス13の処理の一例を示す図である。

● アダプタの呼び出しに必要な情報の抽出(S110)
Webサービスインタフェイス13は、受信したSOAPメッセージを解析し、アダプタの呼び出しに必要な情報を抽出する。抽出する情報は、例えば、アダプタが稼動するサーバ名（図7に示す（ワ）行）、ワークフローソフトウェアの識別名（同（カ）行）、ユーザID（同（ヨ）行）、パスワード（同（タ）行）である。

● アダプタの呼び出し(S120)
ログイン用のアダプタは、ワークフローソフトウェアごとに対応するものが準備されている。Webサービスインタフェイス13は、ステップS110で抽出した情報（アダプタが稼動するサーバ名、ワークフローソフトウェアの識別名）から、呼び出すべきログイン用のアダプタを認識する。そして、アダプタに渡す情報を、アダプタ呼び出しのための引数に設定して、ログイン用のアダプタを呼び出す。

● 処理結果のSOAPメッセージの作成(S130)
ログイン用アダプタの処理が行われ、結果が返されると、Webサービスインタフェイス13は、図9に記述例を示す処理結果のSOAPメッセージを作成する。処理結果のSOAPメッセージには、Webサービスインタフェイス13が呼び出された時に受信した情報である、サーバ名（図7に示す（ワ）行）、ワークフローソフトウェアの識別名（同（カ）行）、ユーザID（同（ヨ）行）、パスワード（同（タ）行）の情報がそのままコピーされて設定される（図9に示す（ワ）行から（タ）行まで）。そのほか、アダプタが返した情報を基に、ログイン処理が成功したか否か（図9に示す（ツ）行）、サーバのIPアドレス（同（レ）行）、および、ポート番号（同（ソ）行）の情報を含める。

● 処理結果のSOAPメッセージの送信(S140)
Webサービスインタフェイス13は、呼び出し元のワークフローアプリケーション21に向けて、ステップS130で作成した処理結果のSOAPメッセージを送信する。

［アダプタの処理］
図10はワークフローソフトウェアに依存するログイン用のアダプタが行う処理の一例を示す図である。

● ワークフローソフトウェアに依存するオブジェクトの生成(S210)
アダプタは、ワークフローソフトウェアに依存して決まっている、用途に応じた複数のオブジェクトの生成、階層構造化、関連付けを行う。従来、開発者がワークフローアプリケーション21の開発時に記述する必要があった処理、例えば図5に示す（イ）（ロ）（ハ）行の処理はアダプタが行うので、開発者はワークフローソフトウェアに依存する知識を必要としない。

● ログイン用APIの呼び出し(S220)
アダプタは、ステップS210で作成したオブジェクトの関数を使用して、ワークフローソフトウェアのログイン用APIを呼び出す。これも、従来は、開発者がワークフローアプリケーション21の開発時に記述する必要があった処理、例えば図5に示す（ニ）行の処理である。

● 処理結果の取り出し、戻り値情報の設定(S230)
アダプタは、ワークフローソフトウェアのログイン用APIから、処理結果が設定されたオブジェクトを受信し、処理結果の値を取り出して、アダプタからの戻り値情報として設定する。

● ログアウト用APIの呼び出し(S240)
アダプタは、ワークフローソフトウェアのログアウト用APIを呼び出してワークフローソフトウェアとの接続を切る。

● 処理結果の返信(S250)
アダプタは、呼び出し元のWebサービスインタフェイス13へ処理結果を返す。

［Webサービスインタフェイスの関数］
図11はWebサービスインタフェイス13の関数例を示す図である。これら関数は、前述したログイン用のWebサービスインタフェイス13と同様に、ワークフローアプリケーション21から受信したSOAPメッセージを解析し、ワークフローソフトウェアの種別、アダプタが稼動するサーバ名から、呼び出すべきアダプタを特定する。そして、アダプタに渡す情報をSOAPメッセージから抽出して、アダプタを呼び出すための引数に設定して、アダプタを呼び出す。そして、アダプタが返した情報から処理結果のSOAPメッセージを作成して、ワークフローアプリケーション21へ送信する。なお、ワークフローソフトウェアごとに、図11に示すWebサービスインタフェイス13の各関数に対応するアダプタが提供される。

［処理の開始］
実施例のワークフローシステムによれば、例えば図1に示す休暇申請処理において、申請者は、予め定められた休暇申請書を、クライアント4上で稼動するブラウザ41によって作成しデータベースに保存した上、申請伝票起票処理STEP0101を行う。この場合、ワークフローアプリケーション21は、ブラウザ41から受信したユーザID、パスワードに基づき図12に記述例を示すSOAPメッセージを作成し、作成したSOAPメッセージをWebサービスインタフェイス13へ送信する。

SOAPメッセージは、プロセス名（図12に示す（ノ）行）、処理手続識別名（同（オ）行）、アクティビティ名（同（ク）行）、操作内容（同（ヤ）（マ）行）、データベースキー（同（ケ）（フ）行）をもつ。このとき、SOAPメッセージの一部として、ログイン時にWebサービスインタフェイス13を呼び出した際の処理結果のSOAPメッセージの一部をそのまま埋め込んでおけばよいため（図12に（ウ）で示す範囲）、ワークフローアプリケーション21の開発者の開発作業は極めて容易になる。処理手続の開始用のWebサービスインタフェイス13は、受信したSOAPメッセージから情報を抽出し、引数に設定して処理手続の開始用のアダプタを呼び出す。

図13は処理手続の開始用のアダプタの処理の一例を示す図である。

● ワークフローソフトウェアに依存するオブジェクトの生成(S310)
アダプタは、図11のステップS210と同様の処理を行う。

● ログイン用APIの呼び出し(S320)
アダプタは、ワークフローソフトウェアのログイン用APIを呼び出す。この場合、SOAPメッセージに含まれている、サーバのIPアドレス、ポート番号を利用するので、図10に示すステップS220の場合よりも短時間に結果を得ることができる。

● 処理結果のオブジェクト、プロセス名称に基づくプロセスのオブジェクトの取得(S330)
ワークフローソフトウェアのログイン用APIの処理が終わると、アダプタは、ログイン処理結果のオブジェクトを取得する。さらに、アダプタは、SOAPメッセージに含まれるプロセス名を引数にし、ログイン処理結果のオブジェクトの関数を使用してプロセスのオブジェクトを取得する。

● 処理手続開始用APIの呼び出し(S340)
アダプタは、SOAPメッセージに含まれるアクティビティ名称、操作内容、データベースキーをプロセスのオブジェクトに設定して、ワークフローソフトウェアの処理手続開始用APIを呼び出す。

● 処理結果の取り出し、戻り値情報の設定(S350)
処理手続開始用APIの処理が終わると、アダプタは、処理結果のオブジェクトの変数に設定された処理結果を取り出して、アダプタの処理結果として設定する。

● ログアウト用APIを呼び出し(S360)
アダプタは、ワークフローソフトウェアのログアウト用APIを呼び出してワークフローソフトウェアとの接続を切る。

● 処理結果の返信(S370)
アダプタは、呼び出し元のWebサービスインタフェイス13へ処理結果を返す。この後、Webサービスインタフェイス13は、図14に記述例を示すSOAPメッセージを作成して、ワークフローアプリケーション21に送信する。このSOAPメッセージは、処理結果（図14に示す（ツ）行）、説明（同（ネ）行）を含む。

従来、ワークフローアプリケーション21の開発者は、ワークフローソフトウェア11a-11nそれぞれに依存して、前回ログイン時のログインのオブジェクトを保存した上で、ステップS330からS350に示す個別のオブジェクトに対応した処理を行うプログラムを開発しなければならない。これに対して、実施例のようにWebサービスインタフェイス13およびアダプタ12a-12nを備えれば、ワークフローアプリケーション21の開発者は、図12に示すような文字列によるSOAPメッセージを作成し、送信するプログラムを開発するだけでよい。そして、各ワークフローソフトウェアやオブジェクトに依存する処理は、アダプタによって処理される。

このように、本実施例によれば、ワークフローソフトウェアの利用技術を汎用化して、ワークフローソフトウェアをWebサービスから利用可能にすることができる。

また、ワークフローソフトウェアに依存せずに使用できるように、ワークフローの機能を標準化し、XML形式のSOAPメッセージを送付することで使用可能なWebサービスインタフェイスを提供することができる。

さらに、ワークフローソフトウェアに依存し、異なる部分については、個々のワークフローソフトウェアごとのアダプタを提供することで、Webサービスインタフェイスからの利用を可能にすることができる。

［他の実施例］
図3に示す構成のワークフローサーバ1をアプリケーションサービスプロバイダに設置すれば、利用者はワークフローソフトウェアを自社に導入する必要がなく、少ない費用でワークフローシステムを構築し運用することが可能になる。

グラフィカルユーザインタフェイスによる休暇申請処理のワークフロー定義画面の一例を示す図、処理手続名と役割との関係例を示す図、ワークフローシステムを実現するコンピュータシステムの構成例を示す図、 Webサービスインタフェイスとアダプタがない場合の、ワークフローシステムにログインするために必要なワークフローアプリケーションの処理の流れを示す図、図4に対応するログイン用のワークフローアプリケーションの記述例を示す図、 Webサービスインタフェイスとアダプタがある場合の、ワークフローシステムにログインするために必要なワークフローアプリケーションの処理の流れを示す図、ワークフローアプリケーションからログイン用のWebサービスインタフェイスに送信するSOAPメッセージの記述例を示す図、 Webサービスインタフェイスの処理の一例を示す図、処理結果のSOAPメッセージの記述例を示す図、ワークフローソフトウェアに依存するログイン用のアダプタが行う処理の一例を示す図、 Webサービスインタフェイスの関数例を示す図、ワークフローアプリケーションが作成し、Webサービスインタフェイスへ送信するSOAPメッセージの記述例を示す図、処理手続の開始用のアダプタの処理の一例を示す図、 Webサービスインタフェイスが作成し、ワークフローアプリケーションへ送信するSOAPメッセージの記述例を示す図である。

Claims

複数のワークフローソフトウェアによるワークフロー処理を一括して提供するワークフローシステムであって、
ワークフローアプリケーションからメッセージを受信するインタフェイス、並びに、前記複数のワークフローソフトウェアと一対一に対応する複数のアダプタとを有し、
前記インタフェイスは、前記メッセージの解析結果に基づき、前記複数のアダプタの一つに前記メッセージを渡し、そのアダプタは、前記メッセージに基づく処理を対応するワークフローソフトウェアに実行させることを特徴とするワークフローシステム。
前記ワークフローアプリケーションは、画面情報をクライアントに供給し、前記画面情報に基づき前記クライアントから取得される情報に基づき、前記インタフェイスに送信するメッセージを生成することを特徴とする請求項1に記載されたワークフローシステム。
前記インタフェイスは、前記アダプタを介して、前記ワークフローソフトウェアの処理結果を取得し、前記処理結果を示すメッセージを生成して、前記ワークフローアプリケーションソフトウェアに返すことを特徴とする請求項1に記載されたワークフローシステム。
前記ワークフローアプリケーションは、前記インタフェイスから返されるメッセージに基づき、メニューまたはエラーメッセージの画面情報を生成し、クライアントに供給することを特徴とする請求項3に記載されたワークフローシステム。
情報処理装置を制御して、請求項1から請求項4の何れかに記載されたワークフローシステムを実現することを特徴とするプログラム。
請求項5に記載されたプログラムが記録されたことを特徴とする記録媒体。
複数のワークフローソフトウェアによるワークフロー処理を一括して提供する情報処理装置であって、
外部装置からメッセージを受信するインタフェイス手段と、
前記複数のワークフローソフトウェアと一対一に対応する複数のアダプタ手段とを有し、
前記インタフェイス手段は、前記メッセージの解析結果に基づき、前記複数のアダプタ手段の一つに前記メッセージを渡し、そのアダプタ手段は、前記メッセージに基づく処理を対応するワークフローソフトウェアに実行させることを特徴とする情報処理装置。