JP2007531157A - 基幹業務アプリケーション統合のためのアダプタフレームワーク - Google Patents

Abstract

本発明は、複数の基幹業務（ＬＯＢ）アプリケーションとの相互運用性を高め、その対話形式操作を円滑にするフレームワークを提供する。特に、マップには、意味データおよび技術データなどのアプリケーションまたはシステム設計情報が書き込まれる。その後、マップは、ユーザが共通の一貫した実装技術上で共通の一貫した意味を持つ用語を対話形式により操作することを可能にするフレームワークにより使用される。その結果、ユーザおよび／またはクライアントデータアプリケーションは、複数の異種ＬＯＢソースからの意味論的に意味のあるデータを楽々と対話形式で操作することができる。

Description

本発明は、一般に、コンピュータに関するものであり、より具体的には、エンタープライズアプリケーションの統合および相互運用性をサポートするフレームワークに関するものである。

本出願は、参照により全体が本明細書に組み込まれている「Ａｎ Ａｄａｐｔｅｒ Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ｂｕｓｉｎｅｓｓ Ｉｎｔｅｌｌｉｇｅｎｃｅ Ｔｏｏｌｓ Ｃｏｎｎｅｃｔｉｖｉｔｙ ｔｏ Ｌｉｎｅ−ｏｆ−Ｂｕｓｉｎｅｓｓ Ｓｏｆｔｗａｒｅ Ａｐｐｌｉｃａｔｉｏｎｓ」という表題の２００４年４月２日に出願した米国仮出願第６０／５５９，０５２号および「Ａｄａｐｔｅｒ Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ｌｉｎｅ−Ｏｆ−Ｂｕｓｉｎｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｔｅｇｒａｔｉｏｎ」という表題の２００４年７月３０日に出願した米国特許出願第（不明）号の利益を主張するものである。

基幹業務（ＬＯＢ）アプリケーションは、今日の知識集約型企業にとって不可欠な技術である。ＬＯＢアプリケーションまたはシステムは、限定はしないが、会計、ＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ）、サプライチェーンマネージメント、および顧客関係管理（ＣＲＭ）を含む一連の、または一群の専用システムを備えることができる。これらの特定のシステムは、データを格納するＳＱＬ ＳｅｒｖｅｒおよびＯｒａｃｌｅなどのデータベース管理システムに結合している。本質的に、ＬＯＢアプリケーションは、レポートまたはその他のビジネスアプリケーションを介して分析できる形でユーザに提示される、事業の律動に関する重要な情報を供給する。しかし、これらのシステムは、さらに、独自性の高い非常に複雑なデータベーススキーマを採用している。そこで、ほとんどのベンダシステム（例えば、ＰｅｏｐｌｅＳｏｆｔ、ＳＡＰ．．．）では、明確でない数の非説明的な英数字または英数字列で顧客テーブルなどのデータ構造を識別している。したがって、現在のＬＯＢアプリケーションでは、データアクセスおよびプロセス統合はきわめて難しいものとなっている。

ＥＲＰなどのＬＯＢアプリケーションは、成熟した技術である。したがって、このような不明瞭さの一部は、一般にすべての種類のビジネスに現在利用されているシステムは元々特定の業界で設計されたのだという事実に発していることを念頭におく。古典的な例はＳＡＰであるが、これは、当初、ドイツの化学業界向けに設計された。したがって、ＳＡＰテーブルおよび列は、最大６個までのドイツの化学略号でラベル付けされている。そのため、ユーザがドイツ人化学者であったとしても、システムによって格納されているデータを取り出し、他の何らかの手段で対話操作しようとしてもかなりの困難を伴うことであろう。しかしながら、より新しい汎用アプリケーションであっても、わかりにくい表記で設計されている。この分野におけるコンセンサスは、とりわけテーブル、列、および行を識別する表記は、わざとわかりにくくされており、ユーザがそこにあるテーブル（例えば、顧客テーブル）に対し独自のオペレーション（例えば、抽出、ロード）を実行する意欲を失わせるということで一致している。むしろ、ユーザは、専用のデータ要素を識別するために使用される難解なメタデータを理解するコンサルタントおよびシステムインテグレータのサービスを保護しなければならない。こうしたコンサルタントおよびシステムインテグレータは、さらに、ＬＯＢアプリケーション用の独自の標準的展開および構成モデルを実装する。

さらに、企業は、少なくとも、ベンダ１社ではあらゆる組織ニーズに応えられないという理由から複数の全く異なるシステムを利用するのがふつうであることが多い。例えば、組織は、同じ機能に対し異なるベンダ２社を採用するか（例えば、財務に２つの異なるＥＲＰシステム）、または異なる複数の機能に対して複数のベンダを採用する（例えば、Ｓｉｅｂｅｌ ＣＭＲおよびＰｅｏｐｌｅＳｏｆｔの財務）ことができる。その結果、独自性の強いデータモデルのせいで、統合と相互運用性が阻害される。従来、インテグレーションベンダにより書かれたカスタムアプリケーション固有のアダプタは、このような内在する制限を克服するために使用されてきた。これらの専用アダプタは、アプリケーションのデータ形式および意味を第１の送信側アプリケーションから第２の受信側アプリケーションに変換するために使用される。しかし、専用アダプタは非常に高価であり、在庫品のアダプタだとカスタムアプリケーションに対応しない。さらに重要なことは、カスタムアプリケーション固有のアダプタは、パッチを用意しており、相互運用性問題の効率的な解決策とはなっていない。

したがって、当業では、馴染みのあるビジネスセマンティックス（ｂｕｓｉｎｅｓｓ ｓｅｍａｎｔｉｃｓ）を通じて、複雑な基幹業務データへのアクセスを公開するか、または他の何らかの手段によりアクセスを可能にする、効率的な中央集中型システムおよび方法が必要である。

以下では、本発明のいくつかの態様の基本的な内容を理解できるように、発明の開示を簡単に説明する。この発明の開示は、本発明の概要を広範囲にわたって述べたものではない。この発明の開示は、本発明の鍵となる／決定的な要素を示したり、本発明の範囲を定めることを目的としていない。後で述べる詳細な説明の前置きとして、本発明のいくつかの概念を簡略化した形式で述べることのみを目的とする。

簡単にいうと、本発明は、複数の異種の基幹業務システム間の統合および相互運用性を円滑にすることに関するということである。本発明のシステムを使用することにより、ＬＯＢアプリケーションメタデータに関する専用マッピングについての知識を補足し再利用することができる。さらに、主題発明は、広範なクライアントに対しわかりやすいビジネス分野の用語で表されたＬＯＢデータを供給し、ビジネスインテリジェンスおよび分析のためそのようなデータに対するハイパフォーマンス処理を円滑にすることを目指す。

本発明の一態様によれば、このシステムは、マップ生成システムおよびデータ抽出／対話形式操作システムを備える。マップ生成システムは、とりわけ、１つまたは複数の異種エンタープライズデータソースからデータを取り出し、要求側クライアントアプリケーションに返すためデータ抽出システムにより利用されるマップコンポーネントを生成するための手段を備える。特に、主題発明のマップコンポーネントは、メタデータマッピング部分およびプロトコルマッピング部分を含む。メタデータマッピング部分では、非記述的エンタープライズソースデータをふつうのビジネスセマンティックスにエイリアスするが、プロトコルマッピング部分は、とりわけ特定のデータソースとやり取りするために適切な接続カートリッジを識別する技術的マッピングである。マップ生成システムは、システムインテグレータにより公開された、または一から開発されたデータモデル情報を使用してマップコンポーネントを出力することができる。

本発明の一態様では、公開されたデータモデルの精度から、オブジェクトを作成し、カスタムデータモデルまたはサービスを構築する能力が明らかになる。例えば、ユーザは、特定のベンダにより公開されているような販売モデル全体を利用するのではなく、ただしこれも可能であるが、顧客モデルおよび製品モデルを使用して、独自の販売モデルを構築することができる。

本発明の他の態様では、対話形式のウィザードを使用することにより、ユーザは公開されているデータモデルから、または手動で、マップコンポーネントを構築することができる。

主題発明のさらに他の態様では、マップコンポーネントは、統一次元モデルでデータをマッピングするために使用されるデータソースビューとすることができる。しかし、限定はしないが、ＸＳＬＴおよびＡＤＬを含む他のマッピングも、主題発明で考察されている。

簡単にいうと、主題発明を使用することで、ユーザはわかりやすいビジネスセマンティックスを操作できるだけでなく、単一の馴染みのある技術を操作することもできる。したがって、ユーザが対話形式で使用するビジネスセマンティックスおよび技術の両方が一貫性および馴染みやすさを持ち、それによって、コードを書き、カスタムコンポーネントを構築する作業が容易になる。

前記の関係する目的を達成するために、本発明のいくつかの例示されている態様について、以下の説明および付属の図面に関して本明細書で説明される。これらの態様は、本発明を実施できるさまざまな方法を示しており、すべて、本発明の対象となることを意図されている。本発明の他の利点および新規性のある特徴は、図面を参照しつつ本発明の以下の詳細な説明を読むと明白になるであろう。

本発明の前述の態様および他の態様は、以下の詳細な説明および以下で簡単に説明されている付属の図面から明らかになるであろう。

次に、本発明は、付属の図面を参照しつつ説明され、本明細書全体を通して類似の番号は類似の要素または対応する要素を示す。しかし、図面および詳細な説明は発明を開示されている特定の形態に限定することを意図されていないことは理解されるであろう。むしろ、発明は、本発明の精神および範囲内にあるすべての修正形態、等価物、および代替形態を対象とする。

本出願で使用されているように、用語「コンポーネント」および「システム」は、コンピュータ関連のエンティティ、つまりハードウェア、ハードウェアとソフトウェアの組み合わせ、ソフトウェア、または実行中のソフトウェアのいずれかを指すことを意図されている。例えば、コンポーネントとして、限定はしないが、プロセッサ上で実行されているプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行のスレッド、プログラム、および／またはコンピュータなどがある。例えば、サーバ上で実行されているアプリケーションとサーバは両方ともコンポーネントであってよい。１つまたは複数のコンポーネントを１つのプロセスおよび／または実行スレッド内に常駐させることができ、またコンポーネントを１台のコンピュータにローカルとして配置し、および／または２台以上のコンピュータ間に分散させることができる。

本明細書で使用されているような用語「エンティティ」、「データエンティティ」、またはそれらの組み合わせまたは置換は、任意の種類のデータまたはメタデータを指し、より具体的には、意味論的に豊かな統合分野のデータ（例えば、「Ｃｕｓｔｏｍｅｒ」または「Ｐｕｒｃｈａｓｅ Ｏｒｄｅｒ」）を指すことが意図されている。

さらに、本発明は、開示されている発明を実装するコンピュータを制御するソフトウェア、ファームウェア、ハードウェア、またはそれらの組み合わせを生成する標準的なプログラミングおよび／またはエンジニアリング手法を使用する製造の方法、装置、または物品として実装することができる。本明細書で使用されているような「製造品」（または代替えとして「コンピュータプログラム製品」）という用語は、コンピュータ可読デバイス、搬送波、または媒体からアクセス可能なコンピュータプログラムを包含することが意図されている。例えば、コンピュータ可読媒体は、限定はしないが、磁気記憶デバイス（例えば、ハードディスク、フロッピー（登録商標）ディスク、磁気ストリップ．．．）、光ディスク（例えば、コンパクトディスク（ＣＤ）、デジタル多用途ディスク（ＤＶＤ）．．．）、スマートカード、およびフラッシュメモリデバイス（例えば、カード、スティック）を含むことができる。さらに、搬送波を使用して、電子メールの送信および受信またはインターネットまたはローカルエリアネットワーク（ＬＡＮ）などのネットワークへのアクセスに使用されるようなコンピュータ可読電子データを搬送できることは理解されるであろう。もちろん、当業者であれば、主題発明の範囲または精神から逸脱することなく、この構成に対し多くの修正を加えることができることは理解するであろう。

まず図１を参照すると、主題発明の一態様によるデータアクセスシステム１００が示されている。データアクセスシステム１００は、なかんずく、ＬＯＢメタデータの専用マッピングの知識の捕捉および再利用可能にする、さまざまなクライアントに対しビジネス分野の用語で表されるＬＯＢ データを公開する、およびビジネスインテリジェンスおよび分析のためＬＯＢデータのハイパフォーマンス処理を可能にするように設計されている。データアクセスシステム１００は、マップ生成システム１１０、マップコンポーネント１２０、およびデータ抽出システム１３０を備える。特に、マップ生成システム１１０は、設計データを受信し、マップコンポーネント１２０を生成する。マップコンポーネント１２０は、なかんずく、意味論的および技術的マッピング情報の一方または両方を含むことができる。主題発明の一態様によれば、マップコンポーネントは、わかりにくいアプリケーション特有の情報をわかりやすいまたは意味のあるビジネスセマンティックスに翻訳または公開するための意味情報を含むことができる。例えば、顧客情報を収容したテーブルを識別する数列などの抽象的な表記をわかりやすい名前「Ｃｕｓｔｏｍｅｒ Ｔａｂｌｅ」などにマッピングすることができる。さらに、マップコンポーネント１２０は、ユーザが複数の異種データソースに格納されているデータを対話形式で操作するのに単一の技術プラットフォーム（例えば、．Ｎｅｔ）または言語を学習するだけで済むように、アプリケーション情報の単一の実装技術へのマッピングを容易にするデータを含むことができる。より具体的には、マッピング（例えば、Ｃｕｓｔｏｍｅｒ．ＦｉｒｓｔＮａｍｅ＝ＫＮＡ１−ＮＡＭＥ１）に加えて、マップコンポーネント１２０は、エンティティ、イベント、オペレーション、および管理を含めることができる。エンティティは、意味論的に豊かな統合分野データである（例えば、「Ｃｕｓｔｏｍｅｒ」、「Ｐｕｒｃｈａｓｅ Ｏｒｄｅｒ」）。イベントは、エンタープライズアプリケーションの状態の変化を示すＬＯＢアプリケーションからの送信ＡＰＩ呼び出しである（例えば、顧客購買イベント）。オペレーションは、ＬＯＢアプリケーションへの受信Ｗｅｂサービスである。管理は、ｇｅｔ ｍｅｔａｄａｔａ、ｓｔａｒｔ、ｓｔｏｐ、ｐａｕｓｅ、ｒｅｓｕｍｅなどのアダプタコントロールに対応する。

データ抽出／対話形式操作システム１３０は、複数の基幹業務アプリケーションにより保持されるデータ（例えば、ロード、修正．．．）を取り出す、または他の何らかの手段により対話形式で操作するメカニズムを備える。特に、データ抽出システム１３０は、マップコンポーネント１２０を受け取り、その情報を利用して、１つまたは複数のエンタープライズシステムから指定データを抽出する。データ抽出システム１３０は、その後、取り出した情報を１つまたは複数のクライアントアプリケーションに供給し、さらに、とりわけ処理、永続、または表示を行う。

図２は、本発明の一態様によるマップ生成システム１１０を例示している。図に示されているように、マップ生成システム１１０は、１つまたは複数のデータモデルライブラリ２１０、データモデルアクセスコンポーネント２２０、およびマップビルダコンポーネント２３０を備えることができる。（複数の）ライブラリ２１０は、共通データモデル（例えば、ＳＡＰ、Ｓｉｅｂｅｌ、ＰｅｏｐｌｅＳｏｆｔ．．．）に対する複数のマッピングまたはマッピング情報を含む。本発明の一態様によれば、データライブラリは、以下でさらに詳しく説明されるように、与えられた接続方法によりＥＲＰシステムからエンティティを取り出すために必要なすべてのマッピングを含むことができる。データモデルアクセスコンポーネント２２０は、ライブラリ２１０からデータを公開するためのメカニズムを備える。特に、アクセスコンポーネント２２０は、マップビルダコンポーネント２３０またはユーザにより要求されるようにライブラリ２１０からデータモデルおよびマッピング情報を取り出す。本発明の一態様によれば、データモデルアクセスコンポーネント２２０は、ライブラリはＷｅｂサービスとしてセットアップできるのでＷｅｂサービス（および／またはオペレーティングシステムサービス）として実装することができ、ベンダはそれを利用して、自社のデータモデルを公開することができることが理解されるであろう。マップビルダコンポーネント２３０は、少なくとも一部はライブラリ２１０から取り出された情報からマップコンポーネント１２０を生成することができる。マップビルダコンポーネント２３０は、さらに、後のセクションで詳しく説明するが、インターフェイス（例えば、ＧＵＩ）を介して、限定はしないがユーザを含む他のソースからのマップコンポーネント構成において使用するため追加設計情報または要求条件を請求することもできる。さらに、ライブラリデータモデルを使用せずに、マップコンポーネントを一から手作業で作成できることに注意すべきである。さらに、マップコンポーネント１２０を使用することにより、ＬＯＢアプリケーション（Ａｃｃｅｎｔｕｒｅ、Ａｒｔｈｕｒ Ａｎｄｅｒｓｏｎ．．．）のシステムインテグレータ展開を体系化することができることも理解されるであろう。

さらに、ＬＯＢスキーママッピング定義を格納することに加えて、ライブラリ２１０はマップコンポーネント１２０を格納できることも理解されるであろう。ユーザ定義マップコンポーネント１２０は、いったん作成され名前が付けられた後、データモデルライブラリ２１０に保存することができる。したがって、生成されたマップコンポーネントは、オンデマンドで再作成するのではなく、ライブラリ２１０から取り出して容易に再利用することができる。

図３を参照すると、主題発明の一態様によるデータ抽出システム１３０が示されている。上述のように、データ抽出システム１３０は、複数の異なる基幹業務アプリケーションおよび異種ストアからデータエンティティを取り出す役割を持つ。抽出システム１３０は、１つのデータモデルプロバイダコンポーネント３１０および１つまたは複数の接続カートリッジコンポーネント３２０を備える。データモデルプロバイダコンポーネント３１０は、マップコンポーネント１２０により提供されるデータに作用する。特に、これは、マップコンポーネント１２０から接続カートリッジコンポーネント３２０に選択されたマッピングを受け渡すことにより、ＬＯＢシステムにデータを要求するクライアントにデータを供給する。接続カートリッジコンポーネント３２０は、ＬＯＢ ＡＰＩ（アプリケーションプログラミングインターフェイス）に接続するためのメカニズムまたはスキーマを備え、クエリまたはその他の要求呼び出しの形でマッピングをそれらに受け渡す。複数の独自システムとの対話形式による操作を可能にする異なる接続カートリッジコンポーネント３２０が多数ありうる。このような場合、マップコンポーネントは、特定のシステム上のデータにアクセスするために使用する特定の接続カートリッジコンポーネント３２０を指定することができる。要するに、データモデルプロバイダコンポーネント３１０は、マップコンポーネント１２０からモデルを読み込み、マップにより指定された通り接続カートリッジコンポーネント３２０を使用してＬＯＢシステムから指定データを抽出し、その後で、そのようなデータをクライアントシステムに供給する。

図４は、主題発明の一態様によるマップ生成システム４００の実施例を例示している。システム４００は、ＤＳＶビルダコンポーネント２３０、ＤＳＶコンポーネント１２０、データモデルサービスコンポーネント２２０、およびデータモデルライブラリ２１０を含む。このシステムでは、データソースビュー（ＤＳＶ）１２０は、マッピングコンポーネントとして採用されている。データソースビューは、統一ディメンションモデル（ＵＤＭ）のマッピングのための特定の技術である。ＵＤＭは、限定はしないが、多次元およびリレーショナルデータベースおよびデータウェアハウスを含む一組の異種データソースについて定義されたデータモデルである。したがって、ＵＤＭを利用すると、従来のＯＬＡＰベースの分析およびリレーショナルレポーティングの最良の態様にアクセスし使用することが簡単に行える。データソースビューは、マッピングのためのＵＤＭのコンポーネントである。例えば、ＤＳＶ １２０は、１つまたは複数のビジネスオブジェクト（例えば、顧客）またはデータモデル全体（例えば、地域別顧客売上高）を表すことができる。大まかにいうと、ＤＳＶ １２０は、とりわけソースメタデータをわかりやすい用語にエイリアスできる機能強化されたメタデータ機能である。データソースビュー１２０は、さらに、新しい列、欠損列、または変更列を検出でき、また大容量パフォーマンスのためスキーマから直接データを調達できるという点で堅牢であり、また有利である。さらに、ＤＳＶ １２０は、大量のデータを特に注目するより小さな部分集合に絞り込むことができる。例えば、データベーススキーマが１００００個のテーブルを持ち、それらのテーブルのうち５または６個のみを操作したいと仮定する。単一のテーブルが必要であるという最も基本的なシナリオでは、ユーザは、必要なテーブルが見つかるまで数千個のテーブルをスクロールする必要がある。それだと不効率であり、ユーザにとって苦痛な作業である。データソースビュー１２０を使用すれば、データを切り詰めて、注目するより小さな管理可能な部分集合に絞り込むことができる。上述のように、ＤＳＶ １２０ではさらに、わかりやすい名前を付けることもできる。わかりやすい名前とは、ＣｕＮやその他の暗号めいた名前ではなく「Ｃｕｓｔｏｍｅｒ Ｎｕｍｂｅｒ」のようなものである。そのため、１００００個のテーブルの隅から隅まで略号を検索しなくても、ユーザは、５個の関連するテーブルを調べて顧客番号を見つけることができる。

ＤＳＶ １２０は、指定されたデータモデルからＤＳＶビルダコンポーネント２３０により生成するか、または一から手作業で生成することができる。データモデルサービスコンポーネント２２０は、データモデルライブラリ２１０からＤＳＶコンポーネント１２０にデータモデルを供給する。例えば、限定はしないが、ＤＳＶビルダコンポーネント２３０とデータモデルサービスコンポーネント２２０との間の通信は、ＷｅｂサービスまたはＣＯＭ（コンポーネントオブジェクトモデル）技術を介して実現することができる。ライブラリ２１０は、複数のＥＲＰシステムへのマッピングとともにサービスコンポーネント２２０にデータモデルを提供する。ライブラリ２１０は、与えられた接続方法によりＥＲＰシステムからデータエンティティを取り出すために必要なすべてのマッピングを含む。例えば、ライブラリ２１０は、ＯＬＥＤＢ（さまざまなデータソースにリンクするためのＡＰＩ）を使用してＳＡＰアプリケーションから顧客データを取り出すためのマッピングおよびＡＢＡＰ（Ａｄｖａｎｃｅｄ Ｂｕｓｉｎｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ言語）を使用するためのマッピングを持つことができる。これは、接続方法は、概して、どのようなエンティティを定義できるかを定義するという点で重要である。例えば、ＳＡＰのプールテーブルでは、ＯＬＥＤＢを使用してマッピングできないエンティティをサポートしている。

図５を参照すると、主題発明の一態様によるデータ抽出システム例５００が示されている。システム５００は、データモデルプロバイダコンポーネント３１０、データクライアント５２０、接続カートリッジコンポーネント３２０、およびＬＯＢシステム（および関連するＡＰＩ、ＳＤＫ、スキーマ．．．）５１０を備える。データモデルプロバイダコンポーネント３１０を使用すると、限定はしないがＳＡＰ、ＳＩＥＢＥＬ、およびＭＳ ＣＲＭを含むＬＯＢシステム５１０とＥｘｃｅｌ、ＤＴＳ、Ａｎａｌｙｓｉｓ Ｓｅｒｖｉｃｅｓ、Ｒｅｐｏｒｔｉｎｇ ＳｅｒｖｉｃｅｓなどのＥＲＰデータクライアントとの間のデータ転送が円滑に行える。クライアントアプリケーション側でＬＯＢデータを取り出して使用したい場合、データプロバイダ３１２を通じてそれを実行できる。データプロバイダコンポーネント３１２を使用することにより、ＤＶＳコンポーネント１２０で定義されているマッピングに基づきＬＯＢアプリケーションからデータおよびメッセージにアクセスすることができる。つまり、データプロバイダコンポーネント３１２は、単に、ＡＰＩ呼び出しおよび独自機能詳細よりも高いレベルでデータを対話形式で操作しやすくするメカニズムであるといえる。本発明の一態様によれば、ＡＤＯ．ＮＥＴプロバイダをこの目的のために採用することができる。要求があれば、データプロバイダは、ＤＶＳパーザーコンポーネント３１４を使用して、ＤＶＳ １２０を読み取り、採用する接続カートリッジコンポーネント３２０のタイプ（例えば、ＡＢＡＰ、ＯＬＥＤＢ、ＡＤＯ．ＮＥＴ、．．．）を判別することができる。その後で、適切な接続カートリッジ３２０を初期化することができる。

接続カートリッジコンポーネント３２０は、データの受け渡しに関係する多数の関数を提供することができる。例えば、コンポーネントでは、ＤＳＶにより提供されるビュー定義を構文解析することができる。その後、マッピングされたスキーマが、データプロバイダコンポーネント３１２に返されるようにできる。その後、接続カートリッジコンポーネントは、用意されたスキーマに基づきデータプロバイダ３１２からクエリを受け取ることができる。続いて、ＤＳＶからの接続詳細を使用して、適切なデータアクセスプロトコル（例えば、ＡＰＩ、直接テーブル、メッセージ．．．）を決定することができる。その後、ＬＯＢソース５１０からデータが取り出され、データプロバイダコンポーネント３１２に供給され、要求側クライアントアプリケーション５２０に送信されるようにできる。したがって、必要なデータエンティティ毎に、データプロバイダ３１２は、クエリマッピングを接続カートリッジコンポーネント３２０に受け渡し、ＥＲＰシステム５１０からデータを取り出すことができる。

上で説明した内容は、データソースビューをマッピングコンポーネント１２０として使用する主題発明の実施例である。しかし、マッピングコンポーネント１２０はＤＳＶに固有のものではないことは理解されるであろう。実際、マッピングコンポーネント１２０は、データマッピングを表すことができるものであれば何でもよい。したがって、マッピングコンポーネントは、いくつか既存技術の例を挙げると、ＸＳＬＴまたはＡＤＬバケットフレームワークを使用して実装することも可能である。さらに、主題発明のシステムを実装するためにすべてのコンポーネントが必ず必要なわけではなく、一部の機能は他の他のコンポーネントにより実行することも可能であることは理解されるであろう。

図６は、本発明の一態様により実現される機能強化されたデベロッパーエクスペリエンスを示す画面である。図に示されているように、ソースデータベースからデータを抽出するためのグラフィカルユーザインターフェイス（ＧＵＩ）はＧＵＩ ６１０とＧＵＩ ６２０の２つがある。ＧＵＩ ６１０は、従来のインターフェイスを例示している。テーブルまたはビュー定義からわかるように、基本的な接続のためは、開発者側はテーブルを結合する方法を含む特定のＬＯＢアプリケーションの立ち入った知識があることが要求される。ＧＵＩ ６２０は、主題発明の一態様によるＧＵＩ例である。ここで、マッピングコンポーネントを介した機能強化されたメタデータがＬＯＢの詳細について抽象化の層を備えることがわかる。したがって、ユーザは、ＬＯＢアプリケーションの暗号めいた詳細を解読しようとしなくても、ＬＯＢのコンテンツを使用することに注意を集中することができる。適切であれば、マッピングコンポーネントは、その後、ＡＰＩを呼び出すか、またはＬＯＢデータベースに対して直接操作し、エンタープライズデータを対話形式で操作することができる。

主題発明の他の態様によれば、ユーザはウィザードを使用して、マッピングコンポーネントまたはデータソースビュー１２０を設計することができる。ウィザードは、開発者を一連のステップに案内するユーザインターフェイス（例えば、ＧＵＩ）であり、それぞれのステップは、もちろん、そのステップがオプションでない限り、一連のステップの中の次のステップに進む前に完了されなければならない。図７〜１０は、データソースビュー１２０を生成するために使用されることができるグラフィカルユーザインターフェイスのウィザード例を示している。それぞれの図は、ＤＳＶを設計する際にユーザを多数の選択オプションへと案内することを容易にするため複数の関連イメージおよびインターフェイスオブジェクトまたは要素を含むＧＵＩを示している。しかし、これらの図は、例として載せてあるのであって、制限するためのものではないことに留意されたい。当業者であれば理解できるであろうが、グラフィカルユーザインターフェイスを配置し提示する方法は多数ある。示されているＧＵＩは、そのような配置の１つにすぎず、主題発明の範囲を制限するためではなく、わかりやすく理解しやすくすることを目的として提示されている。

図７を参照すると、主題発明の一態様によるＤＳＶを生成することに関連する第１のＧＵＩ例７００が示されている。ＧＵＩ ７００は、ＤＳＶがどのように作成されているか−手作業で一から作成されているのか、それともＤａｔａ Ｍｏｄｅｌ Ｐｒｏｖｉｄｅｒを使用しているのか−についてのオプションをユーザ／開発者向けに用意している。ＧＵＩ ７００は、ポインティングデバイスおよび／またはクリックデバイス（例えば、マウス、トラックボール、タッチパッド、タッチスクリーンディスプレイ、ペン入力など）またはキーボードによりアクティブ化できる複数のボタンおよびスイッチを備える。トグルスイッチ７１０は、Ｄａｔａ Ｍｏｄｅｌ Ｐｒｏｖｉｄｅｒを使用してＤＳＶを作成するか、または手作業でＤＳＶを作成するユーザ／開発者向けのオプションを備える。ここでは、Ｄａｔａ Ｍｏｄｅｌ Ｐｒｏｖｉｄｅｒを使用してＤＳＶを作成するボックスが作動されている。ユーザは、ボタン７１２を使用して、「Ｎｅｘｔ」で次のステップに進む、「Ｂａｃｋ」で前のステップに戻る、または単に「Ｃａｎｃｅｌ」をクリックしてウィザードを終了するという操作によりウィザード内をナビゲートすることができる。「Ｎｅｘｔ」をクリックすると、追加オプションまたは選択項目が含まれる新しいＧＵＩが現れる。

図８は、主題発明の一態様によるＤＳＶを生成することに関連する第２のＧＵＩ例８００を示す。ＧＵＩ ８００では、ユーザは、ローカルデータモデルプロバイダサービスまたはインターネット上に置かれているリモートサービスを使用して、例えば、データモデルを選択することができる。例示されているように、ＧＵＩ ８００は２つのトグルスイッチ８１０、テキストボックス８１２、検索ボタン８１４、およびナビゲーションボタン７１２を備える。ユーザは、ポインティングデバイスおよび／またはクリックデバイスまたはキーワードを使用してそれぞれのトグルボタンをアクティブ化し、ＤＳＶを生成する際にローカルデータモデルサービスを使用すべきか、データモデルＷｅｂサービスを利用すべきかを指示することができる。ここでは、ローカルデータモデルサービスを使用することに関連付けられたトグルが選択される。他のトグルがアクティブ化された場合、ユーザはテキストボックス８１２で使用したいＷｅｂサービスのあるロケーションを入力するか、または検索ボタン８１４をアクティブ化することにより検索を開始する必要がある。ＧＵＩ ８００は、さらに、ナビゲーションボタン７１２も備え、これにより次のステップに進む、戻る、ＤＳＶの作成をキャンセルするといった操作を行う。

図９ａは、主題発明の一態様によるＤＳＶを生成することに関連する第３のＧＵＩ ９００である。ＧＵＩ ９００を使用すると、ユーザは、後からデータモデルが選択されるアプリケーションを選ぶことができる。ここで、ＧＵＩ ９００は、ドロップダウンメニュー９１０を備えており、ユーザに対し選択可能なアプリケーションのリストが表示される。ＳＡＰ、Ｒ／３などのアプリケーションの選択後、そのアプリケーションに利用可能なモデルデータモデルのリストが図９ｂに示されているようにスクロール可能なウィンドウ９１２内に提示される。ユーザは、スクロール可能なウィンドウ９１２内で１つまたは複数の所望の利用可能なデータモデルを強調表示することができるが、そのために、例えば、ポインティングデバイスによりそれらをクリックする。これ以降、ユーザは、選択矢印９１４をクリックすることによりモデルを選択できる。選択後、選択されたモデルは、図９ｃに示されているように、スクロール可能なウィンドウ９１６内に表示される。ユーザは、後になって、選択されたモデルのうち１つまたは複数を削除したい場合、再び、適切な手段によりモデルを強調表示にし、その後、削除ボタン９１８を選択することができる。このようなアクションが生じると、強調表示されたオブジェクトがウィンドウ９１６から削除され、ウィンドウ９１２に戻され追加される。アイテムの選択は、複数のアプリケーションから行うことができ、それによって、完全にカスタマイズされたデータモデルの設計が可能になることは理解されるであろう。しかし、ユーザは、アプリケーション（例えば、ＳＡＰ Ｒ／３）からデータモデル全体を単に選択することができる。ユーザがＤＳＶに入れたいすべてのデータモデルオブジェクトを選択した後、ナビゲーションボタン７１２を使用して、次のステップに移動する、１ステップ戻る、またはＤＳＶ作成プロセスをキャンセルする操作を行うことができる。

図１０を参照すると、ＧＵＩ １０００が主題発明の一態様により例示されている。ＧＵＩ １０００は、データソースビューのプレビューおよび保存のための手段を備える。それによると、データソースビュー名を入力するためのテキストボックス１０１０が用意されている。さらに、ユーザが、作成されたデータソースビューをプレビューするためのスクロール可能なウィンドウ１０１２も用意される。ここでは、３つのデータモデルオブジェクトがＳＡＰ Ｒ／３アプリケーションから選択されている。最後に、１ステップ戻ってＤＳＶの作成を完了したり、ＤＳＶウィザードをキャンセルしたりするためのナビゲーションキー１０１４が用意される。

図１１は、主題発明の一態様によるＤＳＶ開発環境を例示している。ここで、ＧＵＩ １１００は、特に、構成されたデータソースビューを示しており、これは、上述のウィザードを使用して構成されたか、または開発環境の助けを借りて手作業で構成された。開発環境は、ＤＳＶ構成を手助けするための複数のツールへの有用なグラフィカルインターフェイスを含むことができる。データソースビューまたはマップは、選択されたオブジェクトに対するデータモデルサービスコンポーネントから返されたメタデータを使用して、ユーザ向けに構築することができる。例示されているように、わかりやすい名前がソースＬＯＢアプリケーションの難解な名前（例えば、ｃｉｔｙとＯＲＴＯ１、ｚｉｐとＰＬＳＴＬＺ、ｐｈｏｎｅとＴＥＬＦ１、．．．）にマッピングされ、それとのやり取りが円滑に行える。

上述のシステム例を参照すると、本発明により実装することができる方法は、図１２〜１４の流れ図を参照するとよりよく理解されるであろう。説明を簡単にするために、方法を図に示し、一連のブロックとして記述するが、本発明はブロックの順序によって制限されるわけではなく、本発明により、いくつかのブロックは、その図に示されているここで説明している内容と異なる順序でおよび／または他のブロックと同時に実行することも可能であることも理解される。さらに、本発明により、方法を実装するために例示されているすべてのブロックが必要なわけではない。

さらに、これ以降および本明細書全体を通して開示されている方法は、そのような方法をコンピュータに移送し転送すること円滑にするための製造品に格納することができることは理解されるであろう。使用されている「製造品」という用語は、コンピュータ可読デバイス、搬送波、または媒体からアクセス可能なコンピュータプログラムを包含することが意図されている。

図１２を参照すると、主題発明の一態様によるデータアクセス方法１２００が示されている。方法１２００は、複数の企業資源管理システムからデータを取り出すのに特に好適である。１２１０で、マップが生成される。このマップは、複雑な、または難解な基幹業務メタデータをわかりやすいビジネスセマンティックスにエイリアスすることができる。さらに、マップを使用することにより、複数の異種エンタープライズシステムを単一のプラットフォームにマッピングすることができ、これによりユーザは格納されているデータを対話形式で操作するためにいくつかの異なるシステムを学習する必要性がなくなる。むしろ、ユーザは、単純に、複数のシステム上にあるデータの表示、取り出し、およびコーディングに１つのプラットフォームを使用することができる。マップは、限定はしないが、データソースビュー、ＸＭＬ、またはＡＤＬを含む複数の形式のマップとすることができる。したがって、特定のマッピング技術があれば、利点が増す可能性がある。例えば、データソースビューは、フィルタ処理によりデータを関連情報の部分集合に狭めることができる。１２２０で、生成されたマップが、ＬＯＢデータソースからデータを抽出するために使用される。

図１３は、主題発明の一態様によるエンタープライズデータアクセス方法１３００の流れ図を示す。１３１０で、データクライアントからエンタープライズデータの要求が受信される。データクライアントは、限定はしないが、Ｅｘｃｅｌ、ＤＴＳ（Ｄａｔａ Ｔｒａｎｓｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅｓ）、分析サービス、およびレポート作成サービスを含むことができる。クライアントは、データプロバイダ（例えば、ＡＤＯ．ＮＥＴ）を介してデータを要求することができる。１３２０で、データマップは、クライアントからのデータ要求への応答としてアクセスされることができる。例えば、データマップが解析され、データプロバイダは、マッピングとともに存続している、このマップから必要な接続プロトコル（例えば、接続カートリッジ、アダプタ．．．）を取り出すことができる。１３３０で、マッピングを使用して（複数の）エンタープライズソースからデータを抽出することができる。特に、クライアントによって必要なエンティティ毎に、マッピングを（複数の）適切な接続カートリッジに受け渡し、データを（複数の）ソースから取り出すことができる。その後、取り出されたデータは、データプロバイダを使用して、クライアントアプリケーションに返されるようにできる。このようにして、不明瞭なソースデータを複数の基幹業務アプリケーションから取り出して、わかりやすいビジネス用語でアプリケーションに公開することができる。さらに、単一のプラットフォームを使用することにより、データの取り出しおよび操作を行うことができる。主題発明では、さらに、クライアントアプリケーションによるデータの操作およびマップを使用したデータのソースへのプッシュバックについても考察している。

図１４は、主題発明の一態様によりデータを取り出す（１４００）方法を示している。１４１０で、マップコンポーネント定義が解析される。１４２０で、マッピングされたスキーマがデータプロバイダコンポーネントに提示される。マッピングされたスキーマは、わかりやすいビジネスセマンティックスを使用してデータエンティティを識別する。１４３０で、データプロバイダコンポーネントを介してエンタープライズクライアントからクエリを受け取る。１４４０で、マップコンポーネントにより与えられる詳細を使用して、データアクセスプロトコル／ＡＰＩを決定する。（複数の）適切なデータアクセスプロトコルを使用して、１４５０で、データが適切な１つまたは複数のエンタープライズソースから取り出される。最後に、１４６０で、接続カートリッジおよびデータプロバイダコンポーネントを介してデータがクライアントに返され、それによりクエリの要件を満たす。

本発明のさまざまな態様の背景状況を示すために、図１５および１６は以下の説明とともに、本発明のさまざまな態様を実装できる好適なコンピューティング環境の簡潔な概要的説明を示すことが意図されている。本発明は、１つおよび／または複数のコンピュータ上で実行されるコンピュータプログラムのコンピュータ実行可能命令の一般的な背景状況において上で説明されているが、当業者であれば、本発明は、他のプログラムモジュールと組み合わせて実装できることも理解するであろう。一般に、プログラムモジュールは、特定のタスクを実行する、および／または特定の抽象データ型を実装するルーチン、プログラム、コンポーネント、データ構造などを含む。さらに、当業者であれば、本発明の方法は、シングルプロセッサまたはマルチプロセッサコンピュータシステム、ミニコンピューティングデバイス、メインフレームコンピュータ、さらにはパーソナルコンピュータ、ハンドヘルドコンピューティングデバイス、マイクロプロセッサベースまたはプログラム可能な家電製品などを含む、他のコンピュータシステム構成で実施できることを理解するであろう。本発明の例示されている態様は、通信ネットワークを通じてリンクされているリモート処理デバイスによりタスクが実行される分散コンピューティング環境で実施することもできる。しかし、本発明のすべての態様ではないとしても一部は、スタンドアロンコンピュータ上で実施できる。分散コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートの両方のメモリ記憶デバイス内に配置されうる。

図１５を参照すると、本発明のさまざまな態様を実装するための環境例１５１０はコンピュータ１５１２を含んでいる。コンピュータ１５１２は、処理ユニット１５１４、システムメモリ１５１６、およびシステムバス１５１８を備える。システムバス１５１８は、限定はしないがシステムメモリ１５１６を含むシステムコンポーネントを処理ユニット１５１４に結合する。処理ユニット１５１４は、さまざまな市販プロセッサがあるがそのうちのどれでもよい。デュアルマイクロプロセッサおよびその他のマルチプロセッサアーキテクチャも、処理ユニット１５１４として採用することができる。

システムバス１５１８は、メモリバスまたはメモリコントローラ、周辺機器バスまたは外部バス、および／または１１ビットバス、Ｉｎｄｕｓｔｒｉａｌ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）、Ｍｉｃｒｏ−Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＳＡ）、Ｅｘｔｅｎｄｅｄ ＩＳＡ（ＥＩＳＡ）、Ｉｎｔｅｌｌｉｇｅｎｔ Ｄｒｉｖｅ Ｅｌｅｃｔｒｏｎｉｃｓ（ＩＤＥ）、ＶＥＳＡ Ｌｏｃａｌ Ｂｕｓ （ＶＬＢ）、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ（ＵＳＢ）、Ａｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）、Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ Ｍｅｍｏｒｙ Ｃａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ａｓｓｏｃｉａｔｉｏｎバス（ＰＣＭＣＩＡ）、およびＳｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅ（ＳＣＳＩ）をはじめとする利用可能な各種バスアーキテクチャを使用するローカルバスなど数種類のバス構造のうちのいずれでもよい。

システムメモリ１５１６は、揮発性メモリ１５２０および不揮発性メモリ１５２２を含む。起動時などにコンピュータ１５１２内の要素間の情報転送を行うための基本ルーチンを含む基本入出力システム（ＢＩＯＳ）は、不揮発性メモリ１５２２に格納される。例えば、限定はしないが、不揮発性メモリ１５２２には、読み取り専用メモリ（ＲＯＭ）、プログラム可能ＲＯＭ（ＰＲＯＭ）、電気的プログラム可能ＲＯＭ（ＥＰＲＯＭ）、電気的消去可能ＲＯＭ（ＥＥＰＲＯＭ）、またはフラッシュメモリなどがある。揮発性メモリ１５２０には、外部キャッシュメモリとして動作するランダムアクセスメモリ（ＲＡＭ）がある。例えば、限定はしないが、使用可能なＲＡＭには、同期ＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、同期ＤＲＡＭ（ＳＤＲＡＭ）、Ｄｏｕｂｌｅ Ｄａｔａ Ｒａｔｅ ＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、Ｅｎｈａｎｃｅｄ ＳＤＲＡＭ（ＥＳＤＲＡＭ）、Ｓｙｎｃｈｌｉｎｋ ＤＲＡＭ（ＳＬＤＲＡＭ）、およびＤｉｒｅｃｔ Ｒａｍｂｕｓ ＲＡＭ（ＤＲＲＡＭ）などさまざまな形態のものがある。

コンピュータ１５１２は、さらに、取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体も備える。図１５は、例えばディスク記憶装置１５２４を例示している。ディスク記憶装置４１２４は、限定はしないが、磁気ディスクドライブ、フロッピディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、またはメモリスティックを含む。さらに、ディスク記憶装置１５２４は、記憶媒体を、単独で備えることも、また限定はしないが、コンパクトディスクＲＯＭデバイス（ＣＤ−ＲＯＭ）、ＣＤ書き込み可能ドライブ（ＣＤ−Ｒドライブ）、ＣＤ書き換え可能ドライブ（ＣＤ−ＲＷドライブ）、またはデジタル多用途ディスクＲＯＭドライブ（ＤＶＤ−ＲＯＭ）などの光ディスクドライブを含む他の記憶媒体と組み合わせて備えることもできる。ディスク記憶装置１５２４をシステムバス１５１８に接続しやすくするために、通常、インターフェイス１５２６などの取り外し可能または取り外し不可能インターフェイスを使用する。

図１５は、ユーザと適当な動作環境１５１０内の説明されている基本コンピュータ資源との媒介手段として動作するソフトウェアを説明していることは理解されるであろう。このようなソフトウェアとして、オペレーティングシステム１５２８がある。オペレーティングシステム１５２８は、ディスク記憶装置１５２４に格納することができ、コンピュータシステム１５１２の資源の制御および割り当てを行う働きをする。システムアプリケーション１５３０は、システムメモリ１５１６またはディスク記憶装置１５２４に格納されているプログラムモジュール１５３２およびプログラムデータ１５３４を通じてオペレーティングシステム１５２８により資源の管理を利用する。本発明は、さまざまなオペレーティングシステムまたはオペレーティングシステムの組み合わせで実装できることは理解されるであろう。

ユーザは（複数の）入力デバイス１５３６を使用してコマンドまたは情報をコンピュータ１５１２に入力する。入力デバイス１５３６は、限定はしないが、マウスなどのポインティングデバイス、トラックボール、ペン、タッチパッド、キーボード、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナ、ＴＶチューナーカード、デジタルカメラ、デジタルビデオカメラ、Ｗｅｂカメラなどを含む。これらの入力デバイスやその他の入力デバイスは、（複数の）インターフェイスポート１５３８を介してシステムバス１５１４を通じて処理ユニット１５１８に接続する。例えば、（複数の）インターフェイスポート１５３８には、シリアルポート、パラレルポート、ゲームポート、およびユニバーサルシリアルバス（ＵＳＢ）がある。（複数の）出力デバイス１５４０は、（複数の）入力デバイス１５３６と同じ種類のポートのうちいくつかを使用する。したがって、例えば、ＵＳＢポートを使用して、コンピュータ１５１２に入力し、コンピュータ１５１２から情報を出力デバイス１５４０に出力することができる。出力アダプタ１５４２が備えられており、特別なアダプタを必要とする、他の出力デバイス１５４０のうちディスプレイ（例えば、フラットパネルおよびＣＲＴ）、スピーカ、およびプリンタなどいくつかの出力デバイス１５４０があることを示している。出力アダプタ１５４２は、例えば、限定はしないが、出力デバイス１５４０とシステムバス１５１８とを接続する手段となるビデオおよびサウンドカードを含む。他のデバイスおよび／またはデバイスのシステムは（複数の）リモートコンピュータ１５４４などの入出力機能を備えることに留意されたい。

コンピュータ１５１２は、（複数の）リモートコンピュータ１５４４などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク接続環境で動作させることができる。（複数の）リモートコンピュータ１５４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの機器、ピアデバイス、またはその他の共通ネットワークノードなどとすることができ、通常は、コンピュータ１５１２に関係する上述の要素の多くまたはすべてを含む。簡単のため、メモリ記憶装置１５４６のみ（複数の）リモートコンピュータ１５４４とともに例示してある。（複数の）リモートコンピュータ１５４４は、ネットワークインターフェイス１５４８を通じてコンピュータ１５１２に論理的に接続され、通信接続１５５０を介して物理的に接続される。ネットワークインターフェイス１５４８は、ローカルエリアネットワーク（ＬＡＮ）およびワイドエリアネットワーク（ＷＡＮ）などの通信ネットワークを含む。ＬＡＮ技術には、Ｆｉｂｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ（ＦＤＤＩ）、Ｃｏｐｐｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ（ＣＤＤＩ）、Ｅｔｈｅｒｎｅｔ（登録商標）／ＩＥＥＥ １１０２．３、Ｔｏｋｅｎ Ｒｉｎｇ／ＩＥＥＥ １１０２．５などがある。ＷＡＮ技術には、限定はしないが、２地点間接続リンク、統合デジタル通信網（ＩＳＤＮ）などの回線交換ネットワークとその変種、パケット交換ネットワーク、およびデジタル加入者回線（ＤＳＬ）などがある。

（複数の）通信接続１５５０とは、ネットワークインターフェイス１５４８をバス１５１８に接続するために使用されるハードウェア／ソフトウェアのことである。通信接続１５５０はわかりやすくするためにコンピュータ１５１２内に示されているが、コンピュータ１５１２の外部にあってもかまわない。ネットワークインターフェイス１５４８の接続に必要なハードウェア／ソフトウェアには、例にすぎないが、通常の電話グレードのモデム、ケーブルモデム、パワーモデム、およびＤＳＬモデムを含むモデム、ＩＳＤＮアダプタ、およびＥｔｈｅｒｎｅｔ（登録商標）カードなどの内部および外部技術がある。

図１６は、本発明との相互やり取りが可能なコンピューティング環境１０００の実施例を示す概略ブロック図である。システム１６００は、１つまたは複数のクライアント１６１０を備える。（複数の）クライアント１６１０は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）とすることができる。システム１６００は、さらに、１つまたは複数のサーバ１６３０も備える。（複数の）サーバ１０３０もまた、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）とすることができる。サーバ１６３０には、例えば、本発明を採用することにより変換を実行するスレッドを置くことができる。クライアント１６１０とサーバ１６３０との間で可能な通信の１つは、２つ以上のコンピュータプロセス間で伝送されるように適合されたデータパケットの形で実行できる。システム１０００は、（複数の）クライアント１６１０と（複数の）サーバ１６３０との間の通信を円滑にするために採用することができる通信フレームワーク１６５０を含む。（複数の）クライアント１６１０は、（複数の）クライアント１６１０のローカルにある情報を格納するために使用することができる１つまたは複数のクライアントデータストア１６６０に接続し動作させることができる。同様に、（複数の）サーバ１６３０は、（複数の）サーバ１６３０のローカルにある情報を格納するために使用することができる１つまたは複数のサーバデータストア１６４０に接続し動作させることができる。

上述した内容は、本発明の複数の実施例を含む。もちろん、本発明を説明するためにコンポーネントまたは方法の考えられるすべての組み合わせを説明することは不可能であるが、当業者であれば、本発明の他の多くの組み合わせおよび置換が可能であることを理解できるであろう。したがって、本発明は、付属の請求項の精神と範囲内に収まるすべてのそのような変更、修正、および変更形態を包含することが意図されている。さらに、「含む、備える」という言い回しを詳細な説明または請求項で使用している範囲において、このような用語は「備える、含む」という用語と似た使い方をし、これは使用した場合に請求項の中で暫定的用語と解釈する。

主題発明の一態様によるデータアクセスシステムのブロック図である。 本発明の一態様によるマップビルダコンポーネントのブロック図である。 主題発明の一態様によるデータ抽出システムのブロック図である。 主題発明の一態様によるマップ生成システム例のブロック図である。 本発明の一態様によるデータ抽出システムのブロック図である。 本発明の一態様により実現される強化されたユーザエクスペリエンスを示す画面である。 主題発明の一態様によるＤＳＶを生成することに関連するＧＵＩ例を示す画面である。 主題発明の一態様によるＤＳＶを生成することに関連するＧＵＩ例を示す画面である。 本発明の一態様によるＤＳＶを出力することに関連するＧＵＩ例を示す画面である。 主題発明の一態様によるＤＳＶを構成することに関連するＧＵＩ例を示す画面である。 本発明の一態様によるＤＳＶを生成することに関連するＧＵＩ例を示す画面である。 主題発明の一態様によるＤＳＶを出力することに関連するＧＵＩ例を示す画面である。 本発明の一態様により構成されたＤＳＶを示すＧＵＩの画面である。 主題発明の一態様によるデータアクセス方法を例示する流れ図である。 主題発明の一態様によるマップ生成方法を例示する流れ図である。 主題発明の一態様によるデータ取り出し方法を例示する流れ図である。 本発明の一態様による好適な動作環境を例示する概略ブロック図である。 本発明との相互やり取りが可能なコンピューティング環境例の概略ブロック図である。

Claims (40)

1. データアクセスシステムであって、
   ソースメタデータを共通のビジネスセマンティックスにエイリアスするマップコンポーネントを生成するためのマップ生成システムと、
   前記マップを使用して基幹業務システムからデータを抽出するデータ抽出システムとを備えることを特徴とするデータアクセスシステム。
2. 前記マップコンポーネントは、意味論的マッピングと技術的マッピングの両方を含むことを特徴とする請求項１に記載のシステム。
3. 前記マップコンポーネントは、データソースビューであることを特徴とする請求項１に記載のシステム。
4. 前記マップコンポーネントは、ＸＳＬＴドキュメントであることを特徴とする請求項１に記載のシステム。
5. 前記マップ生成システムは、
   データモデルおよびマッピング情報を格納するためのデータモデルライブラリと、
   前記ライブラリからデータを取り出すためのデータモデルアクセスコンポーネントと、
   少なくとも一部は前記ライブラリから取り出された情報からマップコンポーネントを生成するためのマップビルダコンポーネントとを備えることを特徴とする請求項１に記載のシステム。
6. 前記データモデルアクセスコンポーネントは、Ｗｅｂサービスとして実装されることを特徴とする請求項５に記載のシステム。
7. 前記マップビルダコンポーネントは、マップコンポーネントの構成を指令するユーザインターフェイスとして実装されることを特徴とする請求項５に記載のシステム。
8. 前記インターフェイスは、マップコンポーネントウィザードであることを特徴とする請求項７に記載のシステム。
9. 生成されたマップコンポーネントは、検索および取り出しが行えるように前記データモデルライブラリに保存できることを特徴とする請求項４に記載のシステム。
10. 前記データ抽出システムは、
    データモデルプロバイダコンポーネントと、
    接続カートリッジコンポーネントとを備え、前記プロバイダコンポーネントは、前記接続カートリッジコンポーネントを利用し、マップコンポーネントで用意されるデータを使用して前記システムからデータを抽出することを特徴とする請求項１に記載のシステム。
11. 前記マップコンポーネントは、取り出される前記データおよび前記ソースに基づいて前記適切な接続カートリッジコンポーネントを識別することを特徴とする請求項１０に記載のシステム。
12. 前記接続カートリッジコンポーネントは、ＬＯＢ ＡＰＩおよび／またはスキーマに接続する動作が可能であり、クライアントアプリケーションにより定義されたクエリの形でマッピングをＬＯＢ ＡＰＩおよび／またはスキーマに受け渡すことを特徴とする請求項１０に記載のシステム。
13. 基幹業務データ統合および対話形式操作システムであって、
    非記述的ソースデータを共通ビジネスセマンティックスにエイリアスし、技術情報を提供して、１つまたは複数の基幹業務アプリケーションの対話形式による操作を可能にするマップコンポーネントと、
    前記マップコンポーネントにより供給される情報を使用して、前記１つまたは複数のアプリケーションに接続し、クライアントアプリケーションクエリに対する応答としてデータを取り出す抽出システムとを備えることを特徴とする基幹業務データ統合および対話形式操作システム。
14. 前記マップコンポーネントは、基幹業務アプリケーションデータの操作を円滑にするため採用されることを特徴とする請求項１３に記載のシステム。
15. 前記抽出システムは、マップコンポーネント情報を使用して、データを取り出す前記アプリケーションに関連付けられた接続カートリッジコンポーネントを識別し採用することを特徴とする請求項１３に記載のシステム。
16. 前記マップコンポーネントは、データソースビューを使用することを特徴とする請求項１３に記載のシステム。
17. 請求項１３に記載の前記コンピュータ実行可能コンポーネントを格納していることを特徴とするコンピュータ可読媒体。
18. 基幹業務データを対話形式で操作するためのシステムであって、
    複雑なソースメタデータと共通のビジネスセマンティックスとの間のマッピングを行うための手段と、
    マッピングを使用して一連のビジネスソースデータをクライアントアプリケーションに公開するための手段とを備えることを特徴とするシステム。
19. さらに、システムインテグレータがデータモデルを公開する手段を備えることを特徴とする請求項１８に記載のシステム。
20. 前記マッピングは、システムインテグレータ展開を体系化するために使用されることを特徴とする請求項１８に記載のシステム。
21. さらに、異種の基幹業務技術を単一の実行プラットフォームにマッピングするための手段を備えることを特徴とする請求１８に記載のシステム。
22. データにアクセスする方法であって、
    難解なメタデータをビジネス分野の用語にマッピングするマップコンポーネントを生成することと、
    前記マップコンポーネントおよびそれによって識別される接続カートリッジコンポーネントを使用して基幹業務ソースからデータを抽出することとを含むことを特徴とする方法。
23. マップコンポーネントは、対話型ウィザードを使用してユーザにより生成されることを特徴とする請求項２２に記載の方法。
24. 前記マップコンポーネントは、データを単一の共通技術プラットフォームにマッピングすることを特徴とする請求項２２に記載の方法。
25. 前記マップコンポーネントは、ＸＳＬＴドキュメントであることを特徴とする請求項２２に記載の方法。
26. 前記マップコンポーネントは、データソースビューであることを特徴とする請求項２２に記載の方法。
27. 前記マップコンポーネントは、データモデルの選択されたオブジェクトに対するデータモデルアクセスサービスから返されたメタデータを使用して生成されることを特徴とする請求項２２に記載の方法。
28. 前記データモデルアクセスサービスは、公開された基幹業務データモデルのライブラリにアクセスするＷｅｂサービスであることを特徴とする請求項２７に記載の方法。
29. 請求項２２に記載の前記方法を実行するコンピュータ実行可能命令を格納していることを特徴とするコンピュータ可読媒体。
30. エンタープライズデータアクセス方法であって、
    企業資源データクライアントからデータの要求を受け取ることと、
    前記要求に対する応答としてデータマップにアクセスすることと、
    前記データマップに応じて少なくとも１つの異種データソースからデータを抽出することと、前記マップはわかりにくいソースメタデータを共通のビジネス用語にエイリアスすることによりデータをクライアントに公開することとを含むことを特徴とする方法。
31. データマップは、データを取り出すソースＳＤＫおよび／またはＡＰＩとインターフェイスするために使用することができる接続カートリッジを識別するプロトコルマッピング部分を含むことを特徴とする請求項３０に記載の方法。
32. 前記要求は、データプロバイダを介して前記データから受信されることを特徴とする請求項３０に記載の方法。
33. 前記データプロバイダは、ＡＤＯ．ＮＥＴであることを特徴とする請求項３２に記載の方法。
34. 前記マッピングコンポーネントは、複数の基幹業務データモデルからのデータモデルオブジェクトを含むことを特徴とする請求項３０に記載の方法。
35. 請求項３０に記載の前記方法を実行するコンピュータ実行可能命令を格納していることを特徴とするコンピュータ可読媒体。
36. エンタープライズデータアクセス方法であって、
    マップコンポーネント定義に従って複雑なアプリケーションメタデータを共通のビジネスセマンティックスにエイリアスするマッピングされたスキーマをデータプロバイダコンポーネントに提示することと、
    前記データプロバイダコンポーネントを介してクライアントからクエリを受け取ることと、
    前記マップコンポーネントにより提供される情報を使用してデータアクセスプロトコルを決定することと、
    少なくとも１つのエンタープライズソースからデータを取り出すことと含むことを特徴とする方法。
37. さらに、前記データプロバイダコンポーネントを介して結果を前記クライアントに返すことを含むことを特徴とする請求項３６に記載の方法。
38. 前記マップコンポーネントは、ウィザードを使用して定義されることを特徴とする請求項３６に記載の方法。
39. 前記ウィザードは、定義済みの基幹業務アプリケーションデータモデルをユーザに公開し、ユーザがカスタマイズされたデータモデルを定義する前記マッピングコンポーネントに含めるそれぞれのモデルに関連付けられているオブジェクトのうちから選択できるようにすることを特徴とする請求項３８に記載の方法。
40. 請求項３６に記載の前記方法を実行する前記コンピュータ実行可能命令を格納していることを特徴とするコンピュータ可読媒体。
    

Images