(57)【要約】【課題】  複数の業務システムを連携させるために使用されるデータ連携ルールの作成にかかる工数及び期間を大幅に軽減し、迅速に業務システム間のデータ連携を行うシステムを導入する。【解決手段】  データ連携ルール生成システム１０は、モデル化した各業務で使用される概念的なデータの連携を示す情報を含む業務モデル定義情報、及び、モデル化した業務で使用される概念的なデータと、モデル化した業務の処理を行う業務システム４０ａ〜ｎで使用されるデータとの対応付けを示すシステム物理仕様マッピング定義情報を基に、業務システム４０ａ〜ｎ間で連携されるデータの対応付けを示すシステム連携ルール定義情報を生成する。データ・コントロール・システム５０は、生成されたシステム連携ルール定義情報を用いて業務システム４０ａ〜ｎのデータを連携させる。【選択図】    図１
2005063261.tif 000002
【特許請求の範囲】
【請求項１】
複数の業務システム間のデータを連携させるために使用されるデータ連携ルールを定義した情報を生成するデータ連携ルール生成システムであって、
モデル化した各業務で使用される概念的なデータの連携を示す概念データ間マッピング情報、及び、モデル化した業務で使用される概念的なデータと、モデル化した前記業務の処理を行う業務システムで使用されるデータとの対応付けを示すシステム物理仕様マッピング定義情報を記憶する記憶手段と、
前記記憶手段内の概念データ間マッピング情報及びシステム物理仕様マッピング定義情報を基に、業務システム間で連携されるデータの対応付けを示すシステム連携ルール定義情報を生成するシステム連携ルール定義情報生成部と、
を備えることを特徴とするデータ連携ルール生成システム。
【請求項２】
前記概念データ間マッピング情報は、さらに、概念的なデータの連携方法の情報を含み、
前記システム連携ルール定義情報生成部は、業務システムで使用されるデータの連携方法の情報をさらに含んだシステム連携ルール定義情報を生成する、
ことを特徴とする請求項１に記載のデータ連携ルール生成システム。
【請求項３】
前記連携の方法は、無条件の同期更新、または、所定の条件下での同期更新であることを特徴とする請求項２に記載のデータ連携ルール生成システム。
【請求項４】
前記所定の条件は、所定のタイミング、連携元のデータを用いた演算、及び、同一の連携元のデータを複数の連携先のデータと連携させる共有のうち何れかまたは複数の組み合わせであることを特徴とする請求項３に記載のデータ連携ルール生成システム。
【請求項５】
複数の業務システム間のデータを連携させるために使用されるデータ連携ルールを定義した情報を生成するデータ連携ルール生成方法であって、
モデル化した各業務で使用される概念的なデータの連携を示す概念データ間マッピング情報、及び、モデル化した業務で使用される概念的なデータと、モデル化した前記業務の処理を行う業務システムで使用されるデータとの対応付けを示すシステム物理仕様マッピング定義情報を記憶する記憶手段を用意し、
前記記憶手段内の概念データ間マッピング情報及びシステム物理仕様マッピング定義情報を基に、業務システム間で連携されるデータの対応付けを示すシステム連携ルール定義情報を生成する、
ことを特徴とするデータ連携ルール生成方法。
【請求項６】
複数の業務システム間のデータを連携させるために使用されるデータ連携ルールを定義した情報を生成するデータ連携ルール生成システムに用いられるコンピュータプログラムであって、
記憶手段内に記憶されたモデル化した各業務で使用される概念的なデータの連携を示す概念データ間マッピング情報、及び、モデル化した業務で使用される概念的なデータと、モデル化した前記業務の処理を行う業務システムで使用されるデータとの対応付けを示すシステム物理仕様マッピング定義情報とを読み出すステップと、
読み出した概念データ間マッピング情報及びシステム物理仕様マッピング定義情報とを基に、業務システム間で連携されるデータの対応付けを示すシステム連携ルール定義情報を生成するステップと、
をコンピュータに実行させることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の業務システム間のデータを連携させるために使用される情報を生成するデータ連携ルール生成システム及び方法、ならびに、コンピュータプログラムに関する。
【背景技術】
【０００２】
従来、企業において活用されている社内外情報システムなどの業務システムは、業務単位に設定されている事が多い。これらの業務システムは個別に開発され、それぞれが業務に付随するデータを登録・保有する。しかし、一連の業務の流れの中で、同一のデータを異なる業務で重複登録する事による非効率が発生し、同時にその実際のデータの値が業務システム間で異なってしまうという品質の劣化をまねく。そのため、異なる業務システム間において、一度登録したデータを他業務システムが再利用することによりこの問題を解決する試みがなされている。これらはデータ連携（統合）と称される。
【０００３】
一方、特許文献１には、アプリケーションの付け替えが容易になるよう、ビジネスプロセス定義とアプリケーション間データ連携定義を分割し、ワークフロー関連データのみをワークフロー管理システムへ通知するシステム連携定義方法等について開示されている。
【特許文献１】特開２００２−１３２５０３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述する業務システム間のデータ連携を行うためのシステムを開発する場合、概ね以下の方式を採用している。
（１）  既存業務の流れ、データの流れをあるがままに物理モデルとして定義し、物理的にどう連携するのかその方向を検討する。
（２）  保有している全ての業務システムを分析し、その仕様を把握する。
（３）  （２）の結果に基づき連携が発生する業務システム間において、どのデータ（単一または複数データ）が授受されるかを洗い出す。また業務システム間においてどのような変換が必要となるかを分析する。
（４）  （１）から（３）の結果を業務システム間データ連携の仕様としてまとめる。
（５）  （４）の結果を、ＥＡＩやＥＴＬ（Extract Transform load）ツールに登録する。ＥＡＩとは、複数の業務システムを有機的に連携させ、データやプロセスの効率的な統合を図るアーキテクチャである。また、ＥＴＬとは、基幹系業務システムなどのデータソースからデータを抽出、変換し、データウェアハウスなどのターゲットシステムにロードするアーキテクチャである。
（６）  （５）の結果、ＥＡＩまたはＥＴＬが、業務システム間でのデータ送受信を実行する。
【０００５】
このような開発方式によれば、データを連携させる対象となる業務システムが複数存在する場合、ＥＡＩやＥＴＬの開発工数の大部分を占める分析／設計／設定の連携定義工数が膨大となり、リードタイムが長くなるという問題がある。具体的には、ｎ個の業務システムの連携を実現する場合、上述する（２）の個々の業務システムの分析に関しては、保有業務システム数分の工数が発生する。また、（３）の業務システム間のデータ連携関係の把握、（４）の業務システム間のデータ連携仕様の作成、及び、（５）の業務システム間のデータ連携仕様登録のそれぞれについては、全ての業務システム間についてメッシュ状に行う必要があり、最大で、「業務システム数×（業務システム数−１）／２」の工数が発生する。また、ｎ個の連携済み既存業務システムに新たにｍ個の業務システムを追加する場合は、（３）〜（５）に対して、[ｍ×ｎ＋（ｍ×（ｍ−１））／２]通りの連携定義が必要となる。
しかし、特許文献１は、上述する工程及び工数を大幅に軽減するものではない。
【０００６】
この発明は、このような事情を考慮してなされたもので、その目的は、複数の業務システムを連携させるために使用されるデータ連携ルールの作成にかかる工数及び期間を大幅に軽減し、迅速に業務システム間のデータ連携を行うためのシステムを導入することができるデータ連携ルール生成システム及び方法等を提供することにある。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、請求項１に記載の発明は、複数の業務システム間のデータを連携させるために使用されるデータ連携ルールを定義した情報を生成するデータ連携ルール生成システムであって、モデル化した各業務で使用される概念的なデータの連携を示す概念データ間マッピング情報、及び、モデル化した業務で使用される概念的なデータと、モデル化した前記業務の処理を行う業務システムで使用されるデータとの対応付けを示すシステム物理仕様マッピング定義情報を記憶する記憶手段と、前記記憶手段内の概念データ間マッピング情報及びシステム物理仕様マッピング定義情報を基に、業務システム間で連携されるデータの対応付けを示すシステム連携ルール定義情報を生成するシステム連携ルール定義情報生成部と、を備えることを特徴とするデータ連携ルール生成システムである。
【０００８】
請求項２に記載の発明は、請求項１に記載のデータ連携ルール生成システムであって、前記概念データ間マッピング情報は、さらに、概念的なデータの連携方法の情報を含み、前記システム連携ルール定義情報生成部は、業務システムで使用されるデータの連携方法の情報をさらに含んだシステム連携ルール定義情報を生成する、ことを特徴とする。
【０００９】
請求項３に記載の発明は、請求項２に記載のデータ連携ルール生成システムであって、前記連携の方法は、無条件の同期更新、または、所定の条件下での同期更新であることを特徴とする。
【００１０】
請求項４に記載の発明は、請求項３に記載のデータ連携ルール生成システムであって、前記所定の条件は、所定のタイミング、連携元のデータを用いた演算、及び、同一の連携元のデータを複数の連携先のデータと連携させる共有のうち何れかまたは複数の組み合わせであることを特徴とする。
【００１１】
請求項５に記載の発明は、複数の業務システム間のデータを連携させるために使用されるデータ連携ルールを定義した情報を生成するデータ連携ルール生成方法であって、モデル化した各業務で使用される概念的なデータの連携を示す概念データ間マッピング情報、及び、モデル化した業務で使用される概念的なデータと、モデル化した前記業務の処理を行う業務システムで使用されるデータとの対応付けを示すシステム物理仕様マッピング定義情報を記憶する記憶手段を用意し、前記記憶手段内の概念データ間マッピング情報及びシステム物理仕様マッピング定義情報を基に、業務システム間で連携されるデータの対応付けを示すシステム連携ルール定義情報を生成する、ことを特徴とするデータ連携ルール生成方法である。
【００１２】
請求項６に記載の発明は、複数の業務システム間のデータを連携させるために使用されるデータ連携ルールを定義した情報を生成するデータ連携ルール生成システムに用いられるコンピュータプログラムであって、記憶手段内に記憶されたモデル化した各業務で使用される概念的なデータの連携を示す概念データ間マッピング情報、及び、モデル化した業務で使用される概念的なデータと、モデル化した前記業務の処理を行う業務システムで使用されるデータとの対応付けを示すシステム物理仕様マッピング定義情報とを読み出すステップと、読み出した概念データ間マッピング情報及びシステム物理仕様マッピング定義情報とを基に、業務システム間で連携されるデータの対応付けを示すシステム連携ルール定義情報を生成するステップと、をコンピュータに実行させることを特徴とするコンピュータプログラムである。
【発明の効果】
【００１３】
上記発明によれば、従来方式と比べ複数の業務システムを連携させるために使用されるデータ連携ルールの定義にかかわる工程及び工数を大幅に軽減し、迅速に業務システム間のデータ連携を行うためのシステムを導入することができる。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照し、この発明の実施の形態について説明する。
図１は、この発明の一実施の形態によるデータ連携ルール生成システムの機能概要を説明するための図である。
業務システム４０ａ〜４０ｎは、各種業務処理を実行するシステムであり、ここでは、これらの業務システム４０ａ〜４０ｎ（以下、「業務システム４０」と記載）のデータを連携させることを想定する。
【００１５】
まず、システム開発担当者は、業務モデル定義情報、システム物理仕様定義情報、及び、システム物理仕様マッピング定義情報を用意する。業務モデル定義情報は、一連の業務の流れを概念的にモデル化したときに、このモデル化した業務において使用される概念データ間の連携を定義する。また、システム物理仕様定義情報は、実際の業務システム４０が使用するデータやプロトコルを定義する。システム物理仕様マッピング定義情報は、モデル化した業務で使用される概念データと実際の業務システム４０で使用されるデータとのマッピングを定義する。
【００１６】
次に、データ連携ルール生成システム１０は、業務モデル定義情報、システム物理仕様定義情報、及び、システム物理仕様マッピング定義情報から、データ・コントロール・システム５０が、業務システム４０間のデータ連携処理を実行するために使用するシステム連携ルール定義情報、プロトコル定義情報、及び、データ変換ルール定義情報を生成する。システム連携ルール定義情報は、業務システム４０間のデータの連携ルールを定義する。システム連携ルール定義情報は、各業務システム４０が利用しているプロトコルとデータ・コントロール・システム５０の内部プロトコルの変換ルールを定義する。また、データ変換ルール定義情報は、業務システム４０で用いられるデータ表現形式（データ属性）をデータ・コントロール・システム５０の内部で用いられるデータ表現形式（内部表現形式）と変換するためのルールを定義する。
データ・コントロール・システム５０は、データ連携ルール生成システム１０が生成したシステム連携ルール定義情報、プロトコル定義情報、及び、データ変換ルール定義情報を参照して、業務システム４０間のデータ連携処理を実行する。
【００１７】
図２は、システム連携ルール定義情報の生成手順の概要を示す図である。
まず、システム開発担当者は、概念的に業務の関連（流れ）をモデル化し、さらに、これらのモデル化した業務で使用する概念データであるメタデータの項目リストを定義する。そして、モデル化した業務の流れに従って、モデル化した業務間において使用されるメタデータ同士の連携を示すメタデータ項目間マッピング情報（概念データ間マッピング情報）を作成する（ステップＳ１）。ここでは、業務の流れの一部に、「業務Ｍ１」から「業務Ｍ２」へのデータ連携が含まれていたとする。
【００１８】
次に、システム開発担当者は、実際の業務システム４０をモデル化し、実際の各業務システム４０が使用するデータ項目を抽出し、定義する（ステップＳ２）。さらに、システム開発担当者は、モデル化した業務と、実際の業務システム４０とを対応付ける。ここでは、業務Ｍ１と業務システム４０ｉが、業務Ｍ２と業務システム４０ｊが対応付けられるとする。システム開発担当者は、業務Ｍ１のメタデータ項目と業務システム４０ｉのデータ項目とをマッピングしたシステム物理仕様マッピング定義情報及び業務Ｍ２のメタデータ項目と業務システム４０ｊのデータ項目とをマッピングしたシステム物理仕様マッピング定義情報を定義する（ステップＳ３）。
【００１９】
続いて、データ連携ルール生成システム１０は、ステップＳ１で定義したメタデータ項目間マッピング情報と、ステップＳ３で定義したシステム物理仕様マッピング定義情報とを参照し、システム連携ルール定義情報を生成する（ステップＳ４）。そして、データ・コントロール・システム５０において、この生成されたシステム連携ルール定義情報を用いて、業務システム４０ｉから業務システム４０ｊのデータ連携を実行する（ステップＳ５）。
【００２０】
次に、各システムの構成について説明する。
図３は、データ連携ルール生成システム１０の内部構成を機能展開して示したブロック図であり、本発明と関係する機能ブロックのみ抽出して示してある。データ連携ルール生成システム１０は、例えば、１つまたは複数のサーバなどで構成することができる。
業務モデル定義情報記憶部１１は、業務モデル定義情報を記憶する。業務モデル定義情報は、連携対象の業務の関連（流れ）をモデル化した情報、これらのモデル化された各業務において使用されるメタデータ（概念データ）の項目のリスト、及び、メタデータ項目間マッピング情報からなる。メタデータ項目間マッピング情報は、モデル化された業務の流れに対応して連携させるべき連携元及び連携先のメタデータのマッピング情報と、連携の種別及び条件を示す連携方式情報とからなる。
システム物理仕様定義情報記憶部１２は、システム物理仕様定義情報を記憶する。システム物理仕様定義情報は、各業務システム４０が使用するデータ項目のリスト、これらのデータ項目で示されるデータの属性を示すデータ構造情報、ならびに、各業務システム４０が使用する通信プロトコル及び内部コードを示すシステム属性情報からなる。
システム物理仕様マッピング定義情報記憶部１３は、モデル化した業務で使用される概念データを示すメタデータ項目と、実際の業務システム４０で使用されるデータ項目とのマッピングを定義するシステム物理仕様マッピング定義情報を記憶する。
【００２１】
システム連携ルール定義情報記憶部３１は、システム連携ルール定義情報を記憶する。システム連携ルール定義情報は、連携元の業務システム４０と連携先の業務システム４０と間で連携すべきデータのマッピングの情報と、連携の種別及び条件を示す連携方式情報とからなる。
プロトコル定義情報記憶部３２は、プロトコル定義情報を記憶する。
データ変換ルール定義情報記憶部３３は、データ変換ルール定義情報を記憶する。
【００２２】
システム連携ルール定義情報生成部２２は、業務モデル定義情報記憶部１１内のメタデータ項目間マッピング情報と、システム物理仕様マッピング定義情報記憶部１３内のシステム物理仕様マッピング定義情報とから、システム連携ルール定義情報を生成し、システム連携ルール定義情報記憶部３１へ書き込む。
プロトコル定義情報生成部２４は、システム物理仕様定義情報記憶部１２内の各業務システム４０のシステム属性情報を基にプロトコル定義情報を生成し、プロトコル定義情報記憶部３２へ書き込む。
データ変換ルール定義情報生成部２５は、システム物理仕様定義情報記憶部１２内の各業務システム４０のシステム属性情報及びデータ構造情報から、データ変換ルール定義情報を生成し、データ変換ルール定義情報記憶部３３へ書き込む。
【００２３】
リポジトリインタフェース部２１は、システム連携ルール定義情報生成部２２、プロトコル定義情報生成部２４、及び、データ変換ルール定義情報生成部２５が、業務モデル定義情報記憶部１１、システム物理仕様定義情報記憶部１２、あるいは、システム物理仕様マッピング定義情報記憶部１３へアクセスするためのインタフェースを提供する。
データ・コントロール・インタフェース部２３は、システム連携ルール定義情報生成部２２、プロトコル定義情報生成部２４、及び、データ変換ルール定義情報生成部２５が、システム連携ルール定義情報記憶部３１、プロトコル定義情報記憶部３２あるいはデータ変換ルール定義情報記憶部３３へアクセスするためのインタフェースを提供する。
【００２４】
なお、業務モデル定義情報記憶部１１、システム物理仕様定義情報記憶部１２、システム物理仕様マッピング定義情報記憶部１３、システム連携ルール定義情報記憶部３１、プロトコル定義情報記憶部３２またはデータ変換ルール定義情報記憶部３３は、データ連携ルール生成システム１０の内部に備えてもよいし、ＬＡＮ（Local Area Network）やＶＰＮ（virtual private network）などのネットワークを介して接続されるデータベースサーバなどの外部の装置であってもよい。また、システム連携ルール定義情報記憶部３１、プロトコル定義情報記憶部３２またはデータ変換ルール定義情報記憶部３３を、データ・コントロール・システム５０の内部に備える構成とすることもできる。
【００２５】
図４は、データ・コントロール・システム５０の内部構成を機能展開して示したブロック図であり、本発明と関係する機能ブロックのみ抽出して示してある。データ・コントロール・システム５０は、既存のＥＡＩ（Enterprise Application Integration）またはＥＴＬ（Extract Transform load）であり、業務システム４０とネットワークを介して接続される。データ・コントロール・システム５０は、プロトコルアダプタ５１、送受信部５２、データ変換部５３、コミュニケーション・バス５４及びＢＰＭ（Business Process Manager：ビジネスプロセスマネージャ）５５からなる。
【００２６】
プロトコルアダプタ５１は、プロトコル定義情報記憶部３２内のプロトコル定義情報を参照して業務システム４０のメッセージで使用するプロトコルと内部プロトコルとを変換し、業務システム４０との間のメッセージの送受信を行う。
送受信部５２は、プロトコルアダプタ５１を介して受信した業務システム４０からのメッセージをデータ変換部５３へ受け渡すとともに、データ変換部５３から送信を指示されたメッセージをプロトコルアダプタ５１へ受け渡す。
データ変換部５３は、データ変換ルール定義情報記憶部３３内のデータ変換ルール定義情報を参照し、業務システム４０が使用するデータの表現形式（データ属性）と、内部で使用するデータ表現形式（内部表現形式）との変換を行う。
コミュニケーション・バス５４は、データ変換部５３から内部表現形式を用いたデータを含むメッセージを受信するとともに、連携先の業務システム４０への送信メッセージ内に設定すべき連携データをデータ変換部５３へ受け渡す。
ＢＰＭ５５は、システム連携ルール定義情報記憶部３１内のシステム連携ルール定義情報を参照し、メッセージの宛先（連携先）の業務システム４０を決定するとともに、この受信メッセージ内のデータを、連携先の業務システム４０において用いられるデータへと変換する。
【００２７】
業務システム４０は、例えば、それぞれ受注、在庫管理、決済などの各種業務処理を実行するシステムやパッケージであり、ＬＡＮやＶＰＮなどのネットワークを介してデータ・コントロール・システム５０と接続される。業務システム４０は、業務処理を実行した結果、業務データの更新が発生した場合には、他の業務システム４０と連携すべきデータをデータ・コントロール・システム５０へ送信する。また、データ・コントロール・システム５０から他の業務システム４０と連携すべきデータを受信して、内部の業務データを更新する。
【００２８】
次に、システム連携ルール定義情報の詳細な生成手順について説明する。
図５は、データ連携対象の業務の関連（流れ）をモデル化した例を示す。図においては、「受注」から「出荷指示」及び「決済」へ、そして、「出荷指示」からは「出荷」、「在庫管理」へと一連の業務の流れがモデル化されたことを示している。さらに、システム開発担当者は、モデル化された各業務と、実際の業務システム４０とを対応づけていく。図においては、「受注」としてモデル化された業務（以下、「受注モデル」）は、業務システム４０ａと対応付けられる。また、「出荷指示」及び「出荷」としてモデル化された業務（以下、それぞれ「出荷指示モデル」、「出荷モデル」）は、業務システム４０ｂと対応付けられる。同様に、「在庫管理モデル」は、業務システム４０ｎと、「決済モデル」は、業務システム４０ｃと対応付けられる。システム開発担当者は、連携対象の業務の関連をモデル化し、業務システム４０と対応付けた情報を業務モデル定義情報記憶部１１へ登録する。
【００２９】
図６及び図７は、メタデータ項目間マッピング情報の設定例を示す。
システム開発担当者は、モデル化された各業務で使用されるメタデータ項目のリストを定義し、さらに、業務の流れに応じて連携させるべきメタデータ項目を定義したメタデータ項目間マッピング情報を定義して、業務モデル定義情報記憶部１１へ登録する。
メタデータ項目間マッピング情報には、連携方式（連携の種別及び条件）も定義される。連携種別には、「共有」と「継承」の２種類がある。「共有」とは、データが常に無条件で連動して同期更新されるべきであることを示す。また、「継承」とは、ある条件の下で連携して更新されるべきであることを示す。この条件の種類を以下に示すが、これらの組み合わせでもよい。
（１）タイミング：業務完了の待ち合わせ、時刻等
（２）演算：連携元のデータと他のデータまたは常数との数値演算、論理演算など
（３）分割（継承の分岐）：連携元のデータを複数の連携先データへ継承
上記のように、継承の対象となるデータの対応関係は1対1の場合もあれば1対多、多対1となる場合もあり、一般的にはｍ対ｎの関係にある。なお、（３）の分割（継承の分岐）については、同じまたは異なるメタデータ項目間マッピング情報において、同一のメタデータ項目が連携元として定義されるのみであり、メタデータ項目間マッピング情報内の連携の種類及び条件には明確に定義されない。
【００３０】
図６は、連携元「受注モデル」と連携先「出荷指示モデル」のメタデータ項目間マッピング情報を示している。同図において、「受注モデル」で使用されるメタデータ項目は、「受注Ｎｏ」、「顧客番号」、「受注年月日」、「受注商品番号」、「受注商品数量」、及び、「納期」である。また、「出荷指示モデル」で使用されるメタデータ項目は、「出荷指示Ｎｏ」、「出荷予定日」、「受注Ｎｏ」、「顧客番号」、「受注年月日」、「出荷指示商品番号」、「出荷指示商品数量」、「商品在庫数量」、「納期」である。
これらのメタデータ項目の連携を定義したメタデータ項目間マッピング情報では、連携元「受注モデル」の「受注Ｎｏ」、「受注年月日」、「受注商品番号」、「納期」はそれぞれ、連携先「出荷指示モデル」の「受注Ｎｏ」、「受注年月日」、「出荷指示商品番号」、「納期」と連携し、連携の種別は全て「継承」、連携の条件は「ＸＸ処理完了時」、「ＺＺＺ処理時」、「受注確定時」、「在庫確認後」（タイミング）であることを示している。また、「受注モデル」の「顧客番号」は、「出荷指示モデル」の「顧客番号」と連携し、連携の種別は「共有」であることを示している。さらに、「受注モデル」の「受注商品数量」は、「出荷指示モデル」の「出荷指示商品数量」及び「商品在庫数量」と連携し（継承の分岐）、連携の種別は両者とも「継承」であるが、連携の条件はそれぞれ、「数量確定時（タイミング）」、「商品在庫数量−受注商品情報（演算）」であることを示している。
【００３１】
図７は、連携元「受注モデル」と連携先「決済モデル」のメタデータ項目間マッピング情報を示している。同図において、「受注モデル」で使用されるメタデータ項目は図６と同様である。また、「決済モデル」で使用されるメタデータ項目は、「取引Ｎｏ」、「出荷日」、「決済期限」、「顧客番号」、「受注年月日」、「取引商品番号」、「取引商品数量」、「取引商品単価」、「決済方法」である。
これらのメタデータ項目の連携を定義したメタデータ項目間マッピング情報では、連携元「受注モデル」の「受注Ｎｏ」、「受注年月日」、「受注商品番号」、「受注商品数量」、「納期」はそれぞれ、連携先「決済モデル」の「取引Ｎｏ」、「受注年月日」、「取引商品番号」、「取引商品数量」、「決済期限」と連携し、連携の種別は全て「継承」、連携の条件は「ＸＸ処理完了時（タイミング）」、「ＸＹ時（タイミング）」、「受注確定時（タイミング）」、「ＹＹ−受注商品数量（演算）」、「ＺＸ後（タイミング）」であることを示している。また、「受注モデル」の「顧客番号」は、「決済モデル」の「顧客番号」と連携し、連携の種別は「共有」であることを示している。
図６及び図７において、「受注モデル」の「受注Ｎｏ」、「顧客番号」、「受注年月日」、「受注商品番号」、「受注商品数量」、「納期」は、「出荷指示モデル」及び「決済モデル」のメタデータ項目と連携されており、すなわち、分割（継承の分岐）が行われていることを示す。
【００３２】
図８から図１０は、システム物理仕様マッピング定義情報の設定例を示す。
システム開発担当者は、実際の各業務システム４０で使用されるデータ項目を抽出し、リストを定義する。さらに、システム開発担当者は、このデータ項目のリストと、対応するモデル化された業務のメタデータ項目とをマッピングして、システム物理仕様マッピング定義情報を定義し、システム物理仕様定義情報記憶部１２へ登録する。
図８は、業務システム４０ａで使用されるデータ項目と図６に示される「受注モデル」のメタデータ項目との、図９は、業務システム４０ｂで使用されるデータ項目と図６に示される「出荷指示モデル」のメタデータ項目との、図１０は、業務システム４０ｃで使用されるデータ項目と図７に示される「決済モデル」のメタデータ項目とのマッピングを定義したシステム物理仕様マッピング定義情報を生成している。
【００３３】
図８においては、業務システム４０ａで使用されるデータ項目「受注Ｎｏ」、「顧客番号」、「受注年月日」、「商品番号」、「商品数量」、「希望納期」はそれぞれ、「受注モデル」のメタデータ項目「受注Ｎｏ」、「顧客番号」、「受注年月日」、「受注商品番号」、「受注商品数量」、「納期」とマッピングされることを示している。
【００３４】
図９においては、業務システム４０ｂで使用されるデータ項目「出荷指示番号」、「出荷番号」、「顧客番号」、「出荷予定日」、「商品コード」、「商品数量」、「在庫数量」、「指定納期」はそれぞれ、「出荷指示モデル」のメタデータ項目「出荷指示Ｎｏ」、「受注Ｎｏ」、「顧客番号」、「出荷予定日」、「出荷指示商品番号」、「出荷指示商品数量」、「商品在庫数量」、「納期」とマッピングされることを示している。
【００３５】
図１０においては、業務システム４０ｃで使用されるデータ項目「決済番号」、「出荷日」、「決済予定日」、「顧客番号」、「受注年月日」、「商品コード」、「商品数量」、「商品単価」、「決済方法」はそれぞれ、「決済モデル」のメタデータ項目「取引Ｎｏ」、「出荷日」、「決済期限」、「顧客番号」、「受注年月日」、「取引商品番号」、「取引商品数量」、「取引商品単価」、「決済方法」とマッピングされることを示している。
【００３６】
図１１は、データ連携ルール生成システム１０におけるシステム連携ルール定義情報生成フローを示す。
データ連携ルール生成システム１０のシステム連携ルール定義情報生成部２２は、データの連携元及び連携先となる業務システム４０を取得する（ステップＳ１１０）。これは、システム開発担当者が、図示しないキーボードやマウスなどの入力手段から入力して指定してもよいし、予め、データ連携ルール生成システム１０内部で規定されたものを使用してもよい。
【００３７】
システム連携ルール定義情報生成部２２は、連携元及び連携先となる業務システム４０を取得すると、リポジトリインタフェース部２１を介して、システム物理仕様マッピング定義情報記憶部１３から連携元及び連携先業務システム４０のシステム物理仕様マッピング定義情報を読み出す（ステップＳ１２０、ステップＳ１３０）。さらに、システム連携ルール定義情報生成部２２は、リポジトリインタフェース部２１を介して、業務モデル定義情報記憶部１１からこの連携元及び連携先業務システム４０に対応した業務モデルのメタデータ項目間マッピング情報を読み出す（ステップＳ１４０）。
【００３８】
システム連携ルール定義情報生成部２２は、内部で使用するシステム連携ルール定義情報テーブルの記憶領域を初期化すると（ステップＳ１５０）、連携元業務システム４０のシステム物理仕様マッピング定義情報から、１つめのデータ項目と、対応するメタデータ項目を取り出す（ステップＳ１６０）。そして、この取り出したメタデータ項目をキーにしてメタデータ項目間マッピング情報から、連携先業務システム４０に対応する業務モデルで使用されるメタデータ項目と、連携方式情報を取得する（ステップＳ１７０）。さらに、連携先業務システム４０のシステム物理仕様マッピング定義情報から、ステップＳ１７０で読み出したメタデータ項目に対応するデータ項目を取り出す（ステップＳ１８０）。システム連携ルール定義情報生成部２２は、システム連携ルール定義情報テーブルに、連携元・連携先のデータ項目、連携方式情報を格納する（ステップＳ１９０）。このとき、連携方式情報内の連携の条件に連携元の業務モデルで使用されるメタデータ項目が用いられている場合には、連携元業務システム４０で使用される対応するデータ項目へと変換する。
【００３９】
次に、システム連携ルール定義情報生成部２２は、連携元業務システム４０のシステム物理仕様マッピング定義情報内の全てのデータ項目について、システム連携ルール定義情報テーブルへの書込みが終了したかを判断する（ステップＳ２００）。全てのデータ項目について終了していなければ（ステップＳ２００：ＮＯ）、次のデータ項目について、ステップＳ１６０〜ステップＳ２００までの処理を繰り返す。
そして、全てのデータ項目について終了した場合には（ステップＳ２００：ＹＥＳ）、内部に記憶していたシステム連携ルール定義情報テーブルを、データ・コントロール・インタフェース部２３経由でシステム連携ルール定義情報記憶部３１に書き込む（ステップＳ２１０）。
なお、ステップＳ１８０において、連携先業務システム４０のシステム物理仕様マッピング定義情報にステップＳ１７０で読み出したメタデータ項目に対応するデータ項目が存在しなかった場合には、ステップＳ１９０の処理を行わずに、ステップＳ２００の処理を行う。
【００４０】
図１２及び図１３は、システム連携ルール定義情報の例を示す図である。
図１２は、業務システム４０ａ及び業務システム４０ｂ間のシステム連携ルール定義情報を、図１３は、業務システム４０ａ及び業務システム４０ｃ間のシステム連携ルール定義情報を示している。
図１２においては、業務システム４０ａ及び業務システム４０ｂ間のシステム連携ルール定義情報は、業務システム４０ａ及び４０ｂのシステム物理仕様マッピング定義情報と、業務システム４０ａ及び４０ｂそれぞれに対応した業務モデル「受注モデル」及び「出荷指示モデル」間のメタデータ項目間マッピング情報を参照して生成されることを示している。
同図において、連携元業務システム４０ａのデータ項目「受注Ｎｏ」、「商品番号」、「希望納期」それぞれは、連携先業務システム４０ｂのデータ項目「出荷番号」、「商品コード」、「指定納期」と連携され、これらの連携の種別は「継承」、連携の条件は「ＸＸ処理完了時」、「受注確定時」、「在庫確認後」（タイミング）であることを示している。また、業務システム４０ａのデータ項目「顧客番号」は、業務システム４０ｂのデータ項目「顧客番号」と連携され、連携の種別は「共有」であることを示している。また、業務システム４０ａのデータ項目「商品数量」は、業務システム４０ｂのデータ項目「商品数量」及び「在庫数量」と連携され、これらの連携の種別は「継承」、連携の条件はそれぞれ「数量確定時（タイミング）」、「在庫数量−商品数量（演算）」であることを示している。
【００４１】
図１３においては、業務システム４０ａ及び業務システム４０ｃ間のシステム連携ルール定義情報は、業務システム４０ａ及び４０ｃのシステム物理仕様マッピング定義情報と、業務システム４０ａ及び４０ｃそれぞれに対応した業務モデル「受注モデル」及び「決済モデル」間のメタデータ項目間マッピング情報を参照して生成されることを示している。
同図において、連携元業務システム４０ａのデータ項目「受注Ｎｏ」、「受注年月日」、「商品番号」、「商品数量」、「希望納期」それぞれは、連携先業務システム４０ｃのデータ項目「決済番号」、「受注年月日」、「商品コード」、「商品数量」、「決済予定日」と連携され、これらの連携の種別は「継承」、連携の条件は「ＸＸ処理完了時（タイミング）」、「ＸＹ時（タイミング）」、「受注確定時（タイミング）」、「ＹＹ−商品数量（演算）」、「ＺＸ後（タイミング）」であることを示している。また、業務システム４０ａのデータ項目「顧客番号」は、業務システム４０ｃのデータ項目「顧客番号」と連携され、連携の種別は「共有」であることを示している。
【００４２】
次に、プロトコル定義情報及びデータ変換ルール定義情報の生成手順について説明する。
図１４は、システム属性情報、データ構造情報、プロトコル定義情報、及び、データ変換ルール定義情報の設定例を示す図である。
同図において、業務システム４０ａのシステム属性情報は、業務システム４０ａが内部コードとして「ＥＵＣ」を、通信プロトコルとして「ＭＱ」を使用していることを示している。また、業務システム４０ａのデータ構造情報は、業務システム４０ａが使用する各データ項目「受注Ｎｏ」、「顧客番号」、…が、それぞれ、「１０進数、４バイト」、「英数文字列、１６桁」、…のデータ属性を持つことを示している。
同様に、業務システム４０ｂのシステム属性情報は、業務システム４０ｂが内部コードとして「Ｓｈｉｆｔ−ＪＩＳ」を、通信プロトコルとして「ＣＯＲＢＡ」を使用していることを示している。また、業務システム４０ｂのデータ構造情報は、業務システム４０ｂが使用する各データ項目「出荷番号」、「顧客番号」、…が、それぞれ、「２進数、４バイト」、「英数文字列、２０桁」、…のデータ属性を持つことを示している。
【００４３】
図１５は、データ連携ルール生成システム１０におけるプロトコル定義情報生成フローを示す。
データ連携ルール生成システム１０のプロトコル定義情報生成部２４は、プロトコル定義情報の生成対象となる業務システム４０を取得する（ステップＳ３１０）。これは、システム開発担当者が、図示しないキーボードやマウスなどの入力手段により指定してもよいし、予め、データ連携ルール生成システム１０内部で規定されたものであってもよい。
【００４４】
プロトコル定義情報生成部２４は、リポジトリインタフェース部２１を介して、対象業務システム４０のシステム属性情報を読み出す（ステップＳ３２０）。さらに、プロトコル定義情報生成部２４は、内部で使用するプロトコル定義情報テーブルの記憶領域を初期化する（ステップＳ３３０）。そして、対象業務システム４０のシステム属性情報内の通信プロトコル情報を読み出し、プロトコル定義情報テーブルへ書き込む（ステップＳ３４０）。このとき、データ・コントロール・システム５０内で使用される通信プロトコルと、読み出したプロトコルが異なる場合には、変換情報に「要」を設定し、同じ場合には、「否」を設定する。そして、全ての対象業務システム４０について、プロトコル定義情報テーブルへの書込みが終了したかを判断する（ステップＳ３５０）。全ての対象業務システム４０について終了していなければ、次の対象業務システム４０について、ステップＳ３４０及びステップＳ３５０の処理を繰り返す。
そして、全ての対象業務システム４０について終了した場合には、内部に記憶していたプロトコル定義情報テーブルを、データ・コントロール・インタフェース部２３経由でプロトコル定義情報記憶部３２に書き込む（ステップＳ３６０）。
【００４５】
図１４に示すプロトコル定義情報の設定例では、業務システム４０ａが使用するプロトコルは「ＭＱ」であり、変換は「要」、すなわち、データ・コントロール・システム５０内において変換が必要であること、業務システム４０ｂが使用するプロトコルは「ＣＯＲＢＡ」であり、変換は「否」、すなわち、データ・コントロール・システム５０内において変換が必要ないこと、…、を示している。
【００４６】
図１６は、データ連携ルール生成システム１０におけるデータ変換ルール定義情報を示す。
データ連携ルール生成システム１０のデータ変換ルール定義情報生成部２５は、プロトコル定義情報の生成対象となる業務システム４０を取得する（ステップＳ４１０）。これは、システム開発担当者が、図示しないキーボードやマウスなどの入力手段により指定してもよいし、予め、データ連携ルール生成システム１０内部で規定されたものであってもよい。
【００４７】
データ変換ルール定義情報生成部２５は、リポジトリインタフェース部２１を介して、対象業務システム４０のシステム属性情報及びデータ構造情報を読み出す（ステップＳ４２０）。さらに、プロトコル定義情報生成部２４は、内部で使用するデータ変換ルール定義情報テーブルの記憶領域を初期化する（ステップＳ４３０）。そして、対象業務システム４０のシステム属性情報内の内部コード情報を読み出し、データ変換ルール定義情報テーブルへ書き込む（ステップＳ４４０）。さらに、データ変換ルール定義情報生成部２５は、データ構造情報から最初のデータ項目と、そのデータ項目のデータ属性情報を取り出し、データ変換ルール定義情報テーブルに書き込む（ステップＳ４５０）。そして、データ構造情報内の全てデータ項目について、データ変換ルール定義情報テーブルへの書込みが終了したか否かを判断する（ステップＳ４６０）。全てのデータ項目について終了していなければ、次のデータ項目について、ステップＳ４５０及びステップＳ４６０の処理を繰り返す。
全てのデータ項目について終了した場合は、内部に記憶していたデータ変換ルール定義情報テーブルを、データ・コントロール・インタフェース部２３経由でデータ変換ルール定義情報記憶部３３に書き込む（ステップＳ４７０）。
【００４８】
図１４に示すデータ変換ルール定義情報では、業務システム４０ａが使用する内部コードは「ＥＵＣ」であり、各データ項目「受注Ｎｏ」、「顧客番号」、…は、それぞれ、「１０進数、４バイト」、「英数文字列、１６桁」、…のデータ属性を持つことを示している。同様に、業務システム４０ｂが使用する内部コードは「Ｓｈｉｆｔ−ＪＩＳ」であり、各データ項目「出荷番号」、「顧客番号」、…は、それぞれ、「２進数、４バイト」、「英数文字列、２０桁」、…のデータ属性を持つことを示している。
【００４９】
次に、図１７〜図２０を用いて、データ・コントロール・システム５０におけるデータ連携ルール生成システム１０が生成した各種データを用いたデータ連携処理を説明する。
図１７は、データ連携ルール生成システム１０が生成したプロトコル定義情報を用いたプロトコル変換処理フローを示す。
データ・コントロール・システム５０のプロトコルアダプタ５１は、業務システム４０からメッセージを受信すると（ステップＳ５１０：受信メッセージ）、プロトコル定義情報記憶部３２内のプロトコル定義情報を参照し、当該受信メッセージの送信元（連携元）の業務システム４０に対応する変換情報を読み出す。読み出した変換情報が「要」であり、受信メッセージのプロトコルが内部プロトコルと一致していないと判断した場合には（ステップＳ５２０：ＮＯ）、この受信メッセージをデータ・コントロール・システム５０の内部で使用するプロトコルに変換する（ステップＳ５３０）。そして、プロトコル変換した受信メッセージを送受信部５２に受け渡す（ステップＳ５４０）。なお、変換情報が「否」であり、受信メッセージのプロトコルが内部プロトコルと一致していると判断した場合には（ステップＳ５２０：ＹＥＳ）、プロトコル変換を行わずに受信メッセージを送受信部５２に受け渡す。
【００５０】
一方、プロトコルアダプタ５１が、送受信部５２から送信メッセージを受信した場合（ステップＳ５１０：送信メッセージ）、プロトコル定義情報記憶部３２内のプロトコル定義情報を参照し、当該送信メッセージの送信先の業務システム４０に対応する変換情報を読み出す。読み出した変換情報が「要」であり、送信先（連携先）の業務システム４０が使用しているプロトコルが内部プロトコルと一致していないと判断した場合には（ステップＳ５５０：ＮＯ）、この送信メッセージをプロトコル定義情報内の送信先の業務システム４０に対応したプロトコル情報で示されるプロトコルに変換する（ステップＳ５６０）。そして、プロトコル変換した送信メッセージを送信先の業務システム４０へ送信する（ステップＳ５７０）。なお、変換情報が「否」であり、送信先の業務システム４０で使用するプロトコルが内部プロトコルと一致していると判断した場合には（ステップＳ５５０：ＹＥＳ）、プロトコルに変換を行わずにメッセージを送信先の業務システム４０へ送信する。
【００５１】
図１８は、データ連携ルール生成システム１０が生成したデータ変換ルール定義情報を用いたデータ変換処理フローを示す。
データ・コントロール・システム５０のデータ変換部５３は、送受信部５２を介して受信メッセージを受け、このメッセージ内のデータを抽出すると（ステップＳ６１０：受信データ）、送信元の業務システム４０に対応するデータ変換ルール定義情報をデータ変換ルール定義情報記憶部３３から読み出す。そして、データ変換ルール定義情報内の内部コード情報及び各データに対応するデータ属性情報を参照し、受信メッセージ内の各データのデータ属性が、データ・コントロール・システム５０の内部表現形式と一致しているか否かを判断する（ステップＳ６２０）。受信メッセージ内のデータ項目の属性が、内部表現形式と一致していないと判断した場合（ステップＳ６２０：ＮＯ）、このデータの属性を内部表現形式に変換（ステップＳ６３０）する。一致していると判断した場合には（ステップＳ６２０：ＹＥＳ）、変換は実行しない。
【００５２】
一方、データ・コントロール・システム５０のデータ変換部５３が、コミュニケーション・バス５４から連携先の業務システム４０へ送信すべきメッセージを受け、このメッセージ内のデータを抽出すると（ステップＳ６１０：送信データ）、送信先（連携先）の業務システム４０に対応するデータ変換ルール定義情報をデータ変換ルール定義情報記憶部３３から読み出す。そして、データ変換ルール定義情報内の内部コード情報及び各データに対応するデータ属性情報を参照し、送信先の業務システム４０で使用しているデータの属性が、内部表現形式と一致しているか否かを判断する（ステップＳ６４０）。一致していないと判断した場合には（ステップＳ６４０：ＮＯ）、この送信データを送信先の業務システム４０で使用するデータ属性へと変換し（ステップＳ６５０）、送受信部５２へ受け渡す。なお、送信先の業務システム４０で使用しているデータの属性が、内部表現形式と一致していると判断した場合には（ステップＳ６４０：ＹＥＳ）、変換を行わずに、送受信部５２へ受け渡す。
【００５３】
図１９は、データ連携ルール生成システム１０が生成したシステム連携ルール定義情報を用いたデータ連携処理フローを示す。
データ・コントロール・システム５０のＢＰＭ５５は、コミュニケーション・バス５４が受けた１受信メッセージを読み出すと（ステップＳ７１０）、この受信メッセージのメッセージＩＤからデータ連携先の業務システム４０を決定する（ステップＳ７２０）。そして、受信メッセージから１データ項目を取り出し、このデータ項目が連携対象であるか否か判断する（ステップＳ７４０）。これは、メッセージの送信元である連携元業務システム４０及び連携先業務システム４０に対応したシステム連携ルール定義情報をシステム連携ルール定義情報記憶部３１から読み出し、ここに、取り出したデータ項目が存在するか否かによって判断する。連携対象であれば、後述する連携データの作成及び内部の連携データ格納領域への格納を行う（ステップＳ７５０）。そして、受信メッセージ内の全てのデータ項目について処理を行ったか否かを判断する（ステップＳ７６０）。全てのデータ項目について処理が終わっていない場合には（ステップＳ７６０：ＮＯ）、次のデータ項目について、ステップＳ７３０からステップＳ７６０の処理を行う。そして、全てのデータ項目について処理を行った場合には（ステップＳ７６０：ＹＥＳ）、連携データ格納領域に格納した連携対象のデータを連携先業務システム４０へ受け渡すためのメッセージの送信をコミュニケーション・バス５４へ指示する（ステップＳ７７０）。
【００５４】
図２０は、図１９のステップＳ７５０における詳細な処理フローを示す。
ＢＰＭ５５は、システム連携ルール定義情報記憶部３１内の連携元業務システム４０及び連携先業務システム４０に対応したシステム連携ルール定義情報を参照する。そして、現在注目しているデータ項目の連携の種別を読み出し、連携が共有であるか否かを判断する（ステップＳ８１０）。連携の種別が共有であれば（ステップＳ８１０：ＹＥＳ）、注目しているデータ項目に対応する受信メッセージ内のデータをそのまま連携データとして内部の連携データ格納領域に格納する（ステップＳ８２０）。
【００５５】
一方、連携が共有ではない、すなわち、継承であると判断した場合（ステップＳ８１０：ＮＯ）、さらに、連携の条件を参照し、連携の条件がタイミングであるか否かを判断する（ステップＳ８３０）。連携の条件がタイミングであった場合（ステップＳ８３０：ＹＥＳ）、タイミング条件がＯＫであるか否かを判断する（ステップＳ８４０）。これは、例えば、システム連携ルール定義情報内に連携の条件として「受注確定時」が設定されていれば、ある業務システム４０において、「受注確定」の業務が行われたときに設定されるべき特定のデータがすでに設定されているか否かにより判断する。タイミングがＯＫではない場合には（ステップＳ８４０：ＮＯ）、図１９のステップＳ７６０からの処理を行う。
【００５６】
ステップＳ８４０において、タイミングがＯＫであると判断した場合には、連携の条件として演算があるか否かを判断する（ステップＳ８５０）。演算がない場合には（ステップＳ８５０：ＮＯ）、注目しているデータ項目に対応する受信メッセージ内のデータを連携データとしてそのまま連携データ格納領域に格納する（ステップＳ８２０）。演算がある場合には（ステップＳ８５０：ＹＥＳ）、連携の条件で定義されている演算を行ったのちに（ステップＳ８６０）、連携データ格納領域への格納を行う（ステップＳ８２０）。
なお、ステップＳ８３０において、連携の条件がタイミングではないと判断した場合には、ステップＳ８５０からの処理を行う。
【００５７】
上記実施の形態によれば、業務システム間でデータ連携を実施する場合の工程及び工数は、以下のようになる。
（１）  事前設定：連携対象となる一連の業務を標準化した詳細な業務モデルとして登録
従来技術における連携のシナリオ設定に相当する。従来技術では既存業務をそのままに物理モデルとして定義するが、詳細まで落とさないため若干工数として少ない。
（２）  個別システム分析：業務システム数ｎ個分の分析（従来技術と同等の工数）
連携対象となる業務システムとして何があるのか、その仕様はどうなっているのかという把握は従来技術による工程と同様に必要となる。但し、対象業務システムの仕様を理解しているシステム開発担当者がいれば不要となる工程である。従来技術においては、連携定義を行うため、システム開発担当者となる一人または数人の要員がすべての業務システムを明確に理解する必要があるため、各業務システム仕様を分析する必要があった。本実施の形態によれば、業務システム仕様を理解しているシステム開発担当者がその仕様を登録し、業務モデルとのマッピングを行うのみで（後述する工程）自動的に連携定義が生成される。
（３）  システム仕様登録：業務システム数ｎ個分の登録
業務システムの仕様を分析したシステム開発担当者あるいは業務システムの仕様を理解しているシステム開発担当者が、その仕様を登録する。この登録は業務システム数のみでよい。ここでは、業務システム名、業務システムが保有するデータ項目とその仕様を登録するだけである。
（４）マッピング登録：業務システム数ｎ個分の登録
業務システムの仕様を分析したシステム開発担当者あるいは業務システムの仕様を理解しているシステム開発担当者が、（３）で登録したシステム仕様を業務モデルとマッピングする。ここでもマッピング登録は業務システム数のみを行えばよい。これは、（１）の業務システム分析による業務モデルや概念データが、このマッピングにおいて、実際のどの業務システムと、また、この業務システムの保有するどのデータ項目と対応するかを理解できなくてはならないからである。
上述した本実施の形態による工程及び工数と、従来技術による工程及び工数とを比較すると、工程数そのものが軽減され、かつ、各工程の工数が減少している。これは、対象となる業務システム数が増加すればそれだけ全体工数は大幅に減少する。
そして、業務システム仕様を理解しているシステム開発担当者がそれぞれの業務システムの仕様およびマッピングを登録するのであれば、連携定義工程は業務システム単位に並行して進める事が可能となり、工数のみでなく期間としても圧倒的な短縮が可能となる。
【００５８】
なお、上述のデータ連携ルール生成システム１０、業務システム４０、データ・コントロール・システム５０は、内部にコンピュータシステムを有している。そして、上述した動作の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータシステムが読み出して実行することによって、上記処理が行われる。ここでいうコンピュータシステムとは、ＯＳや周辺機器等のハードウェアを含むものである。
【００５９】
また、「コンピュータ読み取り可能な記録媒体」とは、ＲＯＭの他に、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のシステムやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。
【００６０】
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【産業上の利用可能性】
【００６１】
データ連携ツールの欠点である連携定義工数を削減するインタフェースコンポーネントとして利用可能である。
また、分散する物理的なデータを送受信する基盤として適用可能である。すなわち、データがどのように分散していても、中央に配置される業務モデルを経由して、その所在、形式を把握し、利用することができる。
さらに、システム資産管理（情報資源管理、データ管理）として適用可能である。すなわち、システム資産として何が在り、どのように配置されているか、どのような形式、仕様であるかを管理する。また、仕様のみでなくマッピングを管理することにより以下のような利用局面がある。
（１）どのような業務をサポートしているかの把握（システムマップ）
（２）システム変更の影響度分析
（３）システム間インタフェース分析、設計
【図面の簡単な説明】
【００６２】
【図１】本発明の一実施の形態によるデータ連携ルール生成システムの機能概要を説明するための図である。
【図２】同実施の形態によるシステム連携ルール定義情報の生成手順の概要を示す図である。
【図３】同実施の形態によるデータ連携ルール生成システムの内部構成を機能展開して示したブロック図である。
【図４】同実施の形態によるデータ・コントロール・システムの内部構成を機能展開して示したブロック図である。
【図５】同実施の形態による連携対象の業務の関連をモデル化した例を示す図である。
【図６】同実施の形態によるメタデータ項目間マッピング情報の設定例を示す図である。
【図７】同実施の形態によるメタデータ項目間マッピング情報の設定例を示す図である。
【図８】同実施の形態によるシステム物理仕様マッピング定義情報の設定例を示す図である。
【図９】同実施の形態によるシステム物理仕様マッピング定義情報の設定例を示す図である。
【図１０】同実施の形態によるシステム物理仕様マッピング定義情報の設定例を示す図である。
【図１１】同実施の形態によるシステム連携ルール定義情報生成フローを示す図である。
【図１２】同実施の形態によるシステム連携ルール定義情報の例を示す図である。
【図１３】同実施の形態によるシステム連携ルール定義情報の例を示す図である。
【図１４】同実施の形態によるシステム属性情報、データ構造情報、プロトコル定義情報、及び、データ変換ルール定義情報の設定例を示す図である。
【図１５】同実施の形態によるプロトコル定義情報生成フローを示す図である。
【図１６】同実施の形態によるデータ変換ルール定義情報を示す図である。
【図１７】同実施の形態によるプロトコル変換処理フローを示す図である。
【図１８】同実施の形態によるデータ変換処理フローを示す図である。
【図１９】同実施の形態によるデータ連携処理フローを示す図である。
【図２０】同実施の形態による連携データ作成及び格納の詳細な処理フローを示す図である。
【符号の説明】
【００６３】
１０…データ連携ルール生成システム
１１…業務モデル定義情報記憶部
１２…システム物理仕様定義情報記憶部
１３…システム物理仕様マッピング定義情報記憶部
２１…リポジトリインタフェース部
２２…システム連携ルール定義情報生成部
２３…データ・コントロール・インタフェース部
２４…プロトコル定義情報生成部
２５…データ変換ルール定義情報生成部
３１…システム連携ルール定義情報記憶部
３２…プロトコル定義情報記憶部
３３…データ変換ルール定義情報記憶部
４０ａ、４０ｂ、４０ｃ、４０ｉ、４０ｊ、４０ｎ…業務システム
５０…データ・コントロール・システム
５１…プロトコルアダプタ
５２…送受信部
５３…データ変換部
５４…コミュニケーション・バス
５５…ＢＰＭ
【図１】
2005063261.tif 000003
【図２】
2005063261.tif 000004
【図３】
2005063261.tif 000005
【図４】
2005063261.tif 000006
【図５】
2005063261.tif 000007
【図６】
2005063261.tif 000008
【図７】
2005063261.tif 000009
【図８】
2005063261.tif 000010
【図９】
2005063261.tif 000011
【図１０】
2005063261.tif 000012
【図１１】
2005063261.tif 000013
【図１２】
2005063261.tif 000014
【図１３】
2005063261.tif 000015
【図１４】
2005063261.tif 000016
【図１５】
2005063261.tif 000017
【図１６】
2005063261.tif 000018
【図１７】
2005063261.tif 000019
【図１８】
2005063261.tif 000020
【図１９】
2005063261.tif 000021
【図２０】
2005063261.tif 000022