(57)【要約】  【課題】  各アプリケーションでビジネスオブジェクト(ＢＯ)の定義内容に差異がある場合でも、ＢＯの転送時の情報の欠落を効率的に防止する。  【解決手段】  ＢＯをやり取りする複数のアプリケーションを統合するためのシステムを提供する。このシステムは、ＢＯを受信するＢＯ受信部２１と、受信ＢＯの送信元及びタイプに対応するビジネスプロセス定義をビジネスプロセス定義記憶部２２から取得するビジネスプロセス定義取得部２３と、送信ＢＯの属性に設定する値の入手先である参照先アプリケーションを定義した参照定義を記憶する参照定義記憶部２４と、送信ＢＯの属性に参照先アプリケーションから取得した値を設定する属性設定部２５と、値設定後の送信ＢＯを送信するＢＯ送信部２６と、各アプリケーションにおけるＢＯのインターフェースを定義したＩ/Ｆ定義記憶部２７と、インターフェース定義から参照定義を生成する参照定義生成部２８とを備える。  【選択図】  図３
2006184941.tif 000002
【特許請求の範囲】
【請求項１】
第１のアプリケーションからビジネスオブジェクトを受信する受信手段と、
前記受信手段により受信された前記ビジネスオブジェクトを第２のアプリケーションに送信する送信手段と、
前記第２のアプリケーションに送信される前記ビジネスオブジェクトに含まれる属性ごとに、当該属性の値を保持する参照先アプリケーションの識別情報を記憶する手段と、
前記送信手段による前記ビジネスオブジェクトの送信に先立ち、当該ビジネスオブジェクトの特定の属性に設定する値を、当該特定の属性に対応する参照先アプリケーションから取得して設定する設定手段と
を備えた、複数のアプリケーションを統合するための装置。
【請求項２】
前記設定手段が前記値を取得して設定する前記特定の属性は、前記第１のアプリケーションから受信した前記ビジネスオブジェクトが保持しない属性である、請求項１記載の装置。
【請求項３】
前記設定手段が前記値を取得して設定する前記特定の属性は、前記第１のアプリケーションから受信した前記ビジネスオブジェクトが前記第２のアプリケーションが要求しない形式で保持する属性である、請求項１記載の装置。
【請求項４】
所定の複数のアプリケーションのそれぞれが管理する前記ビジネスオブジェクトの属性の情報に基づいて、前記参照先アプリケーションを決定する決定手段を更に備えた、請求項１記載の装置。
【請求項５】
所定の複数のアプリケーションのそれぞれが管理する前記ビジネスオブジェクトの属性の情報と、各属性に原データが設定されるかどうかを示す情報とに基づいて、前記参照先アプリケーションを決定する決定手段を更に備えた、請求項１記載の装置。
【請求項６】
前記決定手段は、特定のアプリケーションが管理する前記ビジネスオブジェクトの特定の属性に原データが設定される場合に、当該特定のアプリケーションを、当該特定の属性に対応する前記参照先アプリケーションとして決定する、請求項５記載の装置。
【請求項７】
複数のアプリケーションを統合するための装置において、第１のアプリケーションから受信した第１のビジネスオブジェクトを変換して得られた第２のビジネスオブジェクトを第２のアプリケーションに送信するための方法であって、
前記第１のビジネスオブジェクトから前記第２のビジネスオブジェクトへの変換のために必要な属性の値を保持する参照先アプリケーションの識別情報を記憶装置から読み込むステップと、
読み込まれた前記識別情報により示される前記参照先アプリケーションを参照することにより前記第１のビジネスオブジェクトを前記第２のビジネスオブジェクトに変換するステップと
を含む、方法。
【請求項８】
前記第１のビジネスオブジェクトから前記第２のビジネスオブジェクトへの変換は、当該第１のビジネスオブジェクトに不足する前記第２のアプリケーションに必要なデータを補うための変換である、請求項７記載の方法。
【請求項９】
前記第１のビジネスオブジェクトから前記第２のビジネスオブジェクトへの変換は、当該第１のビジネスオブジェクトにおける不可逆的に変更された部分を元に戻すための変換である、請求項７記載の方法。
【請求項１０】
前記複数のアプリケーションのそれぞれの外部とのインターフェース情報に基づいて、前記参照先アプリケーションを決定するステップを更に含む、請求項７記載の方法。
【請求項１１】
前記複数のアプリケーションのうちの特定のアプリケーションが前記第２のビジネスオブジェクトとして送信すべきデータを保持する場合に、当該特定のアプリケーションを、前記参照先アプリケーションとして決定するステップを更に含む、請求項７記載の方法。
【請求項１２】
請求項７乃至１１のいずれか１に記載の方法を、前記複数のアプリケーションを統合するための装置に実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のアプリケーションを実行する複数のコンピュータ(以下、単に「アプリケーション」としても参照する)が統合サーバによって統合されたコンピュータシステムにおいて、あるアプリケーションから別のアプリケーションへ、統合サーバを介してビジネスオブジェクトを転送する技術に関する。本明細書において、「ビジネスオブジェクト」とは、かかるコンピュータシステムにおいて使用されるビジネスデータの論理的な集合単位を意味する。具体的には、ビジネスオブジェクトを識別するオブジェクト名と、ビジネスオブジェクトを構成する複数のデータ要素の組み合わせとして表現されるものである。
【背景技術】
【０００２】
企業等の組織においては、これまで、部門ごとに業務システムが導入されることが多かった。その結果、各業務システムは、部門に閉じた動作を行うのみであり、部門間で連携した動作は行えないという状況が生じていた。
しかしながら、部門ごとのシステム間の連携がとれないのでは、組織全体としてシステムを効率的に運用することはできない。そこで、各業務システムにおけるアプリケーションを統合しようという動きが高まっている。
【０００３】
そのようなアプリケーションの統合の方法として、第一に、ＥＲＰ(Enterprise Resource Planning)システムによるものがある。ＥＲＰシステムは、組織内で実行される業務で参照/更新されるデータの全てを統合型のリポジトリに格納することにより、業務全体を統合的に管理するシステムである。所謂ビッグバン型のＥＲＰシステムを導入しようという企業も中にはある。しかしながら、ビッグバン型のＥＲＰシステムを導入するには、コストやリスクが高く、また、アプリケーションの分野ごとに最適な製品を選択できないという不利益もある。その結果、導入に踏み切る組織も少数に留まっているのが現状である。
【０００４】
また、第二に、ＥＡＩ(Enterprise Application Integration)又はＢＰＩ(Business Process Integration)によるものがある。ＥＡＩ又はＢＰＩは、複数のアプリケーションを有機的に連携させ、データやプロセスの効率的な運用を図るものである。近年では、ハブ＆スポーク型の統合が主流である。
ハブ＆スポーク型の統合は、統合サーバをハブとし、そのハブを中心に複数のアプリケーションを統合するものである。ビジネスプロセスの実行に伴い、統合サーバを経由してこれら複数のアプリケーションの間でビジネスオブジェクトのやり取りが行われる。そのようなビジネスオブジェクトのやり取りを可能にするために、統合サーバ上には共通ビジネスオブジェクトが定義されることが多い。
例えば、受注システムで製品の注文伝票が作成され、それが生産管理システムに送られる。生産管理システムでは生産計画が立てられ、実際に製品の生産が完了すると、物流システムに配送指示が出される。その際、注文ビジネスオブジェクトは、受注システム、生産管理システム、物流システムへと転送され、各システムにおいて保管、参照される。注文ビジネスオブジェクトは、統合サーバ上では共通注文ビジネスオブジェクトとして定義される。
【０００５】
しかしながら、通常は、アプリケーションごとにビジネスオブジェクトの定義内容に差異がある。従って、統合サーバ上の共通ビジネスオブジェクトに対し、属性の過不足が生じる。また、属性の過不足は生じないにしても、属性の書式やコード体系の違いから、不可逆的なデータ変換が行われる場合もある。このため、統合サーバを通した(即ち、共通ビジネスオブジェクトを通した)ビジネスオブジェクトのやり取りにおいては、ビジネスオブジェクト中の情報に欠損が生じる場合があり、統合サーバを用いたアプリケーション連携上の問題点となっている。
【０００６】
以下、このことを、共通ビジネスオブジェクトの種類別に述べる。
まず、アプリケーション間で共通な属性のみをやり取りする場合を考える。即ち、各アプリケーション固有のビジネスオブジェクトの論理積を共通ビジネスオブジェクトとする場合である。この場合は、そもそも共通する属性以外については、統合サーバ上でやり取りすることはできないので、情報の欠損が生じる。
【０００７】
また、送信側のアプリケーションで定義された属性と受信側のアプリケーションで定義された属性の両方を包含する属性をやり取りする場合を考える。即ち、各アプリケーション固有のビジネスオブジェクトの論理和を共通ビジネスオブジェクトとする場合である。しかし、共通ビジネスオブジェクトをこのように定義しただけでは、実際に情報の欠損を防ぐことはできない。
例えば、アプリケーションＡ、Ｂ、Ｃがあり、ビジネスオブジェクトが、ＡからＢ、ＢからＣと転送されるものとする。この場合において、ＡからＢへの転送で情報の欠落が生じ、その欠落した情報がＣの必要とする情報であった場合に問題となる。通常、ＡからＢへのビジネスオブジェクトの転送と、ＢからＣへのビジネスオブジェクトの転送とは、別々のプロセスで行われる。従って、ＢからＣへ転送されたビジネスオブジェクトに必要な情報がセットされていないという状況が生じるのである。
【０００８】
一方、かかる状況が生じるのを防ぐために、欠落するデータを共有データとして保存しておく方法も提案されている(例えば、特許文献１参照。)。具体的には、第１のアプリケーションから第２のアプリケーションへビジネスオブジェクトを転送する際に欠落するデータを共有データとして保存し、第２のアプリケーションから第３のアプリケーションへビジネスオブジェクトを転送する際にその保存されたデータを取り出すというものである。
【０００９】
【特許文献１】特開２００１−２３６２１５号公報(第１２、１３頁、第１５、１６図)
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、上述したような情報の不足は、必ずしも前工程における情報の欠落が原因とは限らない。アプリケーションＡ、Ｂがあり、ビジネスオブジェクトが、ＡからＢに転送されるものとする。この場合において、Ａの出力するビジネスオブジェクトの情報が、Ｂの要求するビジネスオブジェクトの情報の一部しか含んでいないことがある。各アプリケーションは、そのアプリケーションで必要となる情報のみを通常は保持しているからである。
かかる場合に、特許文献１の方法では、対処できない。即ち、特許文献１の方法では、ビジネスプロセスの上流工程のアプリケーションで作成/更新された属性が下流工程のアプリケーションで参照されることを前提としており、ビジネスプロセスの上流工程に出て来ないアプリケーションの保持する属性を参照することができないという問題点があった。
【００１１】
本発明は、以上のような技術的課題を解決するためになされたものであって、その目的は、ビジネスプロセスの上流工程に出て来ないアプリケーションの保持する属性であっても、下流工程のアプリケーションで参照することができるようにすることにある。
【課題を解決するための手段】
【００１２】
かかる目的のもと、本発明では、ビジネスオブジェクトの属性ごとにその属性の参照先アプリケーションを統合サーバに定義しておき、統合サーバがビジネスオブジェクトを転送する際に、参照先アプリケーションから取得した値を属性に設定するようにした。即ち、本発明の装置は、第１のアプリケーションからビジネスオブジェクトを受信する受信手段と、この受信手段により受信されたビジネスオブジェクトを第２のアプリケーションに送信する送信手段と、第２のアプリケーションに送信されるビジネスオブジェクトに含まれる属性ごとに、その属性の値を保持する参照先アプリケーションの識別情報を記憶する手段と、送信手段によるビジネスオブジェクトの送信に先立ち、そのビジネスオブジェクトの特定の属性に設定する値を、その特定の属性に対応する参照先アプリケーションから取得して設定する設定手段とを備えている。
【００１３】
更に、本発明は、複数のアプリケーションを統合するための装置において、第１のアプリケーションから受信した第１のビジネスオブジェクトを変換して得られた第２のビジネスオブジェクトを第２のアプリケーションに送信するための方法として捉えることもできる。その場合、本発明の方法は、第１のビジネスオブジェクトから第２のビジネスオブジェクトへの変換のために必要な属性の値を保持する参照先アプリケーションの識別情報を記憶装置から読み込むステップと、読み込まれた識別情報により示される参照先アプリケーションを参照することにより第１のビジネスオブジェクトを第２のビジネスオブジェクトに変換するステップとを含んでいる。
【００１４】
一方、本発明は、複数のアプリケーションを統合するための装置に所定の機能を実現させるためのプログラムとして捉えることもできる。
【発明の効果】
【００１５】
本発明によれば、ビジネスプロセスの上流工程に出て来ないアプリケーションの保持する属性であっても、下流工程のアプリケーションで参照することが可能となる。
【発明を実施するための最良の形態】
【００１６】
以下、添付図面を参照して、本発明を実施するための最良の形態(以下、「実施の形態」という)について詳細に説明する。
図１に示すように、本実施の形態は、コンピュータシステム１０ａと、コンピュータシステム１０ｂと、コンピュータシステム１０ｃと、コンピュータシステム１０ｄと、これらのコンピュータシステムを統合するハブとして機能する統合サーバ２０とから構成されている。また、コンピュータシステム１０ａでは、アプリケーションプログラム(以下、「ＡＰ」という)１１ａが動作し、コンピュータシステム１０ｂでは、ＡＰ１１ｂが動作し、コンピュータシステム１０ｃでは、ＡＰ１１ｃが動作し、コンピュータシステム１０ｄでは、ＡＰ１１ｄが動作する。これらのＡＰ１１ａ〜１１ｄは、統合サーバ２０にビジネスオブジェクト(以下、「ＢＯ」という)を送信し、また、統合サーバ２０からＢＯを受信する。
【００１７】
このようなシステムとしては、例えば、コンピュータシステム１０ａがＣＲＭ(Customer Relationship Management)システムであり、コンピュータシステム１０ｂがＥＲＰ(Enterprise Resource Planning)システムであり、コンピュータシステム１０ｃがＭＥＳ(Manufacturing Execution System)であり、コンピュータシステム１０ｄが配送管理システム(Logistics)であるようなものが考えられる。その場合、コンピュータシステム１０ａで顧客からの注文を受け付け、その注文情報をＢＯとしてコンピュータシステム１０ｂに送る。そして、コンピュータシステム１０ｂでは、注文された製品の生産計画を立て、生産指示をＢＯとしてコンピュータシステム１０ｃに送る。その後、実際に製品が生産されると、コンピュータシステム１０ｃからコンピュータシステム１０ｄへ配送指示がＢＯとして送られる。
尚、図１では、４つのコンピュータシステムを示したが、コンピュータシステムの数は３つ以下であってもよいし、５つ以上であってもよい。
【００１８】
図２は、本実施の形態における統合サーバ２０として用いるのに好適なコンピュータのハードウェア構成の例を模式的に示した図である。
図２に示すコンピュータは、演算手段であるＣＰＵ(Central Processing Unit)２０ａと、Ｍ/Ｂ(マザーボード)チップセット２０ｂ及びＣＰＵバスを介してＣＰＵ２０ａに接続されたメインメモリ２０ｃと、同じくＭ/Ｂチップセット２０ｂ及びＡＧＰ(Accelerated Graphics Port)を介してＣＰＵ２０ａに接続されたビデオカード２０ｄ及びディスプレイ２０ｊとを備える。また、ＰＣＩ(Peripheral Component Interconnect)バスを介してＭ/Ｂチップセット２０ｂに接続された磁気ディスク装置(ＨＤＤ)２０ｅと、ネットワークインターフェイス２０ｇとを備える。更に、このＰＣＩバスからブリッジ回路２０ｆ及びＩＳＡ(Industry Standard Architecture)バス等の低速なバスを介してＭ/Ｂチップセット２０ｂに接続されたフレキシブルディスクドライブ２０ｈとキーボード/マウス２０ｉとを備える。
【００１９】
尚、図２は本実施の形態を実現するコンピュータのハードウェア構成を例示するに過ぎず、本実施の形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード２０ｄを設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ２０ａにてイメージデータを処理する構成としてもよいし、外部記憶装置として、ＡＴＡ(AT Attachment)やＳＣＳＩ(Small Computer System Interface)等のインターフェイスを介してＣＤ−Ｒ(Compact Disc Recordable)やＤＶＤ−ＲＡＭ(Digital Versatile Disc Random Access Memory)のドライブを設けてもよい。
【００２０】
次に、図３を参照して、本実施の形態における統合サーバ２０の機能構成を説明する。
本実施の形態における統合サーバ２０は、ＢＯ受信部２１と、ビジネスプロセス定義記憶部２２と、ビジネスプロセス定義取得部２３と、参照定義記憶部２４と、属性設定部２５と、ＢＯ送信部２６と、Ｉ/Ｆ定義記憶部２７と、参照定義生成部２８とを備える。
ＢＯ受信部２１は、送信元ＡＰからＢＯを受信する。ビジネスプロセス定義記憶部２２は、ビジネスプロセスに関する定義を記憶する。ビジネスプロセス定義取得部２３は、受信したＢＯ(以下、「受信ＢＯ」という)に対応するビジネスプロセス定義を取得する。尚、ビジネスプロセス定義の具体例は後述する。
【００２１】
また、参照定義記憶部２４は、送信するＢＯ(以下、「送信ＢＯ」という)の属性に設定する値を取得するために参照されるＡＰ(以下、「参照先ＡＰ」という)を定義した参照定義を記憶する。尚、参照定義の具体例も後述する。属性設定部２５は、この参照定義を参照し、必要に応じて参照先ＡＰから取得した値を送信ＢＯの属性に設定する。
ＢＯ送信部２６は、属性が設定された送信ＢＯを送信先ＡＰに送信する。
一方、Ｉ/Ｆ定義記憶部２７は、統合サーバ２０とやり取りする際における各ＢＯの属性を定義したインターフェース定義(以下、「Ｉ/Ｆ定義」という)を記憶する。尚、Ｉ/Ｆ定義の具体例も後述する。また、参照定義生成部２８は、Ｉ/Ｆ定義から参照定義を自動生成する機能部分であり、参照先ＡＰを決定する決定手段として捉えることもできる。
【００２２】
尚、これらの各機能部分は、ソフトウェアとハードウェア資源とが協働することにより実現される。具体的には、統合サーバ２０のＣＰＵが、ＢＯ受信部２１、ビジネスプロセス定義取得部２３、属性設定部２５、ＢＯ送信部２６、参照定義生成部２８を実現するプログラムを外部記憶装置から主記憶装置に読み込み、外部記憶装置としてのビジネスプロセス定義記憶部２２、参照定義記憶部２４、Ｉ/Ｆ定義記憶部２７に記憶された情報を必要に応じて参照しながら処理を行う。
【００２３】
ここで、図４を参照して、ビジネスプロセス定義記憶部２２の具体的な記憶内容を説明する。
図示するように、ビジネスプロセス定義記憶部２２には、送信元ＡＰと、ＢＯタイプと、ビジネスプロセス定義と、参照定義との対応が記憶されている。即ち、ビジネスプロセス定義とは、ある送信元ＡＰからあるタイプのＢＯを受信した場合に、どのようなビジネスプロセスを実行し、その際、どの参照定義を用いればよいかを定義したものである。
例えば、送信元ＡＰ「Ａｐｐ−Ｘ」からＢＯタイプ「ＢＯ−Ａ」のＢＯを受信したとすると、「ＢＯを『Ａｐｐ−Ｚ』に転送する」というビジネスプロセスが実行される。また、その際、送信ＢＯの属性には、参照定義「ＲＦ−Ａ」に定義される参照先ＡＰから得られた値が必要に応じて設定されることになる。
【００２４】
次に、図５を参照して、参照定義記憶部２４及びＩ/Ｆ定義記憶部２７の具体的な記憶内容及び本実施の形態の動作の概略を説明する。尚、図５は、属性ａ、ｂ、ｃを有するＢＯ「ＢＯ−Ａ」の「KEY=1001」に対するレコードが、「Ａｐｐ−Ｘ」から統合サーバ２０を経由して「Ａｐｐ−Ｚ」へ送られる場合について示したものである。
従って、参照定義記憶部２４に記憶された参照定義としては、図４において送信先「Ａｐｐ−Ｘ」、ＢＯタイプ「ＢＯ−Ａ」に対応付けられた「ＲＦ−Ａ」を示している。具体的には、参照定義「ＲＦ−Ａ」は、属性ａ、ｂ、ｃに設定する値を、それぞれ、「Ａｐｐ−Ｘ」、「Ａｐｐ−Ｙ」、「Ａｐｐ−Ｚ」から取得すべきことを定義している。これにより、本実施の形態は、概略以下のように動作する。
【００２５】
まず、「ＢＯ−Ａ」の「KEY=1001」に対するレコードが、矢印１で示すように、「Ａｐｐ−Ｘ」から統合サーバ２０へ送信される。その際、「ＢＯ−Ａ」の属性ａ、ｂ、ｃには、「xxxx」、「????」、「zzzz」が設定されている。
そこで、統合サーバ２０は、参照定義「ＲＦ−Ａ」を参照し、各属性に設定する値の入手先を得る。具体的には、属性ａに設定する値は「Ａｐｐ−Ｘ」から、属性ｂに設定する値は「Ａｐｐ−Ｙ」から、属性ｃに設定する値は「Ａｐｐ−Ｚ」からそれぞれ取得すべきことを知る。属性ａについては、参照先ＡＰが送信元ＡＰと同じなので、受信ＢＯの属性をそのまま送信ＢＯの属性として送ればよいので、属性に設定する値を参照先ＡＰに問い合わせて取得する処理は行わない。属性ｃについても、参照先ＡＰが送信先ＡＰと同じなので、送信ＢＯの属性への値の設定は送信先で行うこともできるので、属性に設定する値を参照先ＡＰに問い合わせて取得する処理は行わない。
【００２６】
一方、属性ｂについては、参照先ＡＰが送信元ＡＰとも送信先ＡＰとも異なるので、参照先ＡＰに問い合わせて取得する処理を行う。即ち、矢印２で示すように、「Ａｐｐ−Ｙ」から属性ｂに設定する値である「yyyy」を取得する。具体的には、統合サーバ２０が「ＢＯ−Ａ」の「KEY=1001」に対するレコードの送信を「Ａｐｐ−Ｙ」に対して要求すると、「Ａｐｐ−Ｙ」は、その応答として「yyyy」を含むレコードを統合サーバ２０に返信する。そして、矢印３で示すように、属性ｂに「yyyy」が設定された「ＢＯ−Ａ」が統合サーバ２０から「Ａｐｐ−Ｚ」に渡される。
【００２７】
ところで、参照定義は、ビジネスプロセスの特性を考慮しつつ、各属性に設定する値の参照先ＡＰを手作業で定義して記憶するようにしてもよい。或いは、各アプリケーションにおけるビジネスオブジェクトのＩ/Ｆ定義に基づいて自動生成するようにしてもよい。
Ｉ/Ｆ定義記憶部２７は、「Ａｐｐ−Ｘ」、「Ａｐｐ−Ｙ」、「Ａｐｐ−Ｚ」のそれぞれのＩ/Ｆ定義を記憶している。具体的には、「Ａｐｐ−Ｘ」のＩ/Ｆ定義「ＩＦ−Ａ−Ｘ」では、「Ａｐｐ−Ｘ」が、属性ａについては、所有して変更でき、属性ｂについては、所有せず変更もできず、属性ｃについては、所有しないが変更できることを記憶している。また、「Ａｐｐ−Ｙ」のＩ/Ｆ定義「ＩＦ−Ａ−Ｙ」では、「Ａｐｐ−Ｙ」が、属性ａについては、所有しないが変更でき、属性ｂについては、所有して変更でき、属性ｃについては、所有しないが変更できることを記憶している。更に、「Ａｐｐ−Ｚ」のＩ/Ｆ定義「ＩＦ−Ａ−Ｚ」では、「Ａｐｐ−Ｚ」が、属性ａについては、所有しないが変更でき、属性ｂについては、所有しないが変更でき、属性ｃについては、所有して変更できることを記憶している。
【００２８】
図５の例では、ＢＯの各属性に設定する値を、その属性を所有して変更できるＡＰ、つまり、その属性の原データ(オリジナルデータ)を有するＡＰ(以下、「オーナＡＰ」という)から取得することとしている。従って、Ｉ/Ｆ定義「ＩＦ−Ａ−Ｘ」に「Ａｐｐ−Ｘ」が属性ａについてのオーナＡＰであることが記憶されているので、参照定義では、属性ａの参照先ＡＰが「Ａｐｐ−Ｘ」となっている。また、Ｉ/Ｆ定義「ＩＦ−Ａ−Ｙ」に「Ａｐｐ−Ｙ」が属性ｂについてのオーナＡＰであることが記憶されているので、参照定義では、属性ｂの参照先ＡＰが「Ａｐｐ−Ｙ」となっている。更に、Ｉ/Ｆ定義「ＩＦ−Ａ−Ｚ」に「Ａｐｐ−Ｚ」が属性ｃについてのオーナＡＰであることが記憶されているので、参照定義では、属性ｃの参照先ＡＰが「Ａｐｐ−Ｚ」となっている。
【００２９】
ここで、図６を参照しながら、Ｉ/Ｆ定義から参照定義を自動生成する際の一般的な動作を説明する。
まず、参照定義生成部２８は、ビジネスプロセス定義記憶部２２から特定の送信元ＡＰ、特定のＢＯタイプのビジネスプロセス定義を選択し(ステップ２０１)、１つの送信先ＡＰに着目する(ステップ２０２)。図４の例において、送信元「Ａｐｐ−Ｘ」、ＢＯタイプ「ＢＯ−Ａ」に対応するビジネスプロセスを選択したとすると、送信先「Ａｐｐ−Ｚ」に着目する。
そして、その送信先ＡＰのＩ/Ｆ定義で、１つの属性に着目する(ステップ２０３)。図５の例では、属性ａ、ｂ、ｃに所定の順序で着目する。
【００３０】
次に、参照定義生成部２８は、着目した属性がキー項目であるかどうかを判定し(ステップ２０４)、キー項目であれば、送信元ＡＰを参照定義の参照先ＡＰに設定する(ステップ２０８)。図５の例では、属性ａ、ｂ、ｃのいずれもキー項目ではないので、ステップ２０５に進む。
また、参照定義生成部２８は、着目した属性が送信先ＡＰのＩ/Ｆ定義における(所有、変更)が(Ｙ、Ｙ)となっているかどうか判定し(ステップ２０５)、(Ｙ、Ｙ)となっていれば、送信先ＡＰを参照定義の参照先ＡＰに設定する(ステップ２１０)。図５の例では、属性ｃがこの条件を満足するので、参照定義において、属性ｃに対し、送信先ＡＰである「Ａｐｐ−Ｚ」が設定される。
【００３１】
更に、参照定義生成部２８は、着目した属性が送信元ＡＰのＩ/Ｆ定義に含まれているかどうかを判定し(ステップ２０６)、Ｉ/Ｆ定義に含まれていなければ、ステップ２０９に進む。
一方、Ｉ/Ｆ定義に含まれていれば、送信元ＡＰのＩ/Ｆ定義における(所有、変更)が(Ｙ、Ｙ)となっているかどうかを判定する(ステップ２０７)。その結果、(Ｙ、Ｙ)となっていれば、送信元ＡＰを参照定義の参照先ＡＰに設定する(ステップ２０８)。図５の例では、属性ａがこの条件を満足するので、参照定義において、属性ａに対し、送信元ＡＰである「Ａｐｐ−Ｘ」が設定される。
【００３２】
また、ステップ２０６でＩ/Ｆ定義に含まれていないと判定された場合、又は、ステップ２０７で送信元ＡＰのＩ/Ｆ定義における(所有、変更)が(Ｙ、Ｙ)となっていないと判定された場合は、必要に応じてオーナＡＰを参照先に設定する(ステップ２０９)。図５の例では、属性ｂが後者の条件を満足するので、参照定義において、属性ｂに対し、そのオーナＡＰである「Ａｐｐ−Ｙ」が設定される。
そして、参照定義生成部２８は、他に属性があるかどうかを判定し(ステップ２１１)、属性があれば、ステップ２０３〜２１０の処理を繰り返す。一方、属性がなければ、他に送信先ＡＰがあるかどうかを判定する(ステップ２１２)。その結果、送信先ＡＰがあれば、ステップ２０２〜２１１の処理を繰り返し、送信先ＡＰがなければ、処理を終了する。
【００３３】
次に、図７を参照して、統合サーバ２０がＢＯを転送する際の一般的な動作を説明する。
まず、ＢＯ受信部２１が、送信元ＡＰからＢＯを受信する(ステップ２２１)。
そして、ビジネスプロセス定義取得部２３が、ビジネスプロセス定義記憶部２２を参照し、送信元ＡＰ及び受信ＢＯのＢＯタイプに対応するビジネスプロセスの定義を選択する(ステップ２２２)。図４の例では、送信元ＡＰ「Ａｐｐ−Ｘ」とＢＯタイプ「ＢＯ−Ａ」に対して定義されたビジネスプロセスである「Ａｐｐ−Ｚに転送」を取得する。
その後、属性設定部２５は、１つの送信先ＡＰに着目し(ステップ２２３)、この送信元ＡＰと送信先ＡＰとの組み合わせに対して定義された参照定義で１つの属性に着目する(ステップ２２４)。図４及び図５の例では、送信元ＡＰ「Ａｐｐ−Ｘ」、送信先ＡＰ「Ａｐｐ−Ｚ」の組み合わせに対して定義された参照定義「ＲＦ−Ａ」を取得し、属性ａ、ｂ、ｃに所定の順序で着目する。
【００３４】
次に、属性設定部２５は、参照定義の参照先ＡＰの欄を参照し、参照先ＡＰが送信先ＡＰであるか、送信元ＡＰであるか、その他のＡＰであるかを判定する(ステップ２２５)。
この判定の結果、参照先ＡＰが送信先ＡＰである場合は、何もせずにステップ２２９に進む。また、参照先ＡＰが送信元ＡＰである場合は、受信ＢＯのその属性に設定された値をそのまま送信ＢＯの同じ属性に設定し(ステップ２２６)、ステップ２２９に進む。更に、参照先ＡＰがその他のＡＰである場合は、その参照先ＡＰからその属性の値を読み取り(ステップ２２７)、その値を送信ＢＯの同じ属性に設定する(ステップ２２８)。
図５の例において、属性ａに着目した場合は、参照先ＡＰは送信元ＡＰと同じであるので受信ＢＯの属性の値を送信ＢＯの属性の値に設定してステップ２２９に進む。属性ｂに着目した場合は、参照先ＡＰは送信元ＡＰとも送信先ＡＰとも異なるので参照先ＡＰから値を取得して属性ｂに設定し、ステップ２２９に進む。また、属性ｃに着目した場合は、参照先ＡＰは送信先ＡＰと同じであるので何もせずにステップ２２９に進む。
【００３５】
その後、他に属性があるかどうかが判定され(ステップ２２９)、他に属性があれば、ステップ２２４〜２２８の処理を繰り返す。他に属性がなければ、ＢＯ送信部２６が、送信ＢＯを送信先ＡＰに送信する(ステップ２３０)。
最後に、他に送信先があるかどうかが判定され(ステップ２３１)、他に送信先があれば、ステップ２２３〜２３０の処理を繰り返し、他に送信先がなければ、処理を終了する。
尚、図５の例では、送信先として「Ａｐｐ−Ｚ」しか想定していなかったため、ステップ２２３〜２３０の処理は一回しか行われなかった。しかしながら、図４に示す、送信元ＡＰ「Ａｐｐ−Ｚ」からＢＯタイプ「ＢＯ−Ｅ」のＢＯを受信した場合のように、送信先ＡＰが複数存在するときは、ステップ２２３〜２３０の処理は、その送信先ＡＰの数だけ繰り返される。
【００３６】
次に、具体例を用いて、本実施の形態を説明する。
この具体例は、図８に示すように、受注管理を行う「Ａｐｐ−Ｘ」と、生産管理を行う「Ａｐｐ−Ｙ」と、配送管理を行う「Ａｐｐ−Ｚ」とが統合サーバ２０により統合されたシステムにおけるものである。また、「Ａｐｐ−Ｘ」、「Ａｐｐ−Ｙ」、「Ａｐｐ−Ｚ」のそれぞれにおけるＩ/Ｆ定義は、図示するようなものであるとする。
このシステムでは、まず、「Ａｐｐ−Ｘ」が、「Ａｐｐ−Ｙ」に注文ＢＯを送信することにより、注文された製品の生産を指示する(生産指示ビジネスプロセス)。次に、「Ａｐｐ−Ｙ」が、「Ａｐｐ−Ｚ」に注文ＢＯを送信することにより、生産された製品の配送を指示する(配送指示ビジネスプロセス)。最後に、「Ａｐｐ−Ｚ」が、「Ａｐｐ−Ｘ」に注文ＢＯを送信することにより、製品の配送の完了を通知する(配送完了通知ビジネスプロセス)。
以下、これらのビジネスプロセスにおける詳細な動作を順に説明する。
【００３７】
(生産指示ビジネスプロセス)
図９を参照しながら、生産指示ビジネスプロセスについて説明する。尚、各注文ＢＯの属性に設定される値の後の「()」は、その値がどのアプリケーションから得られたものであるかを示している。
生産指示ビジネスプロセスの実行に先立ち、図９に示すような参照定義(注文ＢＯ参照定義)が生成されている。この参照定義を生成する動作を、図６の流れに沿って説明する。
まず、ステップ２０１で生産指示ビジネスプロセス定義が選択され、ステップ２０２で送信先ＡＰとして「Ａｐｐ−Ｙ」が選択される。
ステップ２０３で送信先ＡＰ「Ａｐｐ−Ｙ」のＩ/Ｆ定義である「Ｙ−注文ＢＯＩ/Ｆ定義」に定義される属性「注文番号(KEY)」に着目する。ステップ２０４で「注文番号(KEY)」はキー項目であると判定されるので、ステップ２０８に進み、図９の「注文ＢＯ参照定義」に参照先ＡＰとして、送信元ＡＰである「Ａｐｐ−Ｘ」が設定される。そして、ステップ２１１で他に属性があると判定されるので、ステップ２０３に戻る。
【００３８】
次に、ステップ２０３で送信先ＡＰ「Ａｐｐ−Ｙ」のＩ/Ｆ定義である「Ｙ−注文ＢＯＩ/Ｆ定義」に定義される次の属性「製品番号」に着目する。ステップ２０４で「製品番号」はキー項目でないと判定されるので、ステップ２０５に進む。また、送信先ＡＰ「Ａｐｐ−Ｙ」のＩ/Ｆ定義で(所有、変更)が(Ｙ、Ｙ)ではないので、ステップ２０６に進む。更に、属性「製品番号」が送信元ＡＰ「Ａｐｐ−Ｘ」のＩ/Ｆ定義に存在しているので、ステップ２０７に進む。更にまた、送信元ＡＰ「Ａｐｐ−Ｘ」のＩ/Ｆ定義で(所有、変更)が(Ｙ、Ｙ)であるので、ステップ２０８に進み、図９の「注文ＢＯ参照定義」に参照先ＡＰとして、送信元ＡＰである「Ａｐｐ−Ｘ」が設定される。そして、ステップ２１１で他に属性があると判定されるので、ステップ２０３に戻る。
【００３９】
その後、送信先ＡＰ「Ａｐｐ−Ｙ」のＩ/Ｆ定義である「Ｙ−注文ＢＯＩ/Ｆ定義」に定義される次の属性「個数」に着目し、同様の処理を行い、図９の「注文ＢＯ参照定義」に参照先ＡＰとして、送信元ＡＰである「Ａｐｐ−Ｘ」が設定される。また、属性「納期」についても同様に送信元ＡＰである「Ａｐｐ−Ｘ」が設定される。そして、ステップ２１１で他に属性があると判定されるので、ステップ２０３に戻る。
【００４０】
次に、ステップ２０３で送信先ＡＰ「Ａｐｐ−Ｙ」のＩ/Ｆ定義である「Ｙ−注文ＢＯＩ/Ｆ定義」に定義される次の属性「工場出荷予定日」に着目する。ステップ２０４で「工場出荷予定日」はキー項目でないと判定されるので、ステップ２０５に進む。そして、送信先ＡＰ「Ａｐｐ−Ｙ」のＩ/Ｆ定義で(所有、変更)が(Ｙ、Ｙ)であるので、ステップ２１０に進み、図９の「注文ＢＯ参照定義」に参照先ＡＰとして、「Ｎｏｎｅ」が設定される。尚、「Ｎｏｎｅ」とは、その属性の値として送信先ＡＰにおける値を設定するので、転送する際には値を設定しないことを示すものである。
【００４１】
また、図９に示す注文ＢＯ参照定義が生成された後、「Ａｐｐ−Ｘ」から注文ＢＯを受信した統合サーバ２０の動作を、図７の流れに沿って説明する。
まず、ステップ２２１で「Ａｐｐ−Ｘ」から注文ＢＯを受信し、ステップ２２２でビジネスプロセス定義として「『Ａｐｐ−Ｙ』に転送する」を取得する。
次に、ステップ２２３で送信先ＡＰ「Ａｐｐ−Ｙ」に着目し、ステップ２２４で図９の「注文ＢＯ参照定義」に定義された属性「注文番号(KEY)」に着目する。ステップ２２５で参照先ＡＰが送信元ＡＰ「Ａｐｐ−Ｘ」と判定されるので、受信ＢＯの属性「注文番号(KEY)」に設定された値を送信ＢＯの属性「注文番号(KEY)」に設定する。そして、ステップ２２９で他に属性があると判定されるので、ステップ２２４に戻る。
【００４２】
その後、ステップ２２４で図９の「注文ＢＯ参照定義」に定義された次の属性「製品番号」に着目し、同様の処理を行い、受信ＢＯの属性「製品番号」に設定された値を送信ＢＯの属性「製品番号」に設定する。また、属性「個数」、「納期」についても同様に受信ＢＯの該当する属性に設定された値を送信ＢＯの同じ属性に設定する。そして、ステップ２２９で他に属性があると判定されるので、ステップ２２４に戻る。
【００４３】
次に、ステップ２２４で図９の「注文ＢＯ参照定義」に定義された次の属性「工場出荷予定日」に着目する。ステップ２２５で参照先ＡＰに「Ｎｏｎｅ」が設定されていることが分かるので、送信ＢＯの属性「工場出荷予定日」には何も設定しない。そして、ステップ２２９で他に属性がないと判定されるので、ステップ２３０に進み、値が設定された送信ＢＯが送信される。その後、ステップ２３１で「Ａｐｐ−Ｙ」以外に送信先はないと判定されるので、処理は終了する。
【００４４】
(配送指示ビジネスプロセス)
図１０を参照しながら、配送指示ビジネスプロセスについて説明する。尚、各注文ＢＯの属性に設定される値の後の「()」は、その値がどのアプリケーションから得られたものであるかを示している。
配送指示ビジネスプロセスの実行に先立ち、図１０に示すような参照定義(注文ＢＯ参照定義)が生成されている。この参照定義を生成する動作を、図６の流れに沿って説明する。
まず、ステップ２０１で配送指示ビジネスプロセス定義が選択され、ステップ２０２で送信先ＡＰとして「Ａｐｐ−Ｚ」が選択される。
ステップ２０３で送信先ＡＰ「Ａｐｐ−Ｚ」のＩ/Ｆ定義である「Ｚ−注文ＢＯＩ/Ｆ定義」に定義される属性「注文番号(KEY)」に着目する。ステップ２０４で「注文番号(KEY)」はキー項目であると判定されるので、ステップ２０８に進み、図１０の「注文ＢＯ参照定義」に参照先ＡＰとして、送信元ＡＰである「Ａｐｐ−Ｙ」が設定される。そして、ステップ２１１で他に属性があると判定されるので、ステップ２０３に戻る。
【００４５】
次に、ステップ２０３で送信先ＡＰ「Ａｐｐ−Ｚ」のＩ/Ｆ定義である「Ｚ−注文ＢＯＩ/Ｆ定義」に定義される次の属性「製品番号」に着目する。ステップ２０４で「製品番号」はキー項目でないと判定されるので、ステップ２０５に進む。また、送信先ＡＰ「Ａｐｐ−Ｚ」のＩ/Ｆ定義で(所有、変更)が(Ｙ、Ｙ)ではないので、ステップ２０６に進む。更に、属性「製品番号」が送信元ＡＰ「Ａｐｐ−Ｙ」のＩ/Ｆ定義に存在しているので、ステップ２０７に進む。更にまた、送信元ＡＰ「Ａｐｐ−Ｙ」のＩ/Ｆ定義で(所有、変更)が(Ｙ、Ｙ)ではないので、ステップ２０９に進む。
【００４６】
ところで、属性「製品番号」の場合、「Ａｐｐ−Ｘ」から受信した値が「Ａｐｐ−Ｙ」にて変更されている可能性がある。例えば、図１０に示すように、「Ａｐｐ−Ｘ」から「製品番号」として「M001」を受信したものの、「Ａｐｐ−Ｙ」において「製品番号」を、実際に製造される製品に適用される仕様変更情報を付加した「M001-E1」に変更するような場合である。本具体例では、かかる変更を、不可逆的な変更と捉え、「Ａｐｐ−Ｚ」に送信するＢＯの属性に設定する値を改めて「Ａｐｐ−Ｘ」から取得するようにしている。即ち、図１０の「注文ＢＯ参照定義」に参照先ＡＰとして、オーナＡＰである「Ａｐｐ−Ｘ」が設定される。そして、ステップ２１１で他に属性があると判定されるので、ステップ２０３に戻る。
【００４７】
尚、上述した不可逆的な変更の例としては、図１０に示したもの以外に、次のようなものも考えられる。
(１) データ形式が異なる場合
「Ａｐｐ−Ｘ」のＩ/Ｆ定義で定義される属性のデータ形式と「Ａｐｐ−Ｙ」のＩ/Ｆ定義で定義される属性のデータ形式とが異なるため、「Ａｐｐ−Ｘ」から「Ａｐｐ−Ｙ」へビジネスオブジェクトを転送した際に情報が欠落してしまう場合である。
例えば、郵便番号を、「Ａｐｐ−Ｘ」では７桁で定義し、「Ａｐｐ−Ｙ」では５桁で定義していたとする。この場合、「Ａｐｐ−Ｙ」では郵便番号の６、７桁目を受け取ることはできないので、「Ａｐｐ−Ｘ」から改めて郵便番号の値を取得することになるのである。
また、住所を、「Ａｐｐ−Ｘ」では、都道府県、市町村等に分けて定義しているが、「Ａｐｐ−Ｙ」では、１つの属性にまとめて定義している場合も考えられる。この場合、１つの属性にまとめられたものを都道府県、市町村等に分ける機能が統合サーバ２０に存在すれば問題はないが、もしそのような機能が存在しない場合は、「Ａｐｐ−Ｘ」から改めて住所の値を取得することになる。
【００４８】
(２) コード体系が異なる場合
「Ａｐｐ−Ｘ」で用いる文字コードの体系と「Ａｐｐ−Ｙ」で用いる文字コードの体系とが異なるため、「Ａｐｐ−Ｘ」から「Ａｐｐ−Ｙ」へビジネスオブジェクトを転送した際に情報が欠落してしまう場合である。例えば、「Ａｐｐ−Ｘ」では、文字「Ａ」に対応する文字コードが「1111」であり、文字「Ａ’」に対応する文字コードが「1112」であるとする。また、「Ａｐｐ−Ｙ」では、文字「Ａ」に対応する文字コードは「1111」であるが、文字「Ａ’」に対応する文字コードは存在しないものとする。この場合、「Ａｐｐ−Ｘ」から文字「Ａ’」(文字コード「1112」)を送信したとしても、「Ａｐｐ−Ｙ」では、文字コード「1111」としか認識できず、本来の文字が「Ａ」であるのか「Ａ’」であるのかの区別がつかなくなる。従って、「Ａｐｐ−Ｘ」から改めて文字を取得することになるのである。
【００４９】
さて、再び、図１０の動作の説明を続ける。
ステップ２０３で送信先ＡＰ「Ａｐｐ−Ｚ」のＩ/Ｆ定義である「Ｚ−注文ＢＯＩ/Ｆ定義」に定義される次の属性「個数」に着目する。ステップ２０４で「個数」はキー項目でないと判定されるので、ステップ２０５に進む。また、送信先ＡＰ「Ａｐｐ−Ｚ」のＩ/Ｆ定義で(所有、変更)が(Ｙ、Ｙ)ではないので、ステップ２０６に進む。更に、属性「個数」が送信元ＡＰ「Ａｐｐ−Ｙ」のＩ/Ｆ定義に存在しているので、ステップ２０７に進む。更にまた、送信元ＡＰ「Ａｐｐ−Ｙ」のＩ/Ｆ定義で(所有、変更)が(Ｙ、Ｙ)ではないので、ステップ２０９に進む。本具体例では、かかる場合、送信元ＡＰを参照先ＡＰとすることとし、図１０の「注文ＢＯ参照定義」に参照先ＡＰとして、送信元ＡＰである「Ａｐｐ−Ｙ」が設定される。そして、ステップ２１１で他に属性があると判定されるので、ステップ２０３に戻る。
【００５０】
その後、送信先ＡＰ「Ａｐｐ−Ｚ」のＩ/Ｆ定義である「Ｚ−注文ＢＯＩ/Ｆ定義」に定義される次の属性「納期」に着目し、同様の処理を行い、図１０の「注文ＢＯ参照定義」に参照先ＡＰとして、送信元ＡＰである「Ａｐｐ−Ｙ」が設定される。そして、ステップ２１１で他に属性があると判定されるので、ステップ２０３に戻る。
【００５１】
次に、ステップ２０３で送信先ＡＰ「Ａｐｐ−Ｚ」のＩ/Ｆ定義である「Ｚ−注文ＢＯＩ/Ｆ定義」に定義される次の属性「顧客名」に着目する。ステップ２０４で「顧客名」はキー項目でないと判定されるので、ステップ２０５に進む。また、送信先ＡＰ「Ａｐｐ−Ｚ」のＩ/Ｆ定義で(所有、変更)が(Ｙ、Ｙ)ではないので、ステップ２０６に進む。更に、属性「顧客名」が送信元ＡＰ「Ａｐｐ−Ｙ」のＩ/Ｆ定義に存在していないので、ステップ２０９に進む。本具体例では、かかる場合、オーナＡＰを参照先ＡＰとすることとし、図１０の「注文ＢＯ参照定義」に参照先ＡＰとして、オーナＡＰである「Ａｐｐ−Ｘ」が設定される。そして、ステップ２１１で他に属性があると判定されるので、ステップ２０３に戻る。
【００５２】
その後、送信先ＡＰ「Ａｐｐ−Ｚ」のＩ/Ｆ定義である「Ｚ−注文ＢＯＩ/Ｆ定義」に定義される次の属性「配達先住所」に着目し、同様の処理を行い、図１０の「注文ＢＯ参照定義」に参照先ＡＰとして、オーナＡＰである「Ａｐｐ−Ｘ」が設定される。また、属性「連絡先」についても同様にオーナＡＰである「Ａｐｐ−Ｘ」が設定される。そして、ステップ２１１で他に属性があると判定されるので、ステップ２０３に戻る。
【００５３】
次に、ステップ２０３で送信先ＡＰ「Ａｐｐ−Ｚ」のＩ/Ｆ定義である「Ｚ−注文ＢＯＩ/Ｆ定義」に定義される次の属性「工場出荷予定日」に着目する。ステップ２０４で「工場出荷予定日」はキー項目でないと判定されるので、ステップ２０５に進む。また、送信先ＡＰ「Ａｐｐ−Ｚ」のＩ/Ｆ定義で(所有、変更)が(Ｙ、Ｙ)ではないので、ステップ２０６に進む。更に、属性「工場出荷予定日」が送信元ＡＰ「Ａｐｐ−Ｙ」のＩ/Ｆ定義に存在しているので、ステップ２０７に進む。更にまた、送信元ＡＰ「Ａｐｐ−Ｙ」のＩ/Ｆ定義で(所有、変更)が(Ｙ、Ｙ)であるので、ステップ２０８に進み、図１０の「注文ＢＯ参照定義」に参照先ＡＰとして、送信元ＡＰである「Ａｐｐ−Ｙ」が設定される。そして、ステップ２１１で他に属性があると判定されるので、ステップ２０３に戻る。
【００５４】
次に、送信先ＡＰ「Ａｐｐ−Ｚ」のＩ/Ｆ定義である「Ｚ−注文ＢＯＩ/Ｆ定義」に定義される次の属性「配達日」に着目する。ステップ２０４で「配達日」はキー項目でないと判定されるので、ステップ２０５に進む。そして、送信先ＡＰ「Ａｐｐ−Ｚ」のＩ/Ｆ定義で(所有、変更)が(Ｙ、Ｙ)であるので、ステップ２１０に進み、図１０の「注文ＢＯ参照定義」に参照先ＡＰとして、「Ｎｏｎｅ」が設定される。尚、「Ｎｏｎｅ」とは、その属性の値として送信先ＡＰにおける値を設定するので、転送する際には値を設定しないことを示すものである。
【００５５】
また、図１０に示す注文ＢＯ参照定義が生成された後、「Ａｐｐ−Ｙ」から注文ＢＯを受信した統合サーバ２０の動作を、図７の流れに沿って説明する。
まず、ステップ２２１で「Ａｐｐ−Ｙ」から注文ＢＯを受信し、ステップ２２２でビジネスプロセス定義として「『Ａｐｐ−Ｚ』に転送する」を取得する。
次に、ステップ２２３で送信先ＡＰ「Ａｐｐ−Ｚ」に着目し、ステップ２２４で図１０の「注文ＢＯ参照定義」に定義された属性「注文番号(KEY)」に着目する。ステップ２２５で参照先ＡＰが送信元ＡＰ「Ａｐｐ−Ｙ」と判定されるので、受信ＢＯの属性「注文番号(KEY)」に設定された値を送信ＢＯの属性「注文番号(KEY)」に設定する。そして、ステップ２２９で他に属性があると判定されるので、ステップ２２４に戻る。
【００５６】
次に、ステップ２２４で図１０の「注文ＢＯ参照定義」に定義された次の属性「製品番号」に着目する。ステップ２２５で参照先ＡＰが送信元ＡＰでも送信先ＡＰでもない「Ａｐｐ−Ｘ」と判定されるので、ステップ２２７で「Ａｐｐ−Ｘ」から属性「製品番号」に設定すべき値を取得し、ステップ２２８でその値を送信ＢＯの属性「製品番号」に設定する。そして、ステップ２２９で他に属性があると判定されるので、ステップ２２４に戻る。
【００５７】
次に、ステップ２２４で図１０の「注文ＢＯ参照定義」に定義された次の属性「個数」に着目する。ステップ２２５で参照先ＡＰが送信元ＡＰ「Ａｐｐ−Ｙ」と判定されるので、受信ＢＯの属性「個数」に設定された値が送信ＢＯの属性「個数」に設定される。また、属性「納期」についても同様の動作を行う。そして、ステップ２２９で他に属性があると判定されるので、ステップ２２４に戻る。
【００５８】
次に、ステップ２２４で図１０の「注文ＢＯ参照定義」に定義された次の属性「顧客名」に着目する。ステップ２２５で参照先ＡＰが送信元ＡＰでも送信先ＡＰでもない「Ａｐｐ−Ｘ」と判定されるので、ステップ２２７で「Ａｐｐ−Ｘ」から属性「顧客名」に設定すべき値を取得し、ステップ２２８でその値を送信ＢＯの属性「顧客名」に設定する。また、属性「配達先住所」、「連絡先」についても同様の動作を行う。そして、ステップ２２９で他に属性があると判定されるので、ステップ２２４に戻る。
【００５９】
次に、ステップ２２４で図１０の「注文ＢＯ参照定義」に定義された次の属性「工場出荷予定日」に着目する。ステップ２２５で参照先ＡＰが送信元ＡＰ「Ａｐｐ−Ｙ」と判定されるので、受信ＢＯの属性「工場出荷予定日」に設定された値が送信ＢＯの属性「工場出荷予定日」に設定される。そして、ステップ２２９で他に属性があると判定されるので、ステップ２２４に戻る。
【００６０】
次に、ステップ２２４で図１０の「注文ＢＯ参照定義」に定義された次の属性「配達日」に着目する。ステップ２２５で参照先ＡＰに「Ｎｏｎｅ」が設定されていることが分かるので、送信ＢＯの属性「配達日」には何も設定しない。そして、ステップ２２９で他に属性がないと判定されるので、ステップ２３０に進み、値が設定された送信ＢＯが送信される。その後、ステップ２３１で「Ａｐｐ−Ｚ」以外に送信先はないと判定されるので、処理は終了する。
【００６１】
(配送完了通知ビジネスプロセス)
図１１を参照しながら、配送完了通知ビジネスプロセスについて説明する。尚、各注文ＢＯの属性に設定される値の後の「()」は、その値がどのアプリケーションから得られたものであるかを示している。
配送完了通知ビジネスプロセスの実行に先立ち、図１１に示すような参照定義(注文ＢＯ参照定義)が生成されている。この参照定義を生成する動作を、図６の流れに沿って説明する。
まず、ステップ２０１で配送完了通知ビジネスプロセス定義が選択され、ステップ２０２で送信先ＡＰとして「Ａｐｐ−Ｘ」が選択される。
ステップ２０３で送信先ＡＰ「Ａｐｐ−Ｘ」のＩ/Ｆ定義である「Ｘ−注文ＢＯＩ/Ｆ定義」に定義される属性「注文番号(KEY)」に着目する。ステップ２０４で「注文番号(KEY)」はキー項目であると判定されるので、ステップ２０８に進み、図１１の「注文ＢＯ参照定義」に参照先ＡＰとして、送信元ＡＰである「Ａｐｐ−Ｚ」が設定される。そして、ステップ２１１で他に属性があると判定されるので、ステップ２０３に戻る。
【００６２】
次に、ステップ２０３で送信先ＡＰ「Ａｐｐ−Ｘ」のＩ/Ｆ定義である「Ｘ−注文ＢＯＩ/Ｆ定義」に定義される次の属性「製品番号」に着目する。ステップ２０４で「製品番号」はキー項目でないと判定されるので、ステップ２０５に進む。また、送信先ＡＰ「Ａｐｐ−Ｘ」のＩ/Ｆ定義で(所有、変更)が(Ｙ、Ｙ)であるので、ステップ２１０に進み、図１１の「注文ＢＯ参照定義」に参照先ＡＰとして、「Ｎｏｎｅ」が設定される。尚、「Ｎｏｎｅ」とは、その属性の値として送信先ＡＰにおける値を設定するので、転送する際には値を設定しないことを示すものである。そして、ステップ２１１で他に属性があると判定されるので、ステップ２０３に戻る。
【００６３】
その後、送信先ＡＰ「Ａｐｐ−Ｘ」のＩ/Ｆ定義である「Ｘ−注文ＢＯＩ/Ｆ定義」に定義される次の属性「個数」に着目し、同様の処理を行い、図１１の「注文ＢＯ参照定義」に参照先ＡＰとして、「Ｎｏｎｅ」が設定される。また、属性「納期」、「顧客名」、「配達先住所」、「連絡先」についても同様に「Ｎｏｎｅ」が設定される。そして、ステップ２１１で他に属性があると判定されるので、ステップ２０３に戻る。
【００６４】
次に、ステップ２０３で送信先ＡＰ「Ａｐｐ−Ｘ」のＩ/Ｆ定義である「Ｘ−注文ＢＯＩ/Ｆ定義」に定義される次の属性「工場出荷予定日」に着目する。ステップ２０４で「工場出荷予定日」はキー項目でないと判定されるので、ステップ２０５に進む。また、送信先ＡＰ「Ａｐｐ−Ｘ」のＩ/Ｆ定義で(所有、変更)が(Ｙ、Ｙ)ではないので、ステップ２０６に進む。更に、属性「工場出荷予定日」が送信元ＡＰ「Ａｐｐ−Ｚ」のＩ/Ｆ定義に存在しているので、ステップ２０７に進む。更にまた、送信元ＡＰ「Ａｐｐ−Ｚ」のＩ/Ｆ定義で(所有、変更)が(Ｙ、Ｙ)ではないので、ステップ２０９に進む。本具体例では、かかる場合、送信元ＡＰを参照先ＡＰとすることとし、図１１の「注文ＢＯ参照定義」に参照先ＡＰとして、送信元ＡＰである「Ａｐｐ−Ｚ」が設定される。そして、ステップ２１１で他に属性があると判定されるので、ステップ２０３に戻る。
【００６５】
次に、ステップ２０３で送信先ＡＰ「Ａｐｐ−Ｘ」のＩ/Ｆ定義である「Ｘ−注文ＢＯＩ/Ｆ定義」に定義される次の属性「配達日」に着目する。ステップ２０４で「配達日」はキー項目でないと判定されるので、ステップ２０５に進む。また、送信先ＡＰ「Ａｐｐ−Ｘ」のＩ/Ｆ定義で(所有、変更)が(Ｙ、Ｙ)ではないので、ステップ２０６に進む。更に、属性「配達日」が送信元ＡＰ「Ａｐｐ−Ｚ」のＩ/Ｆ定義に存在しているので、ステップ２０７に進む。更にまた、送信元ＡＰ「Ａｐｐ−Ｚ」のＩ/Ｆ定義で(所有、変更)が(Ｙ、Ｙ)であるので、ステップ２０８に進み、図１１の「注文ＢＯ参照定義」に参照先ＡＰとして、送信元ＡＰである「Ａｐｐ−Ｚ」が設定される。
【００６６】
また、図１１に示す注文ＢＯ参照定義が生成された後、「Ａｐｐ−Ｚ」から注文ＢＯを受信した統合サーバ２０の動作を、図７の流れに沿って説明する。
まず、ステップ２２１で「Ａｐｐ−Ｚ」から注文ＢＯを受信し、ステップ２２２でビジネスプロセス定義として「『Ａｐｐ−Ｘ』に転送する」を取得する。
次に、ステップ２２３で送信先ＡＰ「Ａｐｐ−Ｘ」に着目し、ステップ２２４で図１１の「注文ＢＯ参照定義」に定義された属性「注文番号(KEY)」に着目する。ステップ２２５で参照先ＡＰが送信元ＡＰ「Ａｐｐ−Ｚ」と判定されるので、受信ＢＯの属性「注文番号(KEY)」に設定された値を送信ＢＯの属性「注文番号(KEY)」に設定する。そして、ステップ２２９で他に属性があると判定されるので、ステップ２２４に戻る。
【００６７】
次に、ステップ２２４で図１１の「注文ＢＯ参照定義」に定義された次の属性「製品番号」に着目する。ステップ２２５で参照先ＡＰに「Ｎｏｎｅ」が設定されていることが分かるので、送信ＢＯの属性「製品番号」には何も設定しない。また、属性「個数」、「納期」、「顧客名」、「配達先住所」、「連絡先」についても同様に「Ｎｏｎｅ」を設定する。そして、ステップ２２９で他に属性があると判定されるので、ステップ２２４に戻る。
【００６８】
次に、ステップ２２４で図１１の「注文ＢＯ参照定義」に定義された次の属性「工場出荷予定日」に着目する。ステップ２２５で参照先ＡＰが送信元ＡＰ「Ａｐｐ−Ｚ」と判定されるので、受信ＢＯの属性「工場出荷予定日」に設定された値を送信ＢＯの属性「工場出荷予定日」に設定する。また、属性「配達日」についても同様に受信ＢＯの属性「配達日」に設定された値を送信ＢＯの同じ属性に設定する。そして、ステップ２２９で他に属性がないと判定されるので、ステップ２３０に進み、値が設定された送信ＢＯが送信される。その後、ステップ２３１で「Ａｐｐ−Ｘ」以外に送信先はないと判定されるので、処理は終了する。
【００６９】
以上述べたように、本実施の形態では、ビジネスオブジェクトの属性ごとにその属性の参照先ＡＰを統合サーバに定義しておき、統合サーバがビジネスオブジェクトを転送する際に、参照先ＡＰから取得した値を属性に設定するようにした。このように構成したことにより、ビジネスプロセスの上流工程に出て来ないアプリケーションの保持する属性であっても、下流工程のアプリケーションで参照することが可能となる。
【００７０】
尚、本実施の形態では、ビジネスオブジェクトの転送に着目して説明してきたが、より一般的なデータの転送として本発明を捉えることも可能である。その場合、ビジネスオブジェクトの属性は、データレコードにおけるデータ項目として把握することが可能である。
また、本実施の形態では、統合サーバ２０上に共通ビジネスオブジェクトを設けない形態について述べたが、統合サーバ２０上に共通ビジネスオブジェクトを設ける構成としても構わない。
【図面の簡単な説明】
【００７１】
【図１】本発明の実施の形態が適用されるシステムの全体構成を示した図である。
【図２】本発明の実施の形態における統合サーバのハードウェア構成を示したブロック図である。
【図３】本発明の実施の形態における統合サーバの機能構成を示したブロック図である。
【図４】本発明の実施の形態におけるビジネスプロセス定義記憶部の記憶内容の一例を示した図である。
【図５】本発明の実施の形態における参照定義記憶部及びＩ/Ｆ定義記憶部の記憶内容の一例、及び、システムの動作概略を示した図である。
【図６】本発明の実施の形態における参照定義の自動生成の動作を示したフローチャートである。
【図７】本発明の実施の形態におけるビジネスオブジェクトの転送の動作を示したフローチャートである。
【図８】本発明の実施の形態の具体的な動作を説明するためのＩ/Ｆ定義の例を示した図である。
【図９】本発明の実施の形態の具体的な動作のうち生産指示ビジネスプロセスを説明するための図である。
【図１０】本発明の実施の形態の具体的な動作のうち配送指示ビジネスプロセスを説明するための図である。
【図１１】本発明の実施の形態の具体的な動作のうち配送完了通知ビジネスプロセスを説明するための図である。
【符号の説明】
【００７２】
１０ａ〜１０ｄ…コンピュータシステム、１１ａ〜１１ｄ…ＡＰ、２０…統合サーバ、２１…ＢＯ受信部、２２…ビジネスプロセス定義記憶部、２３…ビジネスプロセス定義取得部、２４…参照定義記憶部、２５…属性設定部、２６…ＢＯ送信部、２７…Ｉ/Ｆ定義記憶部、２８…参照定義生成部
【図１】
2006184941.tif 000003
【図２】
2006184941.tif 000004
【図３】
2006184941.tif 000005
【図４】
2006184941.tif 000006
【図５】
2006184941.tif 000007
【図６】
2006184941.tif 000008
【図７】
2006184941.tif 000009
【図８】
2006184941.tif 000010
【図９】
2006184941.tif 000011
【図１０】
2006184941.tif 000012
【図１１】
2006184941.tif 000013