JP2005284462A - 業務統合サーバの機能連携制御方式 - Google Patents

Abstract

【課題】機能連携における抽象化部分と固有部分の完全分離ができ、連携機能が必要とするデータの変更にも機能の変更を不要にする。
【解決手段】実行すべき業務個別機能名をその実行順序に従い記述する業務プロセスロジック２の拡張機能として、機能定義機構Ｍ１，Ｍ２は業務個別機能名の定義方法として逐次実行する機能及び並列実行する機能と機能の実行形態を状況に応じて定義できるように拡張し、さらに業務プロセスロジックに繰り返しループ制御機構Ｍ３、条件分岐機構Ｍ４、データ連携のための制御機構Ｍ５を追加拡張する。また、これらの拡張に伴い、繰り返しループカウント数、条件分岐の動的処理、及びデータ連携用に、既に実行した個別機能の実行結果を個々に識別できる情報と共に保存するための仕組みである実行結果管理テーブルＴを設ける。
【選択図】 図１

Description

本発明は、自コンピュータ内およびネットワークを介して分散配置されているコンピュータ上に存在する各種業務支援個別機能を統合的に機能させるサーバ（業務統合サーバ）に係り、特に業務統合サーバの機能連携制御方式に関するものである。

近年、情報化の促進やネットワーク環境の整備、さらにネットワークの高速化を背景に、従来スタンドアロン型であった業務支援システム（例えば監視業務における監視支援システムや保守業務における保守支援システム等）が図１１に示すようなネットワーク対応型へとなってきている。特に、企業内ネットワークを利用したイントラネット対応システムや、インターネットに代表される広域のネットワークを利用したシステムでは、時間や場所に対する制約を受けずに業務支援システムを利用することが可能となり、利便性を向上させている。

このようなシステム形態において、ある特定の業務機能を実現する手段としては、従来のスタンドアロン型業務支援システムでは、幾つかの個別機能を連携させ、１つの業務機能として機能させる。この個別機能の連携制御は通常、業務機能を実現するためのプログラムという形で実装され、それはシステム毎に固有の形態となる。これは近年のネットワーク対応型連携システムにおいても同様であり、機能連携制御はそれ自体がシステム機能プログラムとして実装されるのが一般的である。しかし、近年のシステム形態の主流であるネットワーク対応型連携システムでは、個別機能が分散管理されているという性格上、その機能の変更・更新等も個々に行われる。そのため、個別機能に変更・更新が行われる度にその連携を定義しているプログラムの変更も余儀なくされていた。そのため、このような事態にも容易に対応できるようなシステムが求められてきた。

このような状況を背景に、以下に示す仮想的な連携対象に対し、仮想的な連携機能を有してシステム本体に実装される抽象化部分と、具体的な連携対象に対する具体的な連携機能を有してシステム本体から呼ばれる固有部分とで構成した機能連携制御方法が登場してきた。

（Ａ）抽象化部分と固有部分を別プログラム化する形態。

個別機能連携により実現される業務機能部をシステム本体プログラムから業務機能プログラム（固有部分）として独立させ実装する。これにより、システム本体のプログラム（抽象化部分）を変更すること無く、個別機能の変更・更新時も業務機能プログラムのみの変更で対応することが可能となり、変更範囲の局所化が実現される。

（Ｂ）抽象化部分は従来通りのプログラム形式とし、固有部分を外部ファイルとして定義し、これを抽象化プログラムで読み取り実行する形態（例えば、特許文献１参照）。

このシステムにおける業務統合サーバの構成例を図１２に示す。クライアントゲート部１は、クライアントから送信されたデータの中から、実行する業務プロセスのロジック、該ロジックの実行に必要な各種パラメータ、作成するＧＵＩに対するスタイルシートの情報を抽出し、内部データとして格納する。業務プロセスロジック実行部２は、業務プロセス機能の名前に対応する業務支援サーバの詳細情報をサービスリポジトリ管理部３より取得し、これら名前及び業務支援サーバの詳細情報を業務支援サーバ通信部４を通して業務支援サーバにサービス実行を依頼し、このサービス実行の結果は内部データとして格納する。サービスリポジトリ管理部３は、業務プロセスロジック実行部２が指定する業務プロセス機能のサービス名に対応する業務支援サーバの詳細情報を取得し、業務プロセスロジック実行部２に通知する。業務支援サーバ通信部４は、業務プロセスロジック実行部２が指定するサービス名及び業務支援サーバの詳細情報を基に、業務支援サーバと通信し、業務支援サーバのサービス実行結果を業務プロセスロジック実行部２に通知する。サービスリポジトリ５は、業務プロセス機能の名前（サーバ名）に対応する業務支援サーバの詳細情報（サーバ名またはＩＰアドレス、サーバ実行に必要なパラメータ要素等）を格納する。ＧＵＩ作成部６は、内部データに格納されている前記業務プロセスロジック実行部２の処理結果と、指定されたスタイルシート情報を基に、クライアントへ送信すべきＧＵＩを動的に作成する。

上記のシステム構成において、機能連携制御を行っているのが、業務プロセスロジック実行部２であり、業務機能毎の個別機能の連携を定義する業務プロセスロジックと、それを実行するためのシステムプログラムとが、具体的な業務機能に依存する外部リソース部分（以下、固有部分）と具体的な業務機能に依存しない処理を実行する抽象的な部分（以下、抽象化部分）とに分類されるため、個別機能の変更・更新においてもその機能を連携させて実行する業務機能の変更・更新が容易になる。
特開２００３−２４２１２７

前記の（Ａ）抽象化部分と固有部分を別プログラム化する形態では、連携させる個別機能に変更があった場合、その変更の大小に関わらず変更分を吸収するために業務機能プログラムを修正し、再コンパイルする必要がある。

また、前記の（Ｂ）抽象化部分は従来通りのプログラム形式とし、固有部分を外部ファイルとして定義し、これを抽象化プログラムで読み取り実行する形態では、業務プロセスロジックには業務プロセス（個別機能）の連携順序を羅列しているのみであり、その業務プロセス（個別機能）のデータ連携は抽象化部分で行っている。そのため、個別機能が必要とするデータの変更（データの順序、項目の増減）が発生した場合は、抽象化部分の変更を余儀なくされる。

また、前記の（Ａ）及び（Ｂ）のいずれの形態にも当てはまる問題としては、ある個別機能Ｘの実行結果を、次に実行する個別機能Ｙに渡し、機能を連携する場合、個別機能Ｘの実行結果を個別機能Ｙの入力に合わせるための変換作業が必要となる。これは（Ａ）の場合は業務機能プログラム、（Ｂ）の場合は抽象化部分のプログラムで実装されることになる。しかし、これでは、（Ａ）の場合は常に次に実行する個別機能を意識した実装が必要となり、（Ｂ）の場合は抽象化部分に業務毎の機能の一部が混入することになり、機能連携における抽象化部分と固有部分の完全分離ができない。

また、例えば個別機能Ｘの実行結果が場合により“ｔｌｕｅ”、または“ｆａｌｓｅ”いずれかの値を返す場合において、“ｔｌｕｅ”の場合は個別機能Ｙを、“ｆａｌｓｅ”の場合は個別機能Ｚを実行するような分岐制御を機能連携に組み入れたい場合も同様の問題が発生する。

本発明の目的は、機能連携における抽象化部分と固有部分の完全分離ができ、連携機能が必要とするデータの変更にも機能の変更を不要にした業務統合サーバの機能連携制御方式を提供することにある。

本発明は、前記の課題を解決するため、実行すべき業務個別機能名をその実行順序に従い記述する業務プロセスロジックの拡張機能として、業務個別機能名の定義方法として逐次実行する機能及び並列実行する機能と機能の実行形態を状況に応じて定義できるように拡張し、さらに業務プロセスロジックに繰り返しループ制御、条件分岐制御、データ連携制御機構を追加拡張する。また、これらの拡張に伴い、繰り返しループカウント数、条件分岐の動的処理、及びデータ連携用に、既に実行した個別機能の実行結果を個々に識別できる情報と共に保存するための仕組みである実行結果管理テーブルを設ける。これらのことから、本発明は、以下の構成を特徴とする。

（１）自コンピュータ内、及びＬＡＮ、イントラネット、インターネット等のネットワークを介し、分散配置されているコンピュータ上に存在する各種業務支援個別機能を統合的に運用し、業務支援機能を構築・運用する業務支援システムにおいて、
外部リソースファイルの形で業務支援機能の連携情報を定義する業務プロセスロジックと、
前記業務プロセスロジック中に、前記業務支援個別機能の逐次実行及び並列実行の任意の実行形態を定義可能にした個別機能定義機構と、
繰り返し定義による特定の処理のループ制御ができ、ループ制御回数を前回実行個別機能の結果を利用することにより動的定義可能な繰り返し制御機構と、
条件分岐定義による特定の処理の分岐制御ができ、分岐条件を前回実行個別機能の結果を利用することにより動的定義可能な分岐制御機構と、
データ連携定義により個別機能間のデータ変換を用いることで、前回実行個別機能の結果を次回実行個別機能の入力値とすることができるデータ連携制御機構とを備え、
業務機能実行における抽象化部分と機能固有部分とにシステム機能を分離し、その抽象化部分に業務プロセスロジックを解析機構を備えたことを特徴とする。

（２）前記繰り返し制御機構による繰り返しループカウント数、前記条件分岐制御機構による動的処理、及び前記データ連携制御機構における既に実行した個別機能の実行結果を個々に識別できる情報と共に保存する実行結果管理テーブルを備えたことを特徴とする。

（３）前記業務プロセスロジックの形態は、
テキスト形式による業務プロセスロジック形式、
または、ＸＭＬ形式による業務プロセスロジック形式、
または、ＸＭＬ形式で記述した業務プロセスロジックからプログラム形式の業務プロセスロジックへ変換可能な業務プロセスロジック形式、
または、ＸＭＬ形式で記述した業務プロセスロジックから処理のボトルネックとなる部分のみプログラム形式の業務プロセスロジックへ変換可能な業務プロセスロジック形式としたことを特徴とする。

（４）前記業務プロセスロジックおよび前記各機構を業務統合サーバに設け、このサーバからの実行依頼で前記個別機能の実行を複数の業務支援サーバで行うシステム構成としたことを特徴とする。

以上のとおり、本発明によれば、実行すべき業務個別機能名をその実行順序に従い記述する業務プロセスロジックの拡張機能として、業務個別機能名の定義方法として逐次実行する機能及び並列実行する機能と機能の実行形態を状況に応じて定義できるように拡張し、さらに業務プロセスロジックに繰り返しループ制御、機構、条件分岐制御機構、データ連携のための制御機構を追加拡張し、これらの拡張に伴い、繰り返しループカウント数、条件分岐の動的処理、及びデータ連携用に、既に実行した個別機能の実行結果を個々に識別できる情報と共に保存するための仕組みである実行結果管理テーブルを設けるようにしたため、以下の効果がある。

自コンピュータ内、及びネットワークを介し分散配置されているコンピュータ上に存在する各種業務支援個別機能を統合的、且つ柔軟に連携させるために、業務プロセスロジックを拡張することにより、業務プロセスロジック自身に制御機構を保持させることができる。

また、業務プロセスロジックを解析・実行するシステム側においては、ロジックを解析する機能のみを設けることで機能連携における制御機構を定義する必要が無くなり、個別機能の連携において連携処理抽象化部分と、業務機能固有部分を完全に分離することが可能となる。

また、業務支援システムの機能の拡張・変更・追加・削除等がシステム本体のプログラムを変更する必要なく、業務プロセスロジックの変更のみで行うことが可能となる。

また、業務プロセスロジックの変更は、テキストベースによるテキスト形式、ＸＭＬ形式により作成することが可能であるため、容易に編集することが可能となるのでシステム全体における拡張性・柔軟性・保守性を総合的に向上させることが可能となる。

本発明は、前記の特許文献１で記述されている実行すべき業務個別機能名を、その実行順序に従い記述する業務プロセスロジックを以下のような拡張機能を有して構成する。

業務プロセスロジックに繰り返しループ制御、条件分岐制御の制御構造、データ連携のための制御機構を追加拡張する。同時に、業務個別機能名の定義方法も拡張し、逐次実行する機能、及び並列実行する機能と機能の実行形態を状況に応じて定義できるように拡張する。また、これらの拡張に伴い、繰り返しループカウント数、条件分岐の動的処理、及びデータ連携用に、既に実行した個別機能の実行結果を個々に識別できる情報と共に保存するための仕組みである実行結果管理テーブルを設定する。

図１は、本発明の実施形態を示し、図１２における業務プロセスロジック２に搭載する拡張機能構成を示す。以下、図１に示す拡張機能別に説明する。

（１）個別機能定義機構
実行する個別機能の名称を定義するための識別情報を定義する。図１中の機能定義機構Ｍ１では、識別情報を例として“ｍｅｔｈｏｄ”というキーワードを用いる。“ｍｅｔｈｏｄ”キーワードには実行する機能名称を設定するための属性情報を定義する。この属性情報は例として“ｎａｍｅ”というキーワードを用いる。これらの定義情報を実行する個別機能の数だけ、その実行順序に従って繰り返し定義する。

このように、実行順序に従い定義した“ｍｅｔｈｏｄ”キーワードで表した個別機能において、単純に１つずつ順序に従い実行するのではなく、ある２つ以上の機能を同時に実行したい場合も存在する。このような場合に対応するために、機能定義機構Ｍ２では、同時に実行したい“ｍｅｔｈｏｄ”キーワードを束ね、それらを自らの子要素として設定するための識別情報を定義する。この識別情報は例として、“ｍｅｔｈｏｄｓ”というキーワードを用いる。これにより“ｍｅｔｈｏｄｓ”キーワードの子要素として定義した“ｍｅｔｈｏｄ”キーワードの示す個別機能は、同時に実行する（以下、並列実行）機能を表すことになる。

また、並列実行するのではなく、１つずつ順序に従い実行する場合（以下、逐次実行）においても、“ｍｅｔｈｏｄｓ”キーワードの子要素として”ｍｅｔｈｏｄ“キーワードを設定する。この場合は、”ｍｅｔｈｏｄｓ“キーワードの子要素として設定される”ｍｅｔｈｏｄ“キーワードは１つとなる。以上の定義を、全ての”ｍｅｔｈｏｄ“キーワードに対し行う。その結果、業務プロセスロジック中には複数の“ｍｅｔｈｏｄｓ”キーワードが存在することになる。そのため、これらを一意に識別するための情報を、“ｍｅｔｈｏｄｓ”キーワードの属性として定義する。ここでは例として、“ｎａｍｅ”キーワードを用いる。

以上までの定義機構により、“ｍｅｔｈｏｄｓ”キーワードの順序に従い機能を逐次実行し、“ｍｅｔｈｏｄｓ”キーワードの子要素として“ｍｅｔｈｏｄ”キーワードで定義されている個別機能を実行する。但し、子要素としての“ｍｅｔｈｏｄ”キーワードが２つ以上定義されている場合はそれらを並列実行する。

個別機能定義の例を図２に示す。図２で示した業務プロセスロジックは、次のように実行される。

ａ−１を実行→ｂ−１、及びｂ−２を同時に実行→ｃ−１を実行
この実行では、ｂ−１，ｂ−２の並列実行、ａ−１，ｂ−１＆ｂ−２，ｃ−１の逐次実行になる。

（２）繰り返し制御機構
繰り返し識別情報を定義し、これによりある個別機能の繰り返し実行を制御する。図１では、繰り返し制御機構Ｍ３の識別情報は例として、“ｆｏｒ”キーワードを用いる。繰り返し実行の対象となる個別機能は、“ｆｏｒ”キーワードの子要素として定義されたものとする。“ｆｏｒ”キーワードの子要素としては、個別機能定義以外に、繰り返し定義（繰り返しの入れ子構造を示すことになる）、後述の条件分岐制御機構Ｍ４、及びデータ連携制御機構Ｍ５を定義することを可能とする。

繰り返し制御機構Ｍ３においては、そのループ回数を示す諸条件情報を定義する。ここでは、例として“ｆｏｒ”キーワードを用いているので、ループ回数を示す情報として、ループ開始値、及びループ終了値を用いる。設定する情報を各々示す識別情報を“ｆｏｒ”キーワードの属性として定義する。ここでは例としてループ開始値を“ｍｉｎ”、ループ終了値を“ｍａｘ”というキーワードを用いることとする。“ｆｏｒ”キーワードの設定例を図３に示す。図３では、以下のように実行される。

ａ−１を実行→ｃ−１をｍｉｎキーワードが示す値（０）からｍａｘキーワードが示す値（３）まで繰り返し実行。

また、ｍｉｎ、ｍａｘキーワードには直接値を設定する他に、実行結果管理テーブルＴの識別情報を指定することで、実行結果による繰り返し制御を実行することが可能となる。その場合の定義例を図４に示す。図４では、以下のように実行される。

ａ−１を実行→ｃ−１をｍｉｎキーワードが示す値（０）からｍａｘキーワードが示す値（実行結果管理テーブルの識別情報ｒｅｓｕｌｔ＿ａ−１が示す値）まで繰り返し実行。

また、実行結果管理テーブルＴの識別情報をｍｉｎ、ｍａｘキーワードに指定した場合、実行結果管理テーブルＴの識別情報に対し、以下の２つのオプションを用意する。これらのオプションは、実行結果管理テーブルＴの識別情報の後に続けて記述する。

・識別情報要素数指定オプション
指定した実行結果管理テーブルＴの識別情報と同名の識別情報が複数存在した場合、その識別情報数を取得するオプション。ここでは、例として、“＃Ｌｅｎｇｔｈ”キーワードを用いることとする。その例を図５に示す。図５では、以下のように実行される。

ａ−１を実行→ｃ−１をｍｉｎキーワードが示す値（０）からｍａｘキーワードが示す値（実行結果管理テーブルの識別情報ｒｅｓｕｌｔ＿ａ−１が複数あり、その要素数値）まで繰り返し実行。

・配列要素番号指定オプション
指定した実行結果管理テーブルＴの識別情報と同名の識別情報が複数存在した場合、その何番目の実行結果管理テーブルの識別情報が示す値を取得するかを指定するオプション。ここでは、例として、“＃［ｎ］キーワード”（ｎは、整数値）を用いることとする。その例を図６に示す。図６では、以下のように実行される。

ａ−１を実行→ｃ−１をｍｉｎキーワードが示す値（０）からｍａｘキーワードが示す値（実行結果管理テーブルの識別情報ｒｅｓｕｌｔ＿ａ−１が複数あり、その１番目の示す値）まで繰り返し実行。

（３）条件分岐制御機構
条件分岐識別情報を定義し、これによりある条件値による次に実行する個別機能の条件分岐実行を制御する。図１では、条件分岐制御機構Ｍ４の識別情報を例として、“ｉｆ”キーワードを用いる。通常のプログラム言語における「ｉｆ」は、条件に合致しない場合に「ｅｌｓｅ」を使用している。また、３つ以上に条件分岐を行う場合においては「ｅｌｓｅｉｆ」を用いる。「ｅｌｓｅｉｆ」には「ｉｆ」と同様の条件式を定義し、「ｉｆ」の条件に合致しない場合は「ｅｌｓｅｉｆ」の条件式の判定を行う。この「ｅｌｓｅｉｆ」を複数用いることで、条件による処理分岐を複数に設定することが可能である。この例にならい、ここでも例として“ｉｆ”キーワードを用いているので、それぞれを“ｅｌｓｅ”キーワード、“ｅｌｓｅｉｆ”キーワードを用いることとする。

条件分岐制御の対象となる個別機能は、“ｉｆ”，“ｅｌｓｅｉｆ”，“ｅｌｓｅ”キーワードの子要素として定義されるものとする。各々のキーワードの子要素としては個別機能定義以外に、繰り返し制御機構Ｍ３、条件分岐定義（条件分岐の入れ子構造を示すことになる）、及びデータ連携制御機構Ｍ５を定義することを可能とする。

条件分岐制御機構においては、分岐条件を示すための諸条件情報を定義する。ここでは例として“ｉｆ”キーワードを用いているので、条件分岐の条件式設定情報として、条件要素、条件値、条件値のデータ型、判定方法をも用いる。設定する条件の識別情報を“ｉｆ”キーワードの属性として定義する。ここでは、例として、条件要素を“ｂｏｒｄｅｒＮａｍｅ”、条件値を“ｂｏｒｄｅｒＶａｌｕｅ”、条件値のデータ型を“ｂｏｒｄｅｒＶａｌｕｅＴｙｐｅ”、判定方法を“ｏｐｅｒａｔｏｒ”というキーワードを用いる。

特に、条件値“ｂｏｒｄｅｒＶａｌｕｅ”の設定は、実行結果管理テーブルＴの識別情報指定により行う。これにより、“ｉｆ”キーワードの条件式に合致した場合はその子要素として定義しであるものを、そうでない場合は“ｅｌｓｅ”キーワードの子要素として定義しているものを実行する。

“ｂｏｒｄｅｒＶａｌｕｅ”キーワードで設定する実行結果管理テーブルＴの識別情報には、繰り返し制御機構Ｍ３の場合と同様の方法でオプションが指定可能とする。条件分岐制御機構Ｍ４の例を図７に示す。図７では、以下のように実行される。

ａ−１の実行→実行結果管理テーブルの識別情報ｒｅｓｕｌｔ＿ａ−１の示す値が１ならｃ−１を、２ならｄ−１を、それ以外ならｅ−１を実行。

（４）データ連携制御機構
データ連携識別情報を定義し、実行結果管理テーブルＴ内にある識別情報で保存されている個別機能の結果情報を、別の個別機能が読み取り可能な識別情報への変換を行う。このデータ連携制御機構Ｍ５による識別情報への変換は、識別情報の変換ルールを設定した外部ファイル（以下、変換ルール外部ファイル）を用いて行う。ここでは、データ連携識別情報を例として“ｍａｐｐｉｎｇ”キーワードを用いる。利用する変換ルール外部ファイルＦの名称は、“ｍａｐｐｉｎｇ”キーワードの子要素として定義する識別情報、ここでは例として“ｘｓｌ”キーワードを使用して定義する。データ連携は、逐次実行する個別機能の１つとして扱うため、個別機能定義機構の章で記述した“ｍｅｔｈｄｏｓ”キーワードの子要素として定義する。データ連携定義の例を、図８に示す。

以上で定義した識別情報（キーワード）を用いて、業務プロセスロジックを実現する場合の例を以下に４つ示す。

（例１）本例では、業務プロセスロジックをテキスト形式により定義した場合に関して記述する。テキスト形式では、業務プロセスロジックの定義は最も容易に編集・加工が行える方式である。

しかし、業務プロセスロジックを解析するプログラム側においては、全てが文字列で記述されている業務プロセスロジックを解析するためのプロセッサを独自に用意する必要がある。また、文字列であるが故にシステムによる取り扱いが複雑になる傾向がある。業務プロセスロジックをテキスト形式により実装した例を図９に示す。

（例２）本例では、業務プロセスロジックをＸＭＬ形式により定義した場合に関して記述する。ＸＭＬ形式では、定義識別情報（個別機能定義、繰り返し定義、条件分岐定義、データ連携定義）をタグとして位置付け、各定義識別情報を以下のように定義する。

（ａ）個別機能定義機構Ｍ１，Ｍ２
例として挙げた“ｍｅｔｈｏｄｓ”キーワードを＜ｍｅｔｈｄｏｓ＞タグ、“ｎａｍｅ”キーワードを＜ｍｅｔｈｏｄｓ＞タグの属性として定義。同様に、“ｍｅｔｈｏｄ”キーワードは＜ｍｅｔｈｏｄ＞タグ、“ｎａｍｅ”キーワードを＜ｍｅｔｈｏｄ＞タグの属性として定義。

（ｂ）繰り返し制御機構Ｍ３
例として挙げた“ｆｏｒ”キーワードを＜ｆｏｒ＞タグ、“ｍｉｎ”及び“ｍａｘ”キーワードを＜ｆｏｒ＞タグの属性として定義。

（ｃ）条件分岐制御機構Ｍ４
例として挙げた“ｉｆ”キーワードを＜ｉｆ＞タグ、“ｂｏｒｄｅｒＮａｍｅ”，“ｂｏｒｄｅｒＶａｌｕｅ”，“ｂｏｒｄｅｒＶａｌｕｅＴｙｐｅ”、及び“ｏｐｅｒａｔｏｒ”キーワードを＜ｉｆ＞タグの属性として定義。“ｅｌｓｅｉｆ”、及び“ｅｌｓｅ”キーワードも同様にそれぞれ＜ｅｌｓｅｉｆ＞タグ、＜ｅｌｓｅ＞タグとする。

（ｄ）データ連携制御機構Ｍ５
例として挙げた“ｍａｐｐｉｎｇ”キーワードを＜ｍａｐｐｉｎｇ＞タグとして定義。

ＸＭＬ形式では、拡張性・汎用性に優れたＸＭＬを利用することにより、任意のキーワードの増加減が行い易い特徴を持つことが可能となる。また、データの階層構造定義を効率的に行えるため、各キーワードの階層構造を効率的に定義することが可能となる。業務プロセスロジックを解析するためのプロセッサにおいても、市販のＸＭＬＰａｒｓｅｒを利用することで独自に用意する必要が無く、システムによる取り扱いが容易なものとなる。

しかし、全てのデータを文字列として扱うため、数値データなど、文字列以外のデータに対する処理効率が低く、ＸＭＬをシステム内で展開した場合のシステムリソースを多く消費する等の理由により、業務プロセスロジックの解析高速化という面では若千問題が残る。業務プロセスロジックをＸＭＬ形式により実装した例を図１０に示す。

（例３）本例では、ＸＭＬ形式で記述した業務プロセスロジックを、プログラム実装で利用しているプログラム言語に変換するプログラム変換プロセッサを用いてプログラム形式とした業務プロセスロジックを定義した場合に関して記述する。

本方式では、編集時はＸＭＬ形式、実行時はプログラム形式というハイブリット方式を採用することで、編集性、拡張性、解析の高速化を図ることが可能である。

しかし、ＸＭＬ形式で記述された業務プロセスロジックを実行時にプログラム形態へのコンパイル作業が必要になる、実装プログラム言語に変換するプロセッサを独自に用意する必要がある、コンパイル時に多くのシステムリソースが必要になる等の問題がある。

（例４）本例では、ＸＭＬ形式で記述した業務プロセスロジックの一部分を、プログラム実装で利用しているプログラム言語に変換するプログラム変換プロセッサを用いてプログラム形式とした業務プロセスロジックを定義した場合に関して記述する。

本方式では、業務プロセスロジックの実行において処理負荷が高いと思われる箇所、例えば繰り返しループ部分等のみを部分的にプログラム形式に変換し実行するものである。そのため、コンパイル時間の短縮、処理効率が悪い部分の高速化による全体的な処理速度の向上、コンパイル時に多くのシステムリソースを必要としない等のメリットがある。

しかし、ＸＭＬ形式で記述された業務プロセスロジックの一部分を実装プログラム言語に変換するプロセッサを用意する必要がある。業務プロセスロジック中のボトルネック抽出を適切に実施しないと期待していた処理速度向上が実現できない等の問題がある。

本発明の実施形態を示す業務プロセスロジックの拡張機能構成図。 実施形態における個別機能定義のキーワード定義例。 実施形態における繰り返し定義のキーワード定義例。 実施形態における繰り返し定義のキーワード定義例。 実施形態における繰り返し定義のキーワード定義例。 実施形態における繰り返し定義のキーワード定義例。 実施形態における条件分岐定義のキーワード定義例。 実施形態におけるデータ連携のキーワード定義例。 実施形態におけるテキスト形式による業務プロセスロジックの定義例。 実施形態におけるＸＭＬ形式による業務プロセスロジックの定義例。 ネットワーク対応型業務支援システムの構成例。 業務統合サーバのソフトウェア構成例。

符号の説明

１ クライアントゲート部
２ 業務プロセスロジック実行部
３ サービスリポジトリ管理部
４ 業務支援サーバ通信部
５ サービスリポジトリ
６ ＧＵＩ作成部
Ｍ１、Ｍ２ 個別機能定義機構
Ｍ３ 繰り返し制御機構
Ｍ４ 条件分岐制御機構
Ｍ５ データ連携制御機構
Ｔ 実行結果管理テーブル
Ｔ 外部ファイル

Claims (4)

1. 自コンピュータ内、及びＬＡＮ、イントラネット、インターネット等のネットワークを介し、分散配置されているコンピュータ上に存在する各種業務支援個別機能を統合的に運用し、業務支援機能を構築・運用する業務支援システムにおいて、
   外部リソースファイルの形で業務支援機能の連携情報を定義する業務プロセスロジックと、
   前記業務プロセスロジック中に、前記業務支援個別機能の逐次実行及び並列実行の任意の実行形態を定義可能にした個別機能定義機構と、
   繰り返し定義による特定の処理のループ制御ができ、ループ制御回数を前回実行個別機能の結果を利用することにより動的定義可能な繰り返し制御機構と、
   条件分岐定義による特定の処理の分岐制御ができ、分岐条件を前回実行個別機能の結果を利用することにより動的定義可能な分岐制御機構と、
   データ連携定義により個別機能間のデータ変換を用いることで、前回実行個別機能の結果を次回実行個別機能の入力値とすることができるデータ連携制御機構とを備え、
   業務機能実行における抽象化部分と機能固有部分とにシステム機能を分離し、その抽象化部分に業務プロセスロジックを解析機構を備えたことを特徴とする業務統合サーバの機能連携制御方式。
2. 前記繰り返し制御機構による繰り返しループカウント数、前記条件分岐制御機構による動的処理、及び前記データ連携制御機構における既に実行した個別機能の実行結果を個々に識別できる情報と共に保存する実行結果管理テーブルを備えたことを特徴とする請求項１に記載の業務統合サーバの機能連携制御方式。
3. 前記業務プロセスロジックの形態は、
   テキスト形式による業務プロセスロジック形式、
   または、ＸＭＬ形式による業務プロセスロジック形式、
   または、ＸＭＬ形式で記述した業務プロセスロジックからプログラム形式の業務プロセスロジックへ変換可能な業務プロセスロジック形式、
   または、ＸＭＬ形式で記述した業務プロセスロジックから処理のボトルネックとなる部分のみプログラム形式の業務プロセスロジックへ変換可能な業務プロセスロジック形式としたことを特徴とする請求項１または２に記載の業務統合サーバの機能連携制御方式。
4. 前記業務プロセスロジックおよび前記各機構を業務統合サーバに設け、このサーバからの実行依頼で前記個別機能の実行を複数の業務支援サーバで行うシステム構成としたことを特徴とする請求項１〜３のいずれか１項に記載の業務統合サーバの機能連携制御方式。

Images