JP2005505048A - 統合オブジェクトを企業のビジネスアプリケーションと共に用いるための方法及びシステム - Google Patents

Abstract

企業ビジネスアプリケーションと共に統合オブジェクトを用いるための方法及びシステムが開示されている（図１）。本方法は、第１企業アプリケーション用の第１フォーマットを有する外部オブジェクト（１４０）を、第２企業アプリケーション（１１１）にインポートするステップと、統合オブジェクト（１２３）を使って第１フォーマットの外部オブジェクト（１４０）を、第２企業アプリケーション（１１１）用にフォーマットされた第２フォーマットの外部オブジェクトに変換するステップと、第２ビジネスアプリケーション内の第２フォーマットの外部オブジェクトを用いるステップとを含む。
【選択図】図１

Description

【技術分野】
【０００１】
本発明は、コンピュータシステムに関し、さらに詳しくは、統合オブジェクトを企業のビジネスアプリケーションと共に用いるための方法及びシステムに関するものである。
【背景技術】
【０００２】
或るオブザーバーによれば、現代の会社の活力が情報であるとすれば、その動脈は、会社企業を取り巻くデータを動き易くする「アプリケーション間インタフェース」である。これは、最近「アプリケーションネットワーク」として知られるようになっている。
【０００３】
一般的な組織のために、アプリケーションネットワークは、特別な（ad hoc）アプリケーション統合プログラムの集まりへと組織的に成長している。この異色の集合体は、新たなアプリケーションを実行する時間を増大させるので、ビジネスに非常に深刻な衝撃を与え、上級幹部が明確なビジネス像を描けないようにしてしまう。つまり、会社の動脈を詰まらせてしまうのである。競合会社がある中で生き残るためにアプリケーション統合が重要になってきたのは事実であるが、それにもかかわらず先行技術では、長期にわたって経費を会社に投資し、特別仕様のコード（custom code）を手作り（handcraft）又は「改変（hack）」することが許容されていた。同様に、長期のアプリケーション統合に関する決定が、個々のプロジェクトの規準だけに基づいた最低許容レベルで行われてきた。企業アプリケーション統合（ＥＡＩ）の効果的な解決法は、これらの問題の本質が決定的に困難であるが故にまだ見つかっていない。
【０００４】
インターネットの出現、クライアント／サーバー・コンピュータ化、会社の合併及び買収、グローバル化及びビジネスプロセスのリエンジニアリングは、時には手動で、あるシステムが相当の旧式であったとしても異なるシステムが互いに通信させる新たな方法を常に求めるために、会社の情報技術（ＩＴ）部門で力をあわせてきた。その結果生じた混乱の中、不適切な通信システムはＩＴの実行力が衰えビジネスが要求する速さで変化していった。
【０００５】
ＩＴの最近の傾向として、サポートするのに必要なアプリケーション間インタフェースの量が増大−しばしば膨大な量である−することでこの問題が悪化する一方である。ごく最近では、企業のアプリケーションは、データウェアハウス及びエンタープライズリソースプランニング（ＥＲＰ）ような機能を実行しており、電子商取引を容易にしている。したがってこれら３つの技術を簡潔に見直すことは冗長と感じてしまうかもしれないが、未だ解決されていない企業アプリケーション統合（ＥＡＩ）の必要性を理解することに役立つであろう。
【０００６】
データウェアハウス技術は、多くのオペレーションシステムからウェアハウス（倉庫）へ、定期的に移動されなければならない大量の真新しい履歴データを必要とする。ソースデータは、オンライントランザクション処理（ＯＬＴＰ）のために構築されるのが普通であり、一方で典型的なデータウェアハウスは、多次元分析処理（ＯＬＡＰ）フォーマットも備えている。したがって、ソースデータは、ウェアハウス（倉庫）へ移される際に、広範囲に集められ且つ再フォーマットにかけられなければならない。
【０００７】
先行技術に従う典型的なデータウェアハウスは、（ａ）ソースデータを抽出するステップ、（ｂ）その抽出されたデータをクリーニングするステップ、（ｃ）抽出されクリーニングされたデータを多次元で集めるステップ、（ｄ）ウェアハウスにロード（load）するステップ、の４つのステップで構成される。各ウェアハウスのソースは、特定データの抽出、クリーニング、集約、及びロードのルーチンを組立てる必要がある。フォレスター研究所によれば、平均的な大会社は約４つのデータウェアハウスを有していると推測している。２年以内に、この数が６に増えると予測されている。また、各ウェアハウスに含まれるデータの平均の量は、同じ２年以内に約１３０ギガバイトから約２６０ギガバイトへと量的に倍増すると予測される。
【０００８】
この様な大量のデータがこれまでの増加ペースで増大することに伴う問題は、ソースデータの質によって一層悪化する。ＭＥＴＡグループが行った研究によると、現在、典型的なデータウェアハウスにロードされるデータの２０％程度は劣悪な質のデータである。その回答者の約７０％は手作業によりコード化された抽出処理、先浄処理、及びロード処理を用いていたことがその同じ研究で示されている。要求された集約プロセスに関して、事例証拠は、この機能だけを完了するのに５０時間程度のコンピュータ時間が必要になる可能性があることを示している。この様なやり方でコーディングされたプログラムを維持するには相当な努力が必要になることが自明である。
【０００９】
一方、典型的なＥＲＰシステムは、基本的に大型の統合実装アプリケーションであり、給与計算（payroll）、製造、汎用の原簿、及び人的資源の核となるビジネス機能をサポートする。しかしながら、ＥＲＰシステムを実行することは、多くの理由で途方にくれる処理になり得る。
【００１０】
先ず最初に、会社は製品を購入するのであってソリューションを構築することはしない。これは、会社内の事業ユニットが、既存の他の方法ではなくその製品及びそれがどのように作用するかに適応しなければならないことを意味する。更に、今日のＥＲＰシステムは、会社における従来のソリューション全てを取り替えることはできない。このため、ＥＰＲシステムは、しかるべき所にある他の旧来のシステムと効率的に通信しなければならない。結局、１つのベンダーが組織のあらゆる需要を満足することができないのが普通なので、会社が１以上の完全に異なるＥＲＰシステムを採用することは珍しくはない。
【００１１】
その結果、データをＥＲＰシステムから出し入れするためのオプションが、データウェアハウスに用いられる既知のアプローチを妨げる。各ＥＲＰシステムは、そのベンダーによって継続的に拡張（エンハンス）される所有権のあるデータモデルを有している。そのようなモデルを操作する抽出ルーチン又はロードルーチンを記述することは複雑なだけでなく、データの妥当性及び企業アプリケーションに固有のビジネスルールが無視されがちなので、ベンダーによって遠慮させられる。代わりに、ＥＲＰはビジネスオブジェクトレベルでの相互作用を要求し、それは汎用の原簿、予算又は支払い勘定のような特定のビジネスエンティティを扱う。
【００１２】
各形態の電子商取引は、長年広く活用されてきた。基本的に、電子商取引は電子データ交換（ＥＤＩ）と共に開始した。ＥＤＩは、会社が購入注文及び請求書（invoice）を電子的に通信できるようにし、現在の会社がＥＤＩを使用してサプライチェーン管理を行うまでに発展を続けてきた。しかしながら、興味のある物を売買したりオークションしたりするのにごく最近のオンラインインターネットウェブサイトを爆発的に利用して初めて、頑強で効果的なＥＡＩのための緊急を要する必要性が存在していた。
【００１３】
限りある時間フレーム内で特定のビジネス目的を達成するようにアプリケーションが開発されてきている。典型的な大組織の場合、異なるチームの人々が、様々な種類のオペレーティングシステム、ＤＢＭＳ、及び開発ツールを使って、何百ものアプリケーションを開発している。それぞれの場合、他のアプリケーションとの統合を考慮せずに特定の要件を満たしている。
【００１４】
アプリケーション統合に関して、幾つかの力強い傾向が市場を動かしている。例えば、ピア・ツー・ピアネットワーキングと分散処理における顕著な展開は、事業にとって協働者及び供給者を統合するのと同様に、自己の機能的部門を良好に統合できるようにしている。また、前述したインターネット／「イントラネット」／「エクストラネット」の爆発的増加は、バックエンド（back-end）の旧式アプリケーションとの統合を必要とする新しいクラスの「ヒューマン・アクティブ」アプリケーションに対する要求を刺激している。
【００１５】
企業のアプリケーションソフトウェアパッケージ採用における世界的なすさまじい成長も、バックエンドの旧式アプリケーションとの統合を必要とする。結局、例えばＩＢＭのＭＱシリーズのメッセージキューイング（message queuing）のようなメッセージ指向ミドルウェア（ＭＯＭ）製品が徐々に普及してくるようになる。顧客がＭＯＭとの単純な１対１アプリケーション接続の利点を理解すると、多数対多数アプリケーション統合への関心が著しく増大することになる。
【００１６】
多数対多数アプリケーション統合（又は１対多数統合でも）に関してキーとなる問題は、全システムを接続するのに必要なデータ変換の数が極めて大きいことである。これは、システム数の二乗にオブジェクトタイプの数を掛けた程の大きさである。この問題を扱い易くするためには、オブジェクトの意味翻訳を形式翻訳と分離する方法を有し、その形式翻訳を実行するメタデータ駆動のツールを有することが望ましい。
【００１７】
急速に変化する現在の環境において、世界中の多数の開発者は、カスタマイズされた複数のアプリケーション特有の翻訳スキームを埋め込む必要なく、本質的に異なるアプリケーションが互いに通信できる必要性を満たすシステムを開発することに努力を集中している。これはいまだ未解決な必要性として世界経済の緊急の課題に置かれている。
【００１８】
本出願は、Ｊｅｆｆｒｅｙ Ｍｉｃｈａｅｌ Ｆｉｓｃｈｅｒ及びＭａｒｋ Ｃｏｙｌｅによる２００１年４月１４日出願の米国仮特許出願第６０／２８３，７６５号「統合オブジェクト」の出願日に関する恩典を請求する。
【００１９】
（発明の詳細な説明）
統合オブジェクトを企業ビジネスアプリケーションと共に用いるための方法及びシステムが開示されている。或る実施形態では、本方法は、第１企業アプリケーション用の第１フォーマットを有する外部オブジェクトを第２企業アプリケーションに取り込む（import）するステップと、統合オブジェクトを使って第１フォーマットの外部オブジェクトを、第２企業アプリケーション用にフォーマットされた第２フォーマットの外部オブジェクトに変換するステップと、第２ビジネスアプリケーション内の第２フォーマットの外部オブジェクトを用いるステップとを含む。
【００２０】
以下の説明では、分かり易くする目的で、本発明が完全に理解できるように特定の専門用語を使っている。しかしながら、本発明を実行するためにこれら特定用語の詳細が不要であることは当業者であれば明白であろう。
【００２１】
以下の詳細な説明の幾つかの部分は、アルゴリズムの用語と、コンピュータメモリ内のデータビットを操作する記号表示とで示されている。これらのアルゴリズムの説明及び表現は、データ処理分野の当業者が作業の内容を別の当業者に最も効果的に伝えるために用いられる手段である。アルゴリズムは、ここではそして一般的には、所望の結果に到る自己矛盾のない一連のステップであると考えられている。前記ステップは、物理量の物理的操作を要求するものである。通常、必ずというわけではないが、これらの量は、記憶、移動、組み合わせ、比較、或いは操作され得る電気又は電磁の信号形態をとる。主として一般的な使用のために、これらの信号は、ビット、値、要素、記号、文字、用語、数などとして引用されることが好都合であると分かっている。
【００２２】
しかしながら、これらの用語や同様の用語のすべては、適切な物理量と関連付けられているとともに、これら物理量に適用される単に都合の良いラベルであると理解されるべきである。以下の議論から明白なように、他に特定して述べていなければ、「処理」、「計算」、「演算」、「決定」、又は「表示」などの用語を用いた内容は、コンピュータシステム又は同様な電子計算装置に関する動作及び処理を言及し、物理（電子）量で示されるコンピュータシステムのレジスタ及びメモリ内のデータを、同様に物理量として示されるコンピュータシステムのメモリ若しくはレジスタ、又は情報記憶装置、伝送装置、若しくは表示装置等の別の装置内の他のデータに変換し且つ操作する。
【００２３】
また、本発明は、ここでの働き（オペーレーション）を実行するための装置にも関係している。要求された目的のためにこの装置が特別に構成されるようにしてもよいし、又はコンピュータに記憶されたコンピュータプログラムによって選択的に起動又は再構成される汎用コンピュータを備えていてもよい。そのようなコンピュータプログラムは、限定するわけではないが、フロッピー（登録商標）ディスク、光ディスク、ＣＤ−ＲＯＭ、磁気光ディスクを含む何れかの種類のディスク、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気若しくは光カード、又は電子命令を記憶するのに適し、かつそれぞれがコンピュータシステムバスに連結される何れかの種類の媒体等のコンピュータ読み出し可能な記憶媒体内に記憶されることができる。
【００２４】
ここで提示されるアルゴリズム及び表示は、本来的に特定のコンピュータ又は他の装置に関係付けられているものではない。様々な汎用システムを、ここでの教示に関するプログラムと共に用いることができたり、又は要求された方法のステップを実行するために更に特別の装置を構築することが好ましいことが分かっている。様々なこれらのシステムに要求される構造は、以下の説明から明らかになるだろう。加えて、本発明は何れかの特別なプログラム言語を引用して記載されてはいない。ここで記載したように様々なプログラミング言語が本発明の内容を実行するために用いられ得ることを認識されたい。
【００２５】
図１は、統合オブジェクトを実行するシステム１００のブロック図を示す。システム１００は、関連アプリケーション環境１１０を含んでいる。関連アプリケーション環境１１０は、２つの異なる企業アプリケーションシステムがデータを共有できるようにする。例えば、或る会社が或る基本的な企業アプリケーションシステム（基本システム）を使用し、かつその会社のサプライヤーが別の外部企業アプリケーションシステム（外部システム）を使用している場合、環境１１０は、前記外部システムからの企業データが前記基本システムに基本システムの特定フォーマットでアクセスできることを許可する。
【００２６】
環境１１０内には２つの要素がある。アプリケーション１１１は環境１１０の能力を提供し、外部統合インタフェース１４１を介して外部システム１４０とインタフェースする。第２の要素は、関連データベース１２０である。
【００２７】
アプリケーション１１１は、外部アプリケーションアダプタ１１６を備えている。外部アプリケーションアダプタ１１６は、インタフェース１４１のような外部統合インタフェースと通信する。アダプタ１１６は、外部データオブジェクトの意味を失うことなく、外部システム１４０のデータオブジェクトのローカル表現を作り出す。このローカル表現は、データ変換アダプタ１１５に送られる。外部システム１４０からもたらされたローカル表現内のフィールド名は、外部システム１４０のデータオブジェクトの共通表現を作成するため、環境１１０の命名取り決めに応じて名称変更される。更に、環境１４０と環境１１０のオブジェクト構造間の有意な差異は、前記データ変換アダプタによって解決される。前記共通表現が、内部アプリケーションアダプタ１１４に送られる。内部アプリケーションアダプタ１１４は、内部オブジェクト層１１３と直接通信する。
【００２８】
オブジェクト層１１３は、内部アプリケーションアダプタ１１４からの共通表現を受信し、それは環境１１０と十分に統合可能である。この共通表現は、オブジェクト層１１３によって、関連データベース１２０内にオブジェクトとして記憶される。ユーザインタフェース１１２はオブジェクト層１１３の上に存在し、データを表示する。また、ウェブサーバー１５０を介してウェブブラウザ１５１によりそのデータを表示することもできる。
【００２９】
関連データベース１２０は、アプリケーションテーブル１２１及びリポジトリテーブル１２２を備えている。アプリケーションテーブル１２１は、会計、注文、又は連絡情報等の実際のデータを含んでいる。リポジトリテーブル１２２は、統合オブジェクト１２３及びビジネスオブジェクトも同様に含んでいる。統合オブジェクト１２３は、外部システム１４０の外部データオブジェクトのフォーマットを記述したメタデータであり、外部リポジトリ１３０内に記憶されることができる。リポジトリテーブル１２２は、アプリケーションによって使用される他の構造と同様に統合オブジェクトを含みながら、アプリケーションテーブル１２１のフォーマットを記述したメタデータである。
【００３０】
統合オブジェクト１２３はアダプタ１１４〜１１６へ送られ、各アダプタは環境１１０内に外部データオブジェクトを統合するため、外部オブジェクト定義を読み出す。アプリケーション１１１は、リポジトリテーブル１２２からの静的な構成データを、アプリケーションテーブル１２１内に入っている動的データと併合しかつ統合することによって、ブラウザ１５１を通してユーザが見るものを生成する。例えば、アプリケーション１１１は、ＨＭＴＬコードを構築しブラウザ１５１を介して閲覧されるウェブサーバー１５０へ提供する。ウェブページは、コールセンターアプリケーション用の会計情報及びデータフィールドを表示することができる。この表示される情報は、データが閲覧される企業アプリケーションとは異なる企業アプリケーションからのものであってもよい。
【００３１】
前述しシステム１００のフレームワークは、ユーザがプログラミングコードを書いたり、又はそれをするコンサルタントを雇うことなく、異なるデータフォーマットを有する複数のビジネスシステムを統合することを許可する。アダプタ１１４〜１１６は、交換可能な構成要素として統合オブジェクト１２３を使用し、その結果、アダプタ１１４〜１１６が再利用され得る。環境１１０は、統合オブジェクト１２３を使って自己のオブジェクト定義をエクスポート（export）することもでき、その結果、外部システム１４０は、環境１１０のデータオブジェクトを統合することもできる。更に、環境１１０は、（外部リポジトリ１３０内に在る場合）外部システム１４０のオブジェクト定義を取り出し、それを使って外部システム１４０のデータオブジェクトを統合することもできる。
【００３２】
図２は、本発明の或る実施形態に従ったデータ統合システム２００の高レベルのブロック図である。外部スキームのデータオブジェクトは外部リポジトリ２１０内にある。リポジトリ２１０は、それ自身のフォーマットスキームリポジトリ２１０内に、外部データオブジェクトを記述した外部統合オブジェクト定義が入っている。リポジトリ２１０は、統合オブジェクトウィザード２２０によってアクセス可能である。ウィザード２２０は、リポジトリ２１０からオブジェクト定義を抽出し、かつ局所（ローカル）化された統合オブジェクト２３０を生成する。
【００３３】
ウィザード２２０は、アプリケーション１１１を実行するユーザ対話型ソフトウェアを表している。図２は、外部リポジトリ２１０からオブジェクト定義を読み出すとともに、統合オブジェクト２３０を生成する前記ウィザード２２０の機能を示している。統合オブジェクトは、アダプタ２６０によって処理された外部表現と、統合オブジェクトインスタンス２４０と、ＸＭＬ文書２５０との間のマッピングを宣言的に定義する。表１は、統合オブジェクト定義を記憶するためのデータベーススキーマの一実施形態を示すが、この他にも本発明の概念及び範囲内で実現でき考えられる実施方式はある。
【００３４】
（表１）

【００３５】
統合オブジェクト２３０は、命名されかつ分類されたフィールドを含む「構成要素」より構成される。統合オブジェクトの構成要素は互いに親子関係にある。統合構成要素及びそれらのフィールドは、リポジトリ内の他の物理的構成要素とリンク付けられることができる。物理的オブジェクトに統合構成要素をリンクすることは、オブジェクトを外部システムと交換するときに利用するための標準的な表現をアダプタ１１４〜１１６のために提供する。例えば、統合オブジェクト２３０の構成要素がテーブルの定義とリンクされる場合、アダプタ１１４〜１１６は、その出力データを同じ定義を有するテーブル又は別のテーブルに配置することができる。アダプタ１１４〜１１６は、（統合オブジェクト定義内で参照された表を直接利用しない場合、）外部システムに統合オブジェクトの型式と、統合構成要素から実際のステージングテーブル（staging table）へのマッピングとを提供する。統合オブジェクトの標準的な内部メモリ表現が同様に生じる。
【００３６】
統合構成要素の定義のそれぞれは、親への外部キーだけでなく独自のキーも含んでいる。これらのキーは、複数のフィールドを含んでいてもよいし重複していてもよい。表２は、統合構成要素の定義を記憶するためのデータベーススキーマの一実施形態を示しているが、この他にも本発明の概念及び範囲内で実現でき考えられる実施方式はある。
【００３７】
（表２）

【００３８】
テーブルが複数の構成要素を含み、かつそれぞれの行が唯１つの構成要素に属している非正規化テーブル（表）には、正規化された論理表現が提供される。リポジトリ２１０は、非正規化テーブルの最上段に正規化されたオブジェクトを示している。
【００３９】
統合オブジェクト定義のレベルが図２に示されている。３つのレベルは、統合オブジェクト定義２３１、統合構成要素定義２３２、統合構成要素フィールド定義２３３である。統合オブジェクト定義２３１は、データオブジェクトを外部システムの表現とローカルシステムの表現との間でマップする。図２に示すように、各定義レベルは、標準セクションとして３つのセクションから構成される。即ち、ローカルシステムが理解できるデータオブジェクトを記述する規範セクションと、外部システムが理解できるデータオブジェクトを記述する外部セクションと、さらに標準化されたフォーマットでデータオブジェクトを記述するＸＭＬセクションである。ＸＭＬと説明したが、ＸＭＬと同様の他のマークアップ言語も、本実施形態の範囲内にあるとみなされる。
【００４０】
統合オブジェクト定義の第２レベルは、統合構成要素定義レベル２３２である。このレベルは、スカラーフィールドの集合を一緒にグループ分けしている。統合オブジェクト内の構成要素型式の集合は、ある「ルート」構成要素によって階層的に配置される。オブジェクトインスタンスの中には、各構成要素の型式に関する多くのインスタンスが存在し得る。統合オブジェクト定義の第３レベルは、統合構成要素フィールド定義２３３である。フィールドは、ストリング、数、又は日付等の単純なスカラー値を定義する。表３は、統合構成要素フィールド定義を記憶するためのデータベーススキーマの一実施形態を示しているが、この他にも本発明の概念及び範囲内で実現でき考えられる実施方式はある。
（表３）

【００４１】
必要であれば、フィールドレベル２３３は、スカラー値の標準表現と外部表現との間でフィールド名称マッピングを提供する。統合構成要素のインスタンス内で、所与のフィールドインスタンスが一度だけ出現する。
【００４２】
統合オブジェクト２３０の標準セクションと外部セクションを用いて、アダプタ２６０は、外部システムのインスタンス表現と統合オブジェクトインスタンス２４０の間でマップすることができる。統合オブジェクト２３０のＸＭＬセクションを利用して、ＸＭＬページ２５０を作成することができる。アダプタ２６０は、アダプタ１１６のような外部アダプタでもよいし、アダプタ１１４のような内部アダプタでもよい。
【００４３】
図３は、統合オブジェクト３３０と統合オブジェクトインスタンス３４０の間の差異を示している。一般的に、統合オブジェクト３３０はメタデータで、即ち、特定のデータ集合の一般化された表現又はモデルである。図３に示したように、統合オブジェクトインスタンスは、統合オブジェクト３３０のフォーマット又は構造で編成された実際のデータである。
【００４４】
図４は、本発明の一実施形態に従ったウィザード２２０を用いて統合オブジェクトを構築するための典型的なユーザインタフェース４００を示している。ライン（line）４１０で、新規又は既存のプロジェクトが指定される。ライン４２０で、ベース（ソース）システムとインタフェースするためのビジネスアプリケーションが選択される。次に、ユーザは、ライン４３０で生成される新規の統合オブジェクトのためにモデル化されるであろうソースオブジェクトを選択する。ライン４４０で、ユーザは新規統合オブジェクト用の固有の名称を入力する。同様のユーザインタフェースが構成要素の選択のために用いられ、２つのシステムの間で転送される。また、各構成要素の全ての子に対するアクセスもあり、しれは選択されたり又は選択されなかったりする。
【００４５】
リポジトリメタデータの変更は珍しいことではなく、そして統合オブジェクト定義が外部オブジェクト表現の実際の構造と一致しない場合は、実行時に問題を引き起こす可能性がある。これらの問題を回避するためには、統合オブジェクト定義を、変更の可能性のある外部オブジェクト定義と「同期化させる」ツールを有することが望ましい。図５Ａと５Ｂは、このツールの考えられる一実施形態を示している。
【００４６】
図５Ａは、統合オブジェクトの代表的な同期ダイアグラム５００を示している。図５Ａは、２つの統合オブジェクトを含む。統合オブジェクト５１０は、新規の内部メモリ統合オブジェクトである。統合オブジェクト５２０は、データベース内に記憶された既存の統合オブジェクトである。ダイアグラム５００は、多数の構成要素を備えた新規のビジネスオブジェクト５１０を示す。ダイアグラム５００に示すように、同期化のために対応するボックスのクリックによって各構成要素が選択される。既存オブジェクト５２０と新規オブジェクト５１０間の差異は、構成要素５１１（ビジネスアドレス）及び構成要素５１２（機会）に関して顕著である。この様に、ビジネスアドレス構成要素５１１及び機会構成要素５１２は、既存の統合オブジェクト５２０に加えられる新規の構成要素である。図５Ｂは、同期化された統合オブジェクト５５０を示している。構成要素「接触」５６０とその全ての子が更新されている。構成要素「ビジネスアドレス」５５１は、構成要素「機会」５５２と同様に新規である。また、同期化の構成要素として選択されなければ、構成要素は削除される。
【００４７】
図６は、統合された多重プロセッサを表わすコンピュータシステム６００を示し、そこでは本発明の要素が実行され得る。例えば、システム６００は、サーバー１５０のアーキテクチャでもよいし、又は環境１１０が存在するハードウェアであってもよい。コンピュータシステム６００の一実施形態は、情報を伝達するためのシステムバス６２０と、バス６２０に連結されている情報を処理するためのプロセッサ６１０とを備えている。さらに、コンピュータシステム６００は、バス６２０に連結されたランダムアクセスメモリ（ＲＡＭ）、又は（ここではメインメモリとして引用された）他の動的記憶装置６２５を備え、プロセッサ６１０により実行される情報及び命令を記憶する。
【００４８】
また、メインメモリ６２５は、プロセッサ６１０が命令を実行する間に、一時的な変数又は他の中間情報を記憶するために用いられる。また、コンピュータシステム６００は、プロセッサ６１０が使用する静的情報及び命令を記憶するバス６２０に連結された読み出し専用メモリ（ＲＯＭ）及び／又は他の静的記憶装置６２６を含む。環境１１０は、リポジトリ１３０が記憶装置６２７で実行されるシステム６００内に実装される。アダプタ１１４〜１１６とリポジトリテーブル間の通信は、バス６２０を介して行われるのが普通である。ブラウザインタフェースは、表示装置６４３上に示される。
【００４９】
また、磁気ディスク又は光ディスク等のデータ記憶装置６２７とそれに対応する装置は、情報及び命令を記憶するコンピュータシステム６００に連結されることができる。コンピュータシステム６００は、Ｉ／Ｏインタフェース６３０を介して、第２のＩ／Ｏバス６５０に連結することもできる。表示装置６４３、入力装置（例えば英数字入力装置６４２及び／又はカーソル制御装置６４１）を含め、複数のＩ／Ｏ装置を１／Ｏバス６５０に連結することができる。
【００５０】
通信装置６４０は、ネットワークを介して他のコンピュータ（サーバー又はクライアント）にアクセスするための装置である。通信装置６４０は、モデム、ネットワークインタフェースカード、又はイーサネット（登録商標）、トークンリング、若しくは他の型式のネットワークに連結するのに用いられる他の周知のインタフェース装置を備えている。
【００５１】
図７は、統合オブジェクトを企業ビジネスアプリケーションと共に用いる方法の高いレベルのフローチャート７００を示している。このプロセスは処理７０１で始まり、フローは処理ブロック７０２へ続く。ユーザは、統合対象のアプリケーションに関連する内部及び外部インタフェースの型式を選択する。
【００５２】
フローは、処理ブロック７０３へ続き、ここでウィザード２２０を使って、外部アプリケーションのビジネスオブジェクトのための新規の統合オブジェクトを作成する。処理ブロック７０４で、必要であれば新規の統合オブジェクトが修正される。例えば、フィールド名称又は関係が変更される。
【００５３】
処理ブロック７０５では、ウィザード２２０を実行してローカルアプリケーション用の統合オブジェクトを作成する。これらのローカル統合オブジェクトは、ローカルデータオブジェクトを外部システムにエクスポートできるようにする。フローは、処理ブロック７０６へ続き、前述したように、ここでユーザは新規のローカルデータオブジェクトを修正する。
【００５４】
フローは、処理ブロック７０７へ続き、ここでデータマップを書き込む。データマップは、外部及び内部インタフェースの何れが、内部及び外部両方の新規の統合オブジェクと対応するかを示す。処理ブロック７０８では、ユーザを介することなく内部及び外部両方のオブジェクトを統合する。フローはブロック７０９で完了する。
【００５５】
統合オブジェクトを企業のビジネスアプリケーションと共に使用する方法及びシステムを開示した。本発明を特定の例とサブシステムに関して説明してきたが、本発明がこれら特定の例又はサブシステムに限定されるものではなく、他の実施形態にも拡張されることは当業者であれば自明であろう。本発明は、特許請求の範囲で特定されるようにこれら他の実施形態の全てを含むものである。
【００５６】
添付図面は本発明の明細書の一部を成して本発明の好適な実施形態を示し、前記本発明の一般的な記述及び本発明の詳細な記述と共に本発明の原理を説明し教示する役目を果たす。
【図面の簡単な説明】
【００５７】
【図１】統合オブジェクトを実行するシステム１００のブロック図である。
【図２】本発明の一実施形態によるデータ統合システム２００の高いレベルでのブロック図である。
【図３】統合オブジェクト３３０と統合オブジェクトインスタンス３４０の間の相違を示す図である。
【図４】本発明の一実施形態に従いウィザード２２０を使って統合オブジェクトを構築する代表的なユーザインタフェース４００を示す図である。
【図５Ａ】統合オブジェクトの典型的な同期ダイアグラム５００を示す図である。
【図５Ｂ】同期された統合オブジェクト５５０を示す図である。
【図６】統合された多重プロセッサを表すコンピュータシステム３００を示す図であり、本発明の要素がここで実行される。
【図７】企業ビジネスアプリケーションと共に統合オブジェクトを用いる方法の高いレベルでのフローチャート７００を示す図である。

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