JP3887564B2 - 統合型データベース結合システム - Google Patents
統合型データベース結合システム Download PDFInfo
- Publication number
- JP3887564B2 JP3887564B2 JP2001530749A JP2001530749A JP3887564B2 JP 3887564 B2 JP3887564 B2 JP 3887564B2 JP 2001530749 A JP2001530749 A JP 2001530749A JP 2001530749 A JP2001530749 A JP 2001530749A JP 3887564 B2 JP3887564 B2 JP 3887564B2
- Authority
- JP
- Japan
- Prior art keywords
- database system
- computer
- data
- stored
- primary key
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 claims abstract description 67
- 238000013507 mapping Methods 0.000 claims abstract description 37
- 238000003860 storage Methods 0.000 claims abstract description 28
- 230000008569 process Effects 0.000 claims description 18
- 230000004044 response Effects 0.000 claims description 8
- 238000004590 computer program Methods 0.000 abstract 2
- 230000005540 biological transmission Effects 0.000 description 45
- 230000006870 function Effects 0.000 description 35
- 230000008859 change Effects 0.000 description 31
- 238000012545 processing Methods 0.000 description 28
- 239000003795 chemical substances by application Substances 0.000 description 24
- 238000010586 diagram Methods 0.000 description 24
- 238000000605 extraction Methods 0.000 description 15
- 230000010076 replication Effects 0.000 description 14
- 238000004422 calculation algorithm Methods 0.000 description 13
- 230000010354 integration Effects 0.000 description 11
- 230000009471 action Effects 0.000 description 8
- 230000004927 fusion Effects 0.000 description 8
- 238000004891 communication Methods 0.000 description 7
- 238000012790 confirmation Methods 0.000 description 6
- 230000001419 dependent effect Effects 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 5
- 238000007726 management method Methods 0.000 description 4
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 238000001914 filtration Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000002085 persistent effect Effects 0.000 description 3
- 239000011232 storage material Substances 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 238000009826 distribution Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 230000008676 import Effects 0.000 description 2
- 239000000047 product Substances 0.000 description 2
- 238000012384 transportation and delivery Methods 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000009365 direct transmission Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 230000009469 supplementation Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/25—Integrating or interfacing systems involving database management systems
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99942—Manipulating data structure, e.g. compression, compaction, compilation
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Vehicle Body Suspensions (AREA)
- Error Detection And Correction (AREA)
- Steering-Linkage Mechanisms And Four-Wheel Steering (AREA)
- Credit Cards Or The Like (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Storage Device Security (AREA)
- Optical Communication System (AREA)
- Iron Core Of Rotating Electric Machines (AREA)
- Measuring Pulse, Heart Rate, Blood Pressure Or Blood Flow (AREA)
Description
本発明は、構造的に互換性のない種々のデータベースシステムの統合に関する。
【0002】
データベースシステムは電子データ処理の数多くの適用事例において大きな役割を果たしている。
【0003】
それらのデータベースシステムは通常、本来のデータベース(データバンク)とデータベース管理システムによって構成されている。そしてそれらは、データベースに格納されているデータが多種多様に処理されるような広範囲に及ぶコンピュータアプリケーションの基礎を成すことが多い。
【0004】
企業EDPの分野において重要な実例はいわゆるERP(Enterprise Resource Planning)システムであり、たとえばドイツ連邦共和国 Walldorf のSAP 社による OLTP-R/3 などである。それらによって人事や販売や在庫管理など様々な企業分野におけるEDP支援を、1つの共通の中央データベースに基づき実現することができる。この種のシステムはバックオフィスシステムと呼ばれることが多い。
【0005】
データベースシステムの別の重要な実例はカスタマサポートシステムであり、それらはしばしばSFA(Sales Force Automation)またはCRM(Customer Relation Management)システムと呼ばれる。この種のシステムは殊に、カスタマアドバイス、カスタマサポートならびに販売におけるEDP要求に合わせてカスタマイズされている。これには、企業の外勤従業員にポータブルコンピュータを装備させ、このコンピュータによりデータベースシステムのモバイルクライアント(mobile client)として、個々の外勤従業員が必要とするデータ(たとえばその従業員の地区のカスタマに関するデータやその従業員の販売状況に関するデータ)をもつ固有のローカルデータベースが提供される。このようなシステム(フロントオフィスシステムと呼ばれることが多い)には、やはりデータベースを有する中央コンピュータが含まれており、そのデータベースにはモバイルクライアントのデータの総計が格納されている。つまりこれはオフライン分散型データベースシステムである。モバイルクライアントのほかにCRMシステムの中央コンピュータとは他の外部のシステムも通信を行うことができ、たとえばカスタマのEDPシステムなどがそれを行うことができ、このシステムは一時的にまたは定常的なデータコネクションを介して中央コンピュータに接続される。
【0006】
慣用のバックオフィスシステムも慣用のフロントオフィスシステムも非常に複雑である。それらのシステムのためには様々なコンポーネント間の通信能力、データ保全性およびデータの同期を確保するためにパワフルな方法がそれぞれ必要とされ、その際、著しく多くのユーザ数を通信に含めることができるよう考慮しなければならない。
【0007】
先に挙げた形式の大規模なシステムについて広範囲にわたりこの問題が解決されている一方で、構造的に互換性はないがかなりの部分で同じ(業務)データを管理しているデータベースシステムを互いに融合させる確かな方法はまだない。たとえばERPシステムでは通常、企業のカスタマに関する大規模なデータセット(たとえば住所、仲介者、処理されたオーダや仕入れ状況に関するデータなど、また、補充交換部品納入に重要なカスタマのマシン装備に関するデータなど)が格納されている。広範囲にわたり一致しているデータセットはCRMシステムにおいても必要とされる。しかし実際には両方のシステムは、相互に互換性のないまったく異なるデータ構造をもっている。
【0008】
たとえば価格決定(pricing)は、種々のアプリケーションにおいてEDPサポートを受けて実行されるタスクである。(たとえば原価、個数、運搬費、および場合によっては特別な条件を考慮した)一貫した業務の流れが基礎を成しているにもかかわらず、種々のデータベースシステムへの実装は完全に異なっていることがよくあり、つまり業務処理のインプリメントに利用されるアルゴリズム(いわゆるビジネスロジック "Businesslogik")は非常に異なっている。とはいえ当然ながら、価格決定を種々異なるシステムにおいてできりかぎり等しく取り扱えるようにして同じ結果が得られるようにする必要がある。
【0009】
本発明の課題は、構造的に互換性のないデータベースシステムを、双方向で問題なくデータ交換できるよう相互に融合することである。ここでシステムの「融合」とは、技術レベルでの結合を超えて、データ同期を実現し、それぞれ異なるシステムにおいてほぼ同じ動作が得られるような制御ロジックの交換を可能とすることである。複数のサブシステムから成る統合された1つの結合システムへのこのような融合を、ここではセマンティック・システムインテグレーション("semantic system integration")と称する。このためにはたとえば、
−システムの確実な技術的結合
−融合されたシステムにおける有効データの同期合わせ
−融合されたシステムをコントロールするためのカスタマ固有の整合(カスタマイズデータ)の同期合わせ
−データ変更の食い違いや他のデータ不一致が発生したときの適切なコンフリクト解消法
が必要とされる。
【0010】
オンラインでもオフラインでも安定したコネクションを形成するため、実証済みのハードウェアテクノロジーおよびソフトウェアテクノロジーを利用することができる。この場合、キューメカニズムが重要な役割を果たし、これによれば各データ単位が正確に1回で伝送され(guaranteed delivery)、データが精確に決められた順序で伝送されるようになる(In-Order-Processing)。セマンティックなシステム統合のこのような部分的な観点については詳しく説明する必要はない。
【0011】
これに対し、前述の他の要求の実現のためには非常に難しい問題点があり、殊に一般に出発点となり得るのは、様々なデータベースシステムがソフトウェア製品の様々な「世界」に属する可能性のあることである。本発明の課題は、このような問題点を解決するシステムコンポーネントおよび方法を提供することである。
【0012】
種々のデータベースシステムのデータモジュールはそれぞれ異なっている。したがってそれらのデータ構造を相互にマッピングしなければならない。しかもデータ内容の整合が必要とされる(たとえば用語の使い方としてあるシステムの「カスタマ customer」は別のシステムでは「バイヤ buyer」に対応している)。これら両方の機能は、互換性のない2つのシステム間のデータ交換においてスタンダードな役割設定である。慣用のシステム統合はこのような形式のコネクションに関するものである。これによれば、統合システム全体において有効でなければならないデータの新たなエントリを、複数のシステムのうち中央システムと称する1つのシステムにおいてのみ、データベース結合システム全体に対して有効に実施することができる。しかしこのことは多くの事例において、たとえばCRMシステムとERPシステムとの融合においては不十分である。なぜならばその場合、重要な新たなデータは企業のヘッドオフィスにおいても(つまりERPシステムにおいても)カスタマサポートにおいても(つまりCRMシステムにおいても)生じるものであり、新たに取り込まれた後には結合システム全体で利用できなければならないからである。
【0013】
システムを超えてクロスシステムないしはシステムワイドに供給されるデータの新たなエントリを結合システムの各サブシステムにおいて実行できるようにしようという場合(つまり新たなエントリ実行後にけつごうしすてむのすべてのサブシステムにおいて利用できるようにしようという場合)、そのためにはいかなる時点でもデータオブジェクト識別のためシステムを超えて一義的なプライマリキーを利用できるようにしなければならない。その際、このようなプライマリキーを数値範囲の割り当てやGUID(Global Unified Identifier)キーの割り当てによって生成することが知られている。とはいえこれら両方のやり方は汎用的に利用できるものではない。
【0014】
数値範囲の割り当てのためには、関与するデータベースシステムにおいてキーを生成するために同じアルゴリズムが必要とされる。このことはそれぞれ異なるメーカのシステムにおいて保証することはできない。また、同じメーカの種々のシステムであっても、様々なキー生成手順の実装されていることが多い。
【0015】
また、GUIDを用いた一義的なキーの生成を利用できるのは、関与しているすべてのシステムがGUID手順を利用しているときだけである。このこともやはり多くの事例において保証できないことである。
【0016】
本発明の第1の観点によれば、このことから生じる問題点を解決するため、2つのデータベースシステムAとBとの間でデータを交換するための以下のような方法が提案される。すなわちこの方法によれば、データベースシステムの各々は、格納されているデータオブジェクトの一義的な識別のため、各データオブジェクトごとにプライマリキー生成ロジックを用いてシステム固有のプライマリキーを生成し、両方のデータベースシステムAおよびBのプライマリキー生成ロジックは互いに独立している。ここにおいて、ソースデータベースシステムAからターゲットデータベースシステムBへ伝送されるデータオブジェクトについて、システムを超えてクロスシステムで共有される新しいエントリに必要とされる一義的な識別を可能にするため、
a)ソースデータベースシステムAからターゲットデータベースシステムBへ伝送すべきデータオブジェクトのプライマリキーをキーマッピングテーブルと比較するステップを実行し、該キーマッピングテーブルは、すでに2つのプライマリキーの生成されているすべてのデータオブジェクトのプライマリキーを有しており、
b)プライマリキーが前記キーマッピングテーブル内にまだ存在していなければ、自動的にターゲットデータベースシステムBのプライマリキーを生成してデータオブジェクト内に格納し、ソースデータベースシステムAのプライマリキーといっしょに前記キーマッピングテーブルに格納するステップと、
c)ソースデータベースシステムAのプライマリキーが前記キーマッピングテーブル内で見つけられたならば、ターゲットシステムBの対応するプライマリキーをデータオブジェクトに格納するステップを実行する。
【0017】
これによれば、関与しているデータベースシステムが固有のプライマリキー生成ロジックを使用しており、それらのロジックが互いにチューニングされていないような事例であっても、システムを超えて一義的なプライマリキーの生成(つまりはシステムを超えて共有される新たなエントリの実行)が実現される。この場合、関与しているシステムの制御データメモリ(レポジトリ)内にキーロジックが定義される。また、キージェネレータを用いて両方のロジックが互いにマッピングされる。
【0018】
第2の観点によれば本発明は、第1のデータベースシステムA内のデータセットにおいて実行された変更に基づき第2のデータベースシステムB内のデータセットを更新する方法に関する。この場合、第1のデータベースシステムAのデータセットは、第2のデータベースシステムBには関連しないデータも、第2のデータベースシステムBに関連するデータも有しており、各データベースシステムにおけるデータを、それぞれシステム固有のプライマリキーを有するデータオブジェクトのかたちで処理し、該データを第2のデータベースシステムBにおいて両方のシステム固有のプライマリキーとともに格納する。この場合、以下のステップの少なくとも一部分が実行される。すなわち、
a)第2のデータベースシステムBには関連しないデータDR/3をデータオブジェクトから分離するステップと、
b)第1のデータベースシステムAから第2のデータベースシステムBへデータオブジェクトを転送するステップと、
c)データベースシステムBに固有のキーを生成し、生成されたキーをデータオブジェクトに追加するステップと、
d)生じたデータオブジェクトを第2のデータベースシステムBの格納ルーチンに組み込み、該データオブジェクト中に含まれているデータを第2のデータベースシステムBのデータベースに格納するステップの少なくとも一部を実行する。有利にはすべてのステップa)〜d)が実行される。
【0019】
さらに別の観点によれば本発明は、第2のデータベースシステムB内のデータセットにおいて実行された変更に基づき第1のデータベースシステムA内のデータセットを更新する方法に関する。これによれば第2のデータベースシステムBのデータセットは、第1のデータベースシステムAに関連しないデータも第1のデータベースシステムAに関連するデータも有しており、各データベースシステムにおけるデータをデータオブジェクトのかたちで処理し、該データオブジェクトはそれぞれシステム固有のプライマリキーを有しており、第1のデータベースシステムA内のデータをそのシステム固有のプライマリキーとのみいっしょに格納する。この場合、以下のステップの少なくとも1つが実行される。すなわち、
a)第1のデータベースシステムAに関連しないデータDMSをデータオブジェクトから分離し、該データを第2のデータベースシステムB内に保管するステップと、
b)前記データオブジェクトを第2のデータベースシステムBから第1のデータベースシステムAへ転送するステップと、
c)第2のデータベースシステムBのためのシステム固有のキーを前記データオブジェクトから分離し、該キーを第1のデータベースシステムAに保管するステップと、
d)生じたデータオブジェクトを第1のデータベースシステムAの格納ルーチンに取り込み、該データオブジェクトに含まれているデータを第1のデータベースシステムAのデータベースに格納するステップの少なくとも一部を実行する。有利にはすべてのステップa)〜d)が実行される。
【0020】
本発明のさらに別の観点によれば、複数のデータベースシステムを有する統合システム内におけるデータの新たなエントリまたは変更のための方法が提案される。これによれば、前記統合システムにおけるデータベースシステムのうち任意の1つのデータベース内で共有されるデータを新たにエントリする際にデータコンフリクトを避けるため、各データベースシステム間で交換可能な各データオブジェクトごとに前記データベースシステムの一方を管理する側のシステムFSとして定義し、該管理する側のシステムFSのデータセットにも属するデータオブジェクトのデータを、管理される側のシステムGSにおいて新たにエントリまたは変更するたびに、システムを超えた確認アルゴリズムを実行し、該アルゴリズムにおいて、
a)変更を含むデータオブジェクトを管理する側のシステムFS(OLTP−R/3)に伝送し、
b)管理する側のシステムFS内で、変更の承認または少なくとも部分的な拒否として応答メッセージを生成し、
c)応答メッセージを含むデータオブジェクトを管理される側のシステムGS(MS)へ送り戻す。
【0021】
次に、図面に示された実施例に基づき本発明について詳しく説明する。そこで説明する特徴は、本発明の有利な実施形態を実現する目的で個別に用いることもできるし、互いに組み合わせて使用することもできる。
【0022】
図1は、オフライン分散型データベースにおける本発明による結合システムの環境の外観を示す図である。
【0023】
図2は、本発明において適用されるフロントオフィスシステムのアーキテクチャに関する概観をCRMシステムの実例で示す図である。
【0024】
図3は、図2によるシステムのフローコントロールの典型的な流れをデータアップロードプロセスの実例として示す図である。
【0025】
図4は、図2によるシステムで適用されるデータオブジェクト(”BDoc”)の構造を示す図である。
【0026】
図5は、本発明に従って互いに結合された2つのシステムにおいてデータのアップロードおよびダウンロード時にはたらくコンポーネントのアーキテクチャを示す図である。
【0027】
図6は、ダウンロードの事例に関する図3に応じたフローチャートを示す図である。
【0028】
図7は、関与するデータベースシステムに他のデータベースシステム内に含まれているデータを初回にダウンロードするためのコンポーネントのアーキテクチャを示す図である。
【0029】
図8は、必要とされるプライマリキーをシステムを超えて供給する方法を説明するための原理図である。
【0030】
図9は、BDocおよび属するキーマッピングテーブルのセグメント構造に関する実例を示す図である。
【0031】
図10は、いくらか複雑なセグメント構造を有する図9によるBDocの構造に関する実例である。
【0032】
図11は、本発明に適したデータマージ手順の原理を説明する図である。
【0033】
図12は、初回ダウンロードにおける基本コンポーネントの共働の様子を示す基本原理である。
【0034】
図13および図14は、本発明に適したネットフィールド伝送手順を説明するための2つの図である。
【0035】
図15は、データを同期合わせする手順を説明するための基本コンポーネントの原理図である。
【0036】
図16は、本発明に適した「コンペア」モジュールの機能を説明するための基本原理図である。
【0037】
図17は、本発明に適したデータアップデート時のコンフリクトを解消する手順の原理図である。
【0038】
これらの図面に実例として示されている本発明による統合された結合システムの適用事例は、販売EDPソリューション(Sales Force Automation; SFA)と中央ERPシステムとの統合に関する。図1には、その種のシステムの周囲環境に関する概観が描かれている。
【0039】
外勤従業員(Sales Representative)SRは外勤フィールドFDで働いており、その従業員はカスタマ(Customer)Cと相談してたとえばカスタマの注文をとる。外勤従業員SRは各々ポータブルコンピュータをもっており、これをモバイルクライアント(Mobile Client)MCとも称し、ローカルデータベース(Local Database)LDに属している。ポータブルコンピュータはネットワークのノードを成しており、これは常にネットワークと接続されているわけではなく、したがってオフラインノードと称する。
【0040】
モバイルクライアントMCはたとえばマーケッティング情報を提供し、殊にカスタマや製品の基本データ(マスタデータ)を格納している。外勤従業員SRはたとえば注文情報を入力し、また、未処理の注文や処理済みの注文についての状況の情報を得る。これらの機能を一時的に自律的に実現できるようにする目的で、そのために必要とされるすべてのデータがローカルデータベースLDに格納されている。
【0041】
企業の本部(Head Office)にはバックオフィスシステムが存在しており、これによって有利にはオンライントランザクションプロセッシングを行うことができる。ここに示されている実例ではこれはOLTP−R/3システムである。図面および以下の説明ではそのシステムの用語で表すが、汎用性を制約するわけではない。これにはデータベースOLTP−DBが含まれている。その基本データは内勤従業員(In-House-Employee)IHEによってメンテナンスされる。
【0042】
ローカルエリアネットワーク(Local Area Network)LANを介してOLTP−R/3システムはフロントオフィスサーバと接続されており、これをミドルウェアサーバ(MS Middleware Server)と呼ぶが、はやり汎用性を制約するわけではない。このシステムもデータベースCD(Condolidated Database)を有している。
【0043】
MSシステムには、モバイルクライアントMCのほかにオプションの別のシステムを接続することができる。図示されているように、本部HOには外部システムBWが配置されており、これはたとえばいわゆる "Business Information Warehouse" として企業にとって重要な販売情報を分析する。これはデータベースBW−DBを有している。図示されている事例の場合、これはバックオフィスサーバOLTP−R/3からもMSシステムからもデータを受け取る。外勤フィールドFDにおいてたとえば、ネットワーク内の付加的なノードを成すカスタマシステム(Customer System)CSを常に(オンライン)または一時的に(オフライン)MSシステムと接続することができる。このようにすればたとえば、カスタマの注文を外勤従業員を介在することなく処理することができる。
【0044】
このように図示されているネットワークは種々のデータソース(モバイルクライアントMC、OLTP−R/3、オプションの外部システムBWおよびカスタマシステムCS)を有しているが、それらは互いに独立していない。それらはMSシステムによって結合され、このシステムによれば各サブスクライバが自身に必要とされる許された情報を受け取るようになる。図示されている事例の場合、ミドルウェアサーバMSは同時にこのような結合機能も果たし、これとモバイルクライアントから成るCRMシステムの中央コンピュータを成しており、これはオフライン分散型データベースシステムである。これが中央データベースシステムOLTP−R/3と融合される。しかしながら本発明の基本原理をデータベースシステム融合に関する他の事例にも適用可能であり、つまりたとえば、2つまたは複数の中央データベースシステムの融合あるいは2つまたは複数の分散型データベースシステムの融合にも適用することができる。
【0045】
MSシステムのデータベースMS−DBには、その特有の機能(たとえばカスタマリレーションシップマネージメント Customer Relationship Management CRM)に必要とされるすべての情報が含まれている。これは統合データベースCD(consolidated data base)とも呼ばれる。なぜならばこれには(直前のデータ交換時点で)ポータブルコンピュータにおけるすべてのローカルデータベースLDの内容が含まれているからである。これにより、ローカルデータベースLDに必要なデータを供給して、たとえばデータの変更を伝達したり必要に応じてローカルデータベースLDをリストアすることができるようになる。
【0046】
ポータブルコンピュータは所定のインターバルで、実例として毎日夕方、たとえば電話回線、インターネットまたはイントラネットを介して、MSシステムと接続される。この場合、直前の接続以来収集されたデータがMSシステムに伝送される。しかもポータブルコンピュータはその機会に、それぞれ先行する期間における自身の固有の処理データと、(必要なかぎり)他のポータブルコンピュータおよび別のシステムの新たな入力データを受け取る。
【0047】
相互に接続されたシステムの有効データは(この実例ではカスタマやオーダなど業務処理に関連するので)ビジネスデータと呼ばれる。OLTP−R/3システムの場合にはそこからビジネスオブジェクト("BDoc")が形成され、これは別の処理のためのデータコンテナとして用いられる。たとえばある特定のオーダのためのビジネスオブジェクトはそのデータベース内に格納されているそのオーダに属するすべてのデータを有しており、これはそれらのデータがどのようにその論理構造(リレーショナルデータベースのテーブル)内にあるかとは無関係である。この構造はOLTP−R/3システムにとって知られているものであり、同じようにして他のバックオフィスシステムにも適用される。
【0048】
関与するシステムにおいてビジネスデータを処理するのに必要とされる制御データは、個々のデータベースにおける論理的に別個の部分に格納されており、これをレポジトリと称する。
【0049】
OLTP−R/3システムへの伝送について、伝送基準は広範囲にわたりスタティックである。これはひとたび設定されると、個々の企業における業務の流れの変更を比較的長い期間で変える必要がないかぎり、そのまま保持される。
【0050】
これに対し、ポータブルコンピュータへのデータ伝送は高度にダイナミックである。たとえば特定の販売地区に対する外勤従業員の管轄は頻繁に変わる可能性が多い。このような変更によってそのつどデータ伝送のための基準の変更が生じる。それというのも、それぞれ必要とされる最小データだけをポータブルコンピュータへ伝送すべきだからである。同じ理由で、ポータブルコンピュータ内で古くなったデータを消去しなければならず、他方、最近になって重要になったデータを追加する必要がある。データ伝送基準は有利には、MSシステム内でいわゆるパブリケーション(publication)およびサブスクリプション(subscription)として格納される。モバイルクライアントMCへの伝送基準およびデータの更新プロセスを、以下ではリアライメント(realignment)と称する。
【0051】
特定のデータは1つよりも多くのポータブルコンピュータにとって重要であるので、ポータブルコンピュータへの伝送時にコピーする必要がある。1つよりも多くの受信側へのこのような伝送を、以下ではレプリケーション(replication)と称する。
【0052】
図2には、MSシステムのアーキテクチャに関する概観が示されている。左側にはモバイルクライアントMCが描かれ、下方にはOLTP−R/3システムおよび外部システムBWが描かれている。図の他の部分には、データベースCDおよびそれに属するメッセージ伝送サーバ(Message Transfer Server)MTSを含めてMSシステムが示されている。
【0053】
MSシステムは有利にはR/3テクノロジーをベースとして実装されている。したがってその機能を複数のマシンに分散させることができ、たとえばデータベースのために1つの別個のマシンを使用し、要求処理のために1つまたは複数のマシンを使用することができる。メッセージ伝送サーバとして動作するマシンは、全体としてアドミニストレーションステーション(アドミンステーション Admin Station)ASと称する。メッセージ伝送サーバMTSおよびそれに属するアドミニストレーションコンソール(アドミンコンソール Admin Console)ACは有利には、Windows NT によって動作する1つのマシンにインストールされる。その結果生じる可能性のあるマシンの境界は図中、破線で描かれている。
【0054】
フロントオフィスシステムにおけるデータの伝送のためにデータコンテナが使用され、これをBDocと称する。これはモバイルクライアントMCとMSシステムとの間の通信にも用いられる。この場合、様々な種類のBDocを区別することができる:
−ポータブルコンピュータMCとフロントオフィスサーバCRM−MSとの間でトランザクション結果とステータス情報を伝送するため、トランザクションBDocが使用される。それらを以下のようにさらに区別することができる:
トランザクションBDocはトランザクション結果をモバイルクライアントMCからMSシステムへ搬送する。この場合、モバイルクライアントがBDocを成し、これはトランザクションの結果を有しており、それをMSシステムへ送信する。
【0055】
承認BDoc(Confirmation BDoc)は、MSシステムによるトランザクションBDocの処理成功を表す。トランザクションBDocの処理がうまくいったならば、BDocのステータスがそれ相応に変化し、それを送ったモバイルクライアントへ承認メッセージとしてBDocが送り戻される。この承認メッセージには、たとえばOLTP−R/3システムによって提供された付加的なデータあるいは統合データベースCDの変更された値も含まれている。その際、承認BDocには、変更された値だけまたはすべての値が含まれている。
【0056】
インポートBDocは、他のモバイルクライアントMCまたは外部のシステムのトランザクション結果をMSシステムからモバイルクライアントMCへ伝送する。インポートBDocにも、変更された値だけがまたはすべての値が含まれている。さらにインポートBDocは、モバイルクライアントMCとは別のソースからのデータ変更をMSシステムからモバイルクライアントへ伝送するためにも利用される。
【0057】
エラーBDoc(Error BDoc)は、トランザクションBDocの処理にあたりMSシステムにおいてエラーの発生したことを表す。この場合、エラーセグメントがBDocに挿入され、送信を行ったモバイルクライアントMCへエラーBDocとして送り戻される。エラーセグメントは、種々のエラー状態を表示するために種々のレコードを有することができる。さらにエラーBDocには、「先行の状態のイメージ」(before images)としてもとの値も含まれている。すべてのフィールドは、統合データベースCDの目下の内容で満たされている。
【0058】
−サービス指向BDocは、MSシステムからポータブルコンピュータMCへバイナリデータを伝送するために使用される。
【0059】
−バルク指向BDoc(Bulk oriented BDoc)は、たとえば初回のデータダウンロード時などにMSシステムからモバイルクライアントMCへ大量のデータを伝送するために使用される。
【0060】
さらにBDocは、搬送された内容に関して種々のBDocに細分化することができる。BDocをたとえば「カスタマ」、「オーダ」などとすることができる。
【0061】
BDocおよび殊にその構造についての詳細な説明はあとで行うことにする。
【0062】
MSシステムにおけるデータ処理は、「サービス」もしくは「アダプタ」と呼ばれるファンクションモジュールを用いて行われる。サービスは、BDocに適用できる特別なファンクションを提供する。アダプタは特殊なタイプのサービスであり、これによればMSシステム外におけるシステムとのコネクションが可能となる。
【0063】
モバイルクライントMSとミドルウェアサーバMSとの通信もそれらのローカルデータベースLDとの通信も、もっぱらトランザクション層(Transaction Layer)TLを介して行われる。パートレプリケートデータベースネットワークシステム(part-replicated data base network system)の実例としてのミドルウェアサーバMSとモバイルクライアントとのデータ交換にについての詳細は、国際出願 PCT/DE00/01552 に示されており、これを本出願の参考文献とする。
【0064】
図2には描かれているMSシステムにおける各コンポーネントの機能は、以下のような特徴を有している。
【0065】
メッセージ伝送サーバMTSはモバイルクライアントMCからBDocを受け取り、BDocをそのモバイルクライアントに伝送する。データ伝送はそれぞれ1つのモバイルクライアントMCによって導入される。たとえばその目的で、Microsoft の通信テクノロジーDCOMを利用することができる。
【0066】
モバイルクライアントMCからMSシステムへのBDocの伝送は到来メッセージ用アダプタ(Inbound Message Adapter)IMAによって行われる一方、逆方向で伝送されるメッセージは送出メッセージ用アダプタ(Outbound Message Adapter)OMAによって伝送される。このようなデータ伝送は、qRFC(queued Remote Function Call)と称するプロトコルによって行われる。これは処理の順序を決定するためにキュー(queue)を利用するリモートファンクションコールプロトコルである。
【0067】
MSシステムの中央コンポーネントはフローコントロール(Flow Control)FCである。フローコントロールFCはBDocの処理を行い、到来するBDocを適正な順序でサービスおよびアダプタへルーティングし、必要であればエラー処理プロシージャをトリガする。これはすべてのサービスおよびアダプタに対し同じインタフェースを介して行われる。他方、このインタフェースにおけるメインパラメータはBDocである。フローはBDocタイプ固有に制御データメモリ(レポジトリ Repository)内で定義されている。
【0068】
OLTP−R/3システムおよびBWシステムなど外部のシステムは、それぞれ固有のアダプタOLTP−ADもしくはBW−ADを介してMSシステムと接続されている。つまり外部システムはやはり各々固有のアダプタタイプをもっており、これもBDoc固有にレポジトリ内に定義されている。アダプタおよびそれに接続された外部システムとの間のデータ伝送チャネルのプロトコルおよびデータ構造は、外部システムのタイプに固有のものである。
【0069】
データベースサービス(Consolidated Database Service)CDSは、統合データベース(consolidated database)CDに相応のデータを格納するために用いられる。このサービスCDSは、データをデータベースに書き込むときにデータ一致性のチェックを実行しない。そのようなチェックは、データをMSシステムへ伝送するコンポーネント(たとえばモバイルクライアントMCまたはOLTP−R/3システム)によって実行する必要がある。データベースCDの読み出しのため他のサービスはサービスCDSを利用するのではなく、図示されていない特別なハンドラを利用し、これはサービス、アダプタまたは他のハンドラから呼び出される。
【0070】
レプリケーションおよびリアライメントモジュールRPMは2つの主要な役割をもっている。レプリケーションパートは処理されたBDocを引き継ぎ、その受け取り側を決定する。いっそう迅速に処理するため、そのために必要とされる情報がルックアップテーブルから読み出される。目下処理されているBDocに基づきルックアップ情報の変更の必要性をレプリケーションパートが確認すると、そのレプリケーションパートはリアライメントハンドラをトリガする。リアライメントハンドラはレプリケーションルールを評価して、必要とされるルックアップ情報を生成する。さらにリアライメントハンドラは受け取り側に対し新たなデータを提供し、不必要なデータを消去する命令を出す。この目的でリアライメントハンドラは特別なハンドラを用いる。
【0071】
MSサーバをカスタマ固有に整合するため(カスタマイズするため)、および論理的なデータの流れについてシステム全体を管理するために、アドミニストレーションコンソールACが利用される。
【0072】
図3にはデータアップロードオペレーションの実例として、MSシステムにおけるフローコントロールの典型的な流れが示されている。この場合、フローコントロールFCのメッセージプロセッサ(Message Processer)MPによって実行されるステップが、MP−FCと付された列に描かれている。第1および第3の列には、サービスにより実行される処理ステップが示されている。最後の列には、OLTP−R/3システムによって実行される処理ステップが示されている。
【0073】
この流れは、新たなBDocを受け取ったため、メッセージ伝送サーバMTCが(RFCを介して)到来メッセージIMAのためのアダプタを呼び出したときに始まる。到来メッセージIMAのためのアダプタによってメッセージプロセッサMP−FCがスタートする。
【0074】
実行すべき流れはメッセージプロセッサMPによって決定される。この場合、基本的に2つのフロープロシージャを区別することができ、1つは少なくとも部分的にOLTP−R/3システムに関連するBDocタイプの処理のためのものであり、1つはその他のBDoc(MSシステム内でのみ巡回する)のためのものである。
【0075】
個々のBDocタイプのためにレポジトリに格納されているフロー定義に依存して、メッセージプロセッサMPは呼び出される第1のサービスもしくはアダプタを決定する。(少なくとも部分的に)OLTP−R/3システムに関連するBDocのタイプのために、第1のサービスとしてOLTP−R/3アダプタOLTP−ADが呼び出される。その他のBDocのためにはOLTP−R/3アダプタは呼び出されない。BDocのタイプのためにOLTP−R/3アダプタを呼び出すか否かの判定は、フローの決定時に下されており、つまりこのフロー内では下されない。
【0076】
OLTP−R/3アダプタOLTP−ADが呼び出されるとそのアダプタは、BDocが本当にOLTP−R/3システムに関連するものなのかを決定する。このことは必ずしもあてはまらない。それというのもOLTP−R/3システムに対する関連性はBDocにのみ左右されるのではなく、その内容にも左右される可能性があるからである。1つの実例は、ビジネスオブジェクトタイプ「カスタマ」のBDocである。このようなBDocにカスタマに関する情報が含まれているならば、それはOLTP−R/3システムへ送られるが、販売渉外担当(sales and distribution contact)に関する情報が含まれているなら、それはMSシステム内にしか格納されない。
【0077】
BDocがOLTP−R/3システムに関連するとOLTP−R/3アダプタが判定したならば、そのアダプタはそれに対してコールを送り、進行中のフローを中断する。OLTP−R/3システムにおける処理の終了後、それによってOLTP−R/3アダプタへコールが送られ、そのアダプタは結果を引き継ぎ、フローを再びスタートさせて、フローコントロールFCのメッセージプロセッサMPを呼び出す。
【0078】
メッセージプロセッサMP−FCは、どのサービスを次に呼び出すべきであるのかを決定する。BDocがOLTP−R/3システムに関連していないことをOLTP−R/3アダプタが検出すると、そのアダプタはメッセージプロセッサMP−FCへコントロールを戻し、この場合もそのプロセッサは次に呼び出すべきサービスを決定する。
【0079】
通常、OLTP−R/3アダプタのあとにデータベースサービスCDSが呼び出される。このサービスは、BDocに含まれているデータを統合データベースCD内で持続させる。
【0080】
データが首尾よく統合データベースCD内に書き込まれると、通常はレプリケーションおよびリアライメントサービスRPMが呼び出される。このサービスの機能は、BDocがレプリケーション情報に作用を及ぼすか否かをチェックすることである。作用を及ぼすのであればリアライメントハンドラに対し、ルックアップ情報を更新しビジネスデータ分配のためにBDocを生成するオーダが形成される。レプリケーションおよびリアライメントサービスRPMの第2のアクションは、目下のBDocに受け取り側リストを追加することである。
【0081】
さらに、メッセージ伝送サービスMTSによりBDocをその受け取り側へ伝達するために準備処理する目的で、送出メッセージOMA用のアダプタが呼び出される。
【0082】
アップロードが失敗した場合にはリジェクトサービスRSが呼び出される。BDocはエラーBDocとして(つまりエラー情報を含むBDocとして)マーキングされる。アップデートオペレーションにおいてリジェクトサービスは有効な値を統合データベースCDから読み出す。すべてのオペレーションにおいて、モバイルクライアントMCの先行の状態がマークされる。ついでBDocは、それを送ってきたポータブルコンピュータへ送り戻される。そこにおいて相応のトランザクションが新たに実行される。
【0083】
図3には(リジェクトサービスRSを除いて)成功経路だけが書き込まれている。当然ながらエラー処理ルーチンも設けられているが、それについてはここでは詳しく説明しない。
【0084】
次に、図4を参照しながらBDocの構造について詳しく説明する。この図の上部にはBDocタイプの定義構造が示されており、これはMSシステムのレポジトリに格納されている。さらに下部には、同様にレポジトリ内に格納されているBDoc自体の構造が描かれている。
【0085】
BDocは、BDocヘッダBDoc−HおよびBDocボディBDoc−Bから成る。BDocヘッダBDocヘッダ−Hにはコントロール情報が含まれており、たとえばBDocのタイプ(「カスタマ」、「オーダ」...)、その送り手(モバイルクライアントMC)ならびにタイムスタンプなどが含まれている。さらにプライマリキーの複製も含まれていると、パフォーマンスの理由から有利である。
【0086】
BDocボディBDoc−Bにはデータが含まれている。データレコード(Data Record)DRには本来のデータが含まれている。この構造は属するデータセグメント(Data Segment)DSの定義中で規定されている。このセグメントは、実際の物理的なテーブルにおける一種のテーブルビューを成している。オプションとしてBDocにはさらに、1つまたは複数のエラーレコードER(Error Record)をもつエラーセグメントESも含まれる。
【0087】
各データ領域は規定の長さをもっている。それらの領域はキーとデータフィールドから成る。それらの領域に消去情報が含まれているならば、キーフィールドだけに有効なデータが含まれている。また、それらの領域に「インサート」情報または「アップデート」情報が含まれているならば、すべてのデータフィールドに有効なデータが含まれているかまたは、変更されていないフィールドにプリセット値(たとえば0.0)が含まれている。フィールドが満たされているのか利用されていないのかを表す目的で、いわゆる「送信ビット」が使用される。この場合、レプリケーションおよびリアライメントにあたり考慮しなければならないプライマリキーとフィールドが常に(変更された否かとは無関係に)送られる。送信ビットがセットされるのは、値が実際に変更されたときだけである。
【0088】
BDocタイプの定義つまり階層的におかれた要素から成る個々のBDocタイプ固有の構造に関する情報BDocは、BDocタイプの定義("BDoc Type Definition")内に含まれており、これはBDocボディ定義BDoc−BDとBDocセグメント定義BDoc−SDから成る。BDocボディ定義BDoc−BDは正確に1つのルートセグメントを有しており、これにはただ1つのデータレコードだけが含まれている。この条件は遵守しなければならず、その目的はBDoc中に含まれている情報がそれぞれ個々のノードシステムへ伝達できるようにまたは別のやり方で処理できるようにするためである。たとえばタイプ「カスタマ」のBDoc中には、ただひとりのカスタマに関する情報だけしか格納してはならず、そうすることによってカスタマ情報を個々に所期のように個々のカスタマごとに相応のノードシステムへ導くことができるようになるからである。相前後するセグメントのデータレコードには依存するデータが含まれており、たとえばカスタマのマシン装備に関するデータなどが含まれている。当然ながらこの場合、1つのセグメントに対し複数のレコードを設けることができる。
【0089】
セグメントがBDocタイプの定義中で階層構造をとっているのに対し、BDocの物理的な再生においてはそのような階層はない。階層関係は、依存するセグメントのデータレコードDRがそれらの上位のデータレコードのキーを有することにより、BDoc内に収容されている。トランザクションBDocの場合にはさらに(エラーレコード Error Record ERをもつオプションのエラーセグメントを除いて)依存しないセグメントが設けられており、これをルートセグメントと称する。
【0090】
変更されたデータがMSシステムへ伝送される場合、モバイルクライアントMCが変更前に有していた値がMSシステムにとって重要である可能性がある。そのような「先行状態のイメージ」(before image)は固有のデータ領域に伝達され、それらは相応に特徴づけられている。
【0091】
外部のシステムBWおよびインストールファイルをモバイルクライアントMCへ伝送するために、サービス指向BDocが用いられる。サービス指向BDocのボディは、一般情報をもつルートセグメントとバイナリデータを含むメモセグメントから成る。
【0092】
バルク指向BDocは、モバイルクライントの最初のセットアップ(Initial Client Setup)およびリアライメント中のデータ伝送のために使用される。バルク指向BDocもタイプ固有に(つまりたとえばオブジェクトタイプ「カスタマ」などのために)定義されている。とはいえそれらは、そのルートセグメントにただ1つのレコードだけしか収容してはならない、という制約を受けない。したがってたとえばバルク指向BDocは複数のカスタマのデータを一度に伝送することができる。
【0093】
OLTP−R/3アダプタOLTP−ADは、OLTP−R/3システムをMSシステムとリンクする。これはデータを双方向で伝送するために用いられる。データたとえばカスタマの注文がモバイルクライアントMCに入力され、OLTP−R/3システムに転送される場合、これを「アップロード」と呼ぶ。データがOLTP−R/3システムに入力され、そこからMSシステムへ転送される場合、これを「ダウンロード」と称する。
【0094】
この場合、3つのタイプのダウンロードを区別することができる。初回のデータダウンロード(Initial Download)によって、MSシステムの統合データベースCDはオペレーションの開始にあたりOLTP−R/3システムからのデータで満たされる。オンラインユーザがデータをOLTP−R/3システムへ入力し、変更されたオブジェクトがMSシステムへ転送されるとき、デルタダウンロードが行われる。このようなデルタダウンロードは、すべてのデータ形式について可能なわけではない。これらの機能が利用できないならば、第3のダウンロードメカニズムが使用され、これを以下では同期メカニズムと称する。
【0095】
図5には、アップロードおよびダウンロードにおいて有効なMSシステムおよびOLTP−R/3システムのコンポーネントが示されている。MSシステムの構成部分は、BDocの処理に必要とされるプロセスステップをコーディネートするためのフローコントロールFC、OLTP−R/3アダプタOLTP−ADならびに3つのエージェントであり、それらはキージェネレータ(Keygenerator)KG、マッピングエージェントMAおよびマージエージェント(Merging-Agent)MEAと称する。これらのエージェントはOLTP−R/3アダプタのための補助機能を果たす。
【0096】
MSシステムの構成部分はスタンダードBAPI(Business Application Programming Interface)SBを呼び出すためのコールフレームCFであり、これはBDocの処理中に呼び出すことができる。スタンダードBAPIは変更を持続的なものにするため、アップデートファンクションモジュールUFMを呼び出す。
【0097】
アップデータファンクションモジュールUFMは変更のたびにイベントを発し、これはイベントディストリビュータEDへ伝達される。このような伝達に対するリアクションとして、イベントディストリビュータはすべてのサブスクライバを始動させる。とりわけこれにより、サブスクライバとしてエントリされている結果伝送部(Results Sender)RSが呼び出される。そして変更されたデータは結果伝送部RSからMSシステムへ伝送される。1つのメモリ領域であるキーリファレンス(Key Reference)KRには、フロントオフィスシステムMSのキーKMSとオブジェクトリファレンスORが格納されている。また、1つのメモリ領域である補助データ(Additional MS-Data)AMDには、OLTP−R/3システムにより搬送しなければならないがそれ自体にとっては重要ではないデータ(たとえばフロントオフィスシステムのキーなど)が含まれている。MSシステムからはOLTP−R/3システムへは、それに関連しないデータは伝送されない。
【0098】
コールフレームCFおよび結果伝送部RSだけが、ここで述べた機能のために付加的にインプリメントされたOLTP−R/3システムの構成部である。
【0099】
アップロードは以下のようにして行われる。MSシステムにおいてBDocが処理される。この処理のステップとしてOLTP−R/3アダプタが呼び出される。そしてこれは、BDocがOLTP−R/3システムに関連するか否かについて判定する。関連するのであれば、BAPI呼出部BCはそのBDocをマークする。これにより保証されるのは、同じキュー内にある別のBDocも処理されないようにすることである。OLTP−R/3システムに関連のないその種のBDocも必ずキュー内に存在する。その理由は、キュー内のBDocと先行のBDocとの依存性が場合によっては存在するからである。BDocの構造は、OLTP−R/3システムの対応するBAPIのパラメータ構造にマッピングされる。ついでそのBAPIのコールフレームがOLTP−R/3システムにおいて呼び出される。
【0100】
コールフレームの第1の役割は二重の処理を避けることである。BAPIに従って新たなオブジェクトを生成しようという場合にコールフレームは、そのオブジェクトがすでに存在していてMSシステムの相応の要求に応じて生成されているかのかについてチェックする。そうであればビジネスオブジェクトの新たな生成の代わりにすでに処理されたデータが抽出され、MSシステムへ伝送されて戻される。コールフレームの第2の役割は、MSシステムにおけるキーおよびオブジェクトリファレンスとOLTP−R/3システムのキーおよびオブジェクトリファレンスとの間で必要とされるマッピングを保証することである。さらに第3の役割はコミットサイクルのハンドリングである。これにより、ただ1つのコミットサイクルでBAPI処理が実行されるようになる。その結果、バックオフィスシステムOLTP−R/3へのデータの格納ならびにフロントオフィスシステムMSへのデータの伝送が、1つの共通の処理単位で行われるようになる。
【0101】
コールフレームCFのメイン機能は、スタンダードBAPI SBを呼び出すことである。このためコールフレームは、それが受け取ったBDocの構造を汎用的なBAPIの構造に置き換えるために必要とされるすべての情報を有している。BAPIはBDocのデータを処理し、アップデートファンクションモジュールUFMに対する呼び出しを有している。このファンクションモジュールは、コールフレームがコミット命令をスタンダードBAPIへ出したときに稼働し始める。アップデートファンクションモジュールはデータベースにおけるデータの変更を持続的なものにする。さらにこのモジュールはイベントを発し、そのイベントはイベントディストリビュータEDのサブスクライバへ分配される。これらのサブスクライバの1つは結果伝送部RSである。これは変更されたデータを発せられたイベントのパラメータとして受け取り、それを結果データAMDと混合してそれをMSシステムへ伝送する。
【0102】
MSシステムにおいて、結果セーブエージェントRSAは受け取った結果をBDoc構造へマッピングして戻す。マージエージェントMEAは、OLTP−R/3システムから到来した結果をMSシステムにおけるBDocと混合する。その後、結果セーブエージェントRSAはBDocのためのフローコントロールを開始し、BDocのステータスを変えて "OLTP Complete" とする。
【0103】
BDocを処理するためのフローコントロールについては、図3に基づく前述の説明を補足的に参照されたい。
【0104】
デルタダウンロード(じかにOLTP−R/3システムに入力されその後MSシステムへ転送されたデータの伝送)は、アップロードと非常に似ている。図6には、デルタダウンロードに基づき生じたBDocの処理における完全なフローコントロールが示されている。このアーキテクチャは図5に対応している。
【0105】
ダイアローグプログラムDPを介してOLTP−R/3システムとオンラインで通信する内勤従業員IHEによって、ビジネスオブジェクトが生成される。ダイアローグプログラムDPはアップデートファンクションモジュールUFMを呼び出し、稼働し始める。アップデートモジュールはイベントを発し、結果伝送部RSはMSシステムにおける結果セーブエージェントを呼び出す。アップロードプロセスとは異なり、結果伝送部RSがMSシステムへ伝送しなければならないような付加的なMSデータは存在しない。たとえば新たに生成されたオブジェクトのためのMSキーなどのように欠けているMSデータはキージェネレータKGによって生成され、キージェネレータ自体は結果セーブエージェントRSAによってトリガされる。OLTP−R/3システムから受け取ったデータに対し新たなBDocが生成され、図6に示されているように相応のコントロールフローを実行するためフローコントロールがスタートする。
【0106】
生産的オペレーションの開始前にMSシステムのデータベースCDを満たすために、初回のデータダウンロード(Initial Download)が必要とされる。ダウンロードすべきビジネスオブジェクトクラスは、カスタマ固有のシステム整合中に決定される。しかもビジネスオブジェクトのインスタンスを、特定の属性値に依存してフィルタリングすることができる。ついで、固有の出口(カスタマイクジット Customer Exit)を利用することができる。
【0107】
図7には、初回データダウンロードのために用いられるコンポーネントが示されている。初回データダウンロードドリガエージェント(Initial Download Trigger Agent)IDTAはプロダクションフェーズ開始前、初回データダウンロードを導入するためシステムアドミニストレータによって始められる。初回データダウンロードトリガエージェントは、OLTPダウンロードトリガエージェント(OLTP Download Trigger Agent)ODTAを呼び出す。トリガはqRFCによって引き起こされる。これにより、初回データダウンロードアクションが正確に1度実行されるようになる。OLTPダウンロードトリガエージェントODTAは、選択されたビジネスオブジェクトクラスに対し抽出部マスタEMを呼び出し、さらにこの抽出部マスタ自身はR/3抽出部EXTを呼び出す。抽出部マスタEMと抽出部EXTの相違点は、抽出部マスタはMSシステムとの共働に固有に適合されたコンポーネントであるのに対し、抽出部EXTはOLTP−R/3システム内の他の関連においても使用される。
【0108】
抽出部マスタによって引き継がれたフィルタ基準に基づき、抽出部EXTはOLTPデータベースOLTP−DBからオブジェクトデータを選び出す。さらに抽出部マスタは処理すべきテーブルに関する情報も供給し、必ずしも完全なオブジェクトを抽出しなくてもよいようにする。個々の抽出部マスタは選択されたオブジェクトを結果伝送部RSへ伝送する。既述のように、固有の出口を用いて結果伝送部において付加的なフィルタリングを実行することができる。
【0109】
結果伝送部RSは、ビジネスオブジェクトデータをBAPI結果セーブエージェントRSAへ伝送する。そしてこのエージェントはマッピング用エージェントMA、キー生成用エージェントKGならびに統合データベース用バルクストレージエージェント(Bulk CDB Agent)BCAを呼び出す。マッピングエージェントは、OLTP−R/3システムの構造をMSシステムの構造に変換する。キージェネレータは、OLTP−R/3キーだけをもつオブジェクトのためのMSキーを生成する。バルクストレージエージェントBCAは、ビジネスオブジェクトのデータを統合データベースDBへ書き込む。バルクストレージエージェントBCAとMSシステムのデータベースサービスCDSとの相違点は、BCAは複数のオブジェクトを同時に処理できるのに対し、CDSはそれぞれただ1つのビジネスオブジェクトのデータだけしか処理できないことである。
【0110】
良好なパフォーマンスを保証するため、複数のビジネスオブジェクトクラスが同時にダウンロードされる。とはいえこれは、互いに無関係なオブジェクトクラスについてのみ行われる。あるオブジェクトが他のオブジェクトに依存しているかぎりは(たとえば「カスタマ}の「オーダ」など)、それらは適切な順序で相前後してダウンロードされる。この場合、望ましい順序におく目的で、各オブジェクトはインスタンスのレベルではなくクラスのレベルでダウンロードされる。
【0111】
抽出部はOLTP−R/3データベースからデータを抽出する。既述のように、それらは他のアプリケーション領域(たとえば外部のアプリケーションBW)のためにも用いられる。
【0112】
抽出部の利用は2つのステップを有している。第1のステップにおいてフィルタ基準が抽出部へ渡される。これはフィルタ基準に対応するすべてのビジネスオブジェクトのキーを決定する。さらに第2のステップにおいて、本来の情報を読み出すためキーリストを用いて抽出部マスタEMが呼び出される。そして抽出部マスタは抽出部を用いて、別の処理のためにBDocとして必要とされる順序で呼び出しに固有のデータをテーブルからフェッチする。
【0113】
ブロックサイズによって、1つのパスにおいて処理されるビジネスオブジェクトの個数が決定される。抽出部はシリアルに動作可能であり、つまり1つのパスを他のパスの次に処理することができる。パラレルの動作モードもオブジェクトごとのベースで可能である。
【0114】
OLTP−R/3システムの構造は、マッピングによりMSシステムの構造に移される。マッピングはフィールドごとに実行される。この場合、複数のフィールドを1つのフィールドに連結したり、あるいは1つのフィールドを複数の部分に分けることができる。また、フィールドタイプがコンバートされる。さらにソースフィールドから依存する情報が生成される。
【0115】
キージェネレータKGは、OLTP−R/3キーに対しそれぞれCRM−MSキーを見つけるために用いられる。この場合、それぞれ1つのキージェネレータはBDocのタイプについて固有に、レポジトリ情報を利用して生成される。キージェネレータエージェントを最新の状態に保持する目的で、キージェネレータを生成するためのジェネレータがレポジトリのジェネレータエージェントにおいて1つのサブスクライバとして登録される。そしてこれは、対応するレポジトリの情報が変化したときに呼び出される。
【0116】
キージェネレータはBDocを受け取り、存在するすべてのOLTP−R/3キーに対しCRM−MSキーをここではGUID(globally unique identifier)のかたちで使用する。必要とされるMSキーは種々の場所で探され、つまりまずはじめにキージェネレータのローカルテーブルにおいて探され、ついでキーマッピングテーブルによって、最後に統合データベースCDにおいて探される。MSキーがみつからなければ新たなキーが生成され、種々のマッピングテーブルに挿入される。
【0117】
データがまだ統合データベースCDに格納されていない状況でキーが二重に生成されるのを避けるため、付加的なキーマッピングテーブルが必要とされる。キージェネレータのローカルテーブルはオプションであり、パフォーマンス向上のためキャッシュとして用いられるだけである。
【0118】
OLTP−R/3データベースOLTP−DBとMSシステムの統合データベースCDとの同期合わせのために2つのコンポーネントが設けられており、すなわち「リクエスト」と「コンペア」とが設けられている。リクエストコンポーネントは、初回データダウンロード用のコンポーネントと非常に似ている。これによって、所期のように特定のビジネスオブジェクトをOLTP−R/3データベースOLTP−DBから統合データベースCDへダウンロードすることができ、つまりはポータブルコンピュータMCのデータのレプリケーションを(フローコントロールFCの制御のもとで)実行することができる。リクエストによって指定されたフィルタ基準は初回データダウンロードの一般的なフィルタ基準と混合され、その結果、初回データダウンロード中に処理されたデータの1つのサブセットだけを選択できるようになる。このリクエストコンポーネントをインタラクティブにスタートさせることもできるし、バッチモードでスタートさせることもできる。
【0119】
コンペアコンポーネントはOLTP−R/3システムからビジネスデータをダウンロードする。比較アクションの結果として得られる相違点によって、統合データベースCDにおいて行う必要のある変更が表され、これはその内容をOLTP−R/3データベースOLTP−DBの内容と一致させることを目的としている。その際、変更情報(「インサート」、「アップデート」、「デリート」)はBDoc構造内に格納される。本来の比較アクション後に統合データベースDBに対しその変更が適用され、それによってその変更をOLTP−DBと一致させるようにする。そして変更情報からBDocが生成され、ローカルデータベースLDのレプリケーションのため(フローコントロールにより制御されて)モバイルクライントMCが用いられる。
【0120】
次に、本発明にとって重要な機能について補足的に説明する。
【0121】
1.クロスシステムプライマリキー(cross-system primary key)の供給
上述のように、オフライン分散されたデータベースシステムのセマンティクスインテグレーションにとって重要であるのは、システムを超えてクロスシステムもしくはシステムワイドでプライマリキーを供給することであり、これによってデータオブジェクトの一義的な識別を相互に融合するデータベースシステムの境界を超えて実現することができる。
【0122】
図8には、(上述の説明を補足するかたちで)これに適した手順の基本原理が描かれている。キージェネレータKGは、ここでは一般的にAもしくはBの付されたデータベースシステム(ソースシステム)において捕捉されたデータを受け取る。これにはシステム固有の個々のプライマリキーKAもしくはKBが属している。(ターゲットとなるシステムにおける)それぞれ他のプライマリキーについては、データセットにおいて空のフィールドが設けられている。キージェネレータはキーマッピングテーブル(Key Mapping Table)KMTの内容を読み出し、システムAまたはBの一方から供給されるデータセットのキーフィールドと比較する。ソースシステム(たとえばKA)のプライマリキーがキーマッピングテーブルKMT内にすでに存在しているならば、供給されたデータセットは既存のエントリの変更(アップデート Update)に該当する。この場合、ターゲットとなるシステム(たとえばKB)における対応のプライマリキーがキーマッピングテーブルKMTから読み出され、データセットの空のフィールドにエントリされる。
【0123】
これに対し供給されたプライマリキーがキーマッピングテーブルKMT内にみつからなければ、それはデータセットの新たな生成(インサート Insert)である。この場合、欠けているプライマリキー(たとえばKB)がキー生成モジュール(Key Generate Module)KGMによって生成されてキーマッピングテーブルKMTに書き込まれ、さらにそのキーは空のデータフィールドにエントリされる。その後、データセットはターゲットとなるシステムにおいても一義的に識別可能であり、ソースシステムのキーとターゲットシステムのキーは互いに一義的に対応づけられる。
【0124】
次に、上述のBDocのように実際のインプリメントにおいて階層的に分けられたデータセグメントの複雑な構造をもつデータオブジェクトを有するデータベースシステムにおいてこの原理を実施するための実際のやり方について説明する。
【0125】
図9には、2つのセグメントS1およびS2から成る非常に簡単な構造が描かれている。セグメントS1は階層的にいえばセグメントS2の一段上に配置されており、したがって子セグメントS2に対する親セグメントと呼ばれる。親セグメントは図示の事例ではBDocのルートセグメントである。
【0126】
親セグメントS1は、MSシステムのプライマリキーKMSとOLTP−R/3システムのプライマリキーKR/3を有している。これらのキーの各々は、1つまたは複数のセグメントフィールド内に格納されている。
【0127】
子セグメントも、(1つのフィールドに格納されている)MSシステムのプライマリキーKMSと(3つのフィールドに格納されている)OLTP−R/3システムのキーKR/3を有している。さらに子セグメントのフィールドには上位の親セグメントのキーも含まれており、このことは両方のセグメント間の矢印によって表されている。とはいえそれらのフィールドはキーのファンクションをもっているのではなく、セグメント構造に関する情報に対するいわゆる外部キー(foreign key)として用いられる。つまりそれらは、S2はセグメントS1の子であることを表している。
【0128】
図9の右側には対応するキーマッピングテーブルが描かれており、この場合、矢印で表されている行にはセグメントS1とS2の各キーが書き込まれている。
【0129】
図10にはいくらか複雑なフィールド構造が示されており、これには親セグメントS1(BDocのルートセグメント)、階層的にいえば下位に位置する子ジェネレーションの2つのセグメントS2aおよびS2b、さらにはセグメントS2aの子である孫ジェネレーションのセグメントS3が設けられている。たとえばセグメントS1には「カスタマ」タイプのBDocのためにカスタマの名前と住所をもたせることができ、セグメントS2aにはそのカスタマの担当員を、また、フィールドS3にはその担当員の渉外情報(電話番号、サービス時間など)を、さらにフィールドS2bにはそのカスタマの装備しているマシンに関する情報を含めることができる。
【0130】
この場合も各セグメントには(図示の実例ではみやすくするためそれぞれ1つのフィールドのみにおいて)両方のデータベースシステムのキーKMSおよびKR/3を有しており、この場合、依存するシステムはそれぞれ親ジェネレーションのキーを外部キーとして有している。図10の右側に描かれているキーマッピングテーブルは、やはり両方のシステムの対応を示している。
【0131】
実際には大規模なデータベースシステムのデータオブジェクトは、互いにインタリーブされた多数の階層平面をもつ非常に複雑なデータ構造を有している可能性があり、その際、セグメントはしばしばきわめて多くの個数のデータレコードを有している。これに加えて、特別な要求を考慮するため特殊な構造エレメントの必要とされることも多い。たとえば個々のデータレコードのデータに対し、それらが下方の階層平面にあるにもかかわらず、迅速にアクセスできるようにすることの要求されることが多い。このような状況において好適であるのは、階層的に深いセグメントにおいて必要とされるキーを比較的高い階層のセグメントにおける特別なフィールドに格納することである。たとえば図10に描かれているように、第2のセグメントS2aの第1のデータレコードのコードC1Mを有するキーがセグメントS1の特別フィールドSF内にエントリされており、その目的はたとえばS1にコーディングされているカスタマの最も重要な担当員に対するダイレクトなアクセスを可能にすることである。このような構造上の特殊性によって、上述の方法の実施は実際にはとても困難になる。
【0132】
このような問題点を以下で説明するアルゴリズムによって解決することができる。このアルゴリズムは2つのプログラム部分から成り、それらをPASS−IおよびPSS−IIと称する。
【0133】
PASS−Iにおいて、すべての定義済みセグメントに対し(つまりキー生成の必要とされるすべてのセグメントに対し)、およびすべてのデータセットに対し、コメント「KMSを満たす」の付けられたアルゴリズムセクションが実行される。このアルゴリズムセクションではまずはじめに、プライマリキーのフィールドが空であるか否かの問い合わせが行われる。空であるならば、存在するキーKR/3のもとでキーマッピングテーブルにおいて、エントリが存在するか否かが探索される。場合によっては、対応するMSプライマリキーがキーマッピングテーブルから取り出され、BDocへエントリされる。
【0134】
探索されたKMSのエントリが存在しなければ、GUIDが新たなMSプライマリキーとして生成され、KR/3もKMSもキーマッピングテーブルにエントリされる。さらにBDocへのKMSのエントリが行われる。
【0135】
ついで、コメント「MS親キーを満たす」の付されたアルゴリズムセクションが実行される。MS親キーのためのフィールドが空であれば、読み出しポジションがBDoc内の親セグメントにおかれ、しかもこれは対応するKR/3を含むデータレコードにおかれる。その後、対応するKMSが親セグメントから取り出され、子セグメントの外部キーフィールドにエントリされる。
【0136】
PASS−Iは、階層によりまえもって定められた順序で(最も高い階層平面から始めて)BDocのすべてのセグメントが処理されてしまうまで何度も実行される。
【0137】
その後、PASS−IIがスタートする。これはFETCHテーブルと称するレポジトリに格納されたテーブルによって制御される。このテーブルには、PASS−Iでは不可能である充填アクション(フィルアクション)が記述されている。これには、(図10に描かれているように)階層的に低い方のセグメントからの値の充填と、親平面よりも高い階層平面(つまりたとえば2つの平面だけ高い平面すなわち親の親の平面)からのキーの充填が属している。
【0138】
これらの機能を果たせるようにするため、FETCHテーブルは以下の構造を有している。
【0139】
・DestTbl:ターゲットテーブル
・DestFld:ターゲットフィールド
・SrcTbl: ソーステーブル
・SrcFld: ソースフィールド
・Cond: KR/3またはサンプルx=yによる条件
FETCHテーブルにおけるエントリにより、ソーステーブルのソースフィールドからターゲットテーブルと称するBDocのセグメントへの充填アクションが発生する。
【0140】
PASS−IIのアルゴリズムは以下の通りである:
処理されるBDocのすべてのセグメントについて、およびセグメントがDestTblとしてエントリされているFETCHテーブル内のすべてのエントリについて、FETCHテーブルから値が読み出される。その後、条件判定が行われる。Cond=R/3とセットされていれば、それはBDoc内のキー値の伝送のことであり、この場合、ソースセグメントにおけるソースフィールドの内容がターゲットセグメント内のターゲットフィールドへ伝送される。条件Condが別の値を有しているならば、BDoc自体からまたは統合データベースCDから値が引き継がれ、後者の場合、データベースCD内のソーステーブルへのアクセスが行われ、その内容がターゲットセグメントのターゲットフィールドへ伝送される。
【0141】
2.データマージ
種々のデータベースシステムの融合におけるさらに別の基礎的な問題点は、2つのシステムにおいて所定のタイプのデータオブジェクトに対して存在するデータがそれぞれ異なることである。たとえばCRMシステムにおけるデータオブジェクト「カスタマ」には、個々のカスタマ担当員または準備されている販売交渉(opportunities)に関する情報の含まれている可能性があり、これをERPシステムは必要としない。これに対し、ERPシステムにおけるデータオブジェクト「カスタマ」は、たとえば取引関係開始以来のカスタマのすべての勘定のような情報を有しており、これをCRMシステムは必要とせず、したがってそこで処理されるデータオブジェクトについてセグメントは設けられていない。
【0142】
プライマリキーに関してはさきに説明したロジックが有利であり、それによればシステムの一方においてつまりフロントオフィスシステムMSにおいて、互いに融合されるシステムの両方のキーKMSおよびKR/3がホールドされるのに対し、バックオフィスシステムにはそのキーKR/3だけがホールドされる。
【0143】
このような状況においてできるかぎり完全なデータ交換を実現するために有利であるのは「データマージ手順(data merge procedure)」を使用することであり、次にこれについて以下の取り決めを用いながら図5および図11に基づき説明する:
DMS: MSシステム内にしか存在していないデータ
DR/3: OLTP−R/3システム内にしか存在していないデータ
DMix: 両方のシステムに存在しているデータ
図11に示されているように、MSシステムからのデータがシステム固有のデータオブジェクト(BDoc)としてOLTP−R/3システムへ伝送するために用意される場合、それにはDMS,DR/3,DMixがキーとして含まれる。OLTPアダプタOLTP−ADにおいて、データDMSがBAPI呼出部BCから分配されてそこに保管される。その後、OLTPアダプタは残りの情報DMixおよびKMSをOLTP−R/3システムへ伝送する。ソースシステムKMSのキーはターゲットシステムOLTP−R/3システムにおいて分離され、補助データAMDというメモリ領域に保管される。
【0144】
ついでDMixデータは補助データDDによって補われる。これはターゲットシステム(OLTP−R/3システム)において生成されたデータオブジェクトを処理するために必要とされる。それらの補助データは通例、対応するデータフィールドのためのプリセット値(デフォルト値)である。
【0145】
その後、OLTP−R/3システムにおいて通常の処理が実行される。データはターゲットシステムにおいて一般に行われているロギングルーチンを用いることで非同期にチェックされ、データベースOLTP−DBに格納される。
【0146】
ロギングと関連して1つのイベントがトリガされ、このイベントはイベントディストリビュータEDによって殊に結果伝送部RSへ伝達され、結果伝送部はこれに応じてデータをロギングから受け取る。得られたデータパケットはDR/3,DMixおよびKR/3から成る。結果伝送部RSは保管されていたMSキーKMSを挿入し、MSシステムに関係しないデータDR/3を取り除く。その後、データパケットDMix,KMSおよびKR/3としてMSシステムへの伝送が行われる。MSシステム内において、保管されていたデータDMSが結果セーブエージェントRSAにより再び付け加えられ、その結果、データDMS,DMix,KMSおよびKR/3を有する完全なBDocが後続処理(たとえばデータベースCDにおける統合化およびそれに続くモバイルクライントMCへのレプリケーション)のために得られる。
【0147】
このようなデータマージ手順は、MSシステムからOLTP−R/3システムへのデータのアップデートごとに行われる。OLTP−R/3システムにおけるデータ変更(デルタダウンロード)にあたりこの手順の一部分がロギングルーチンからスタートして実行されるが、その際には当然ながらMSキーKMSを加えることはできない。これはその場合には上述のようにしてキージェネレータKGによって生成される。
【0148】
3.ダウンロード
データベースシステムの融合における基本的な目標は、各システムにおいて共通に利用されるデータを別個にメンテナンスしなくても済むようにし、互いに融合されたデータベースシステム中に存在するデータを共通に利用できるようにすることである。たとえばCRMフロントオフィスシステムは、企業のERPバックオフィスシステム内に格納されているカスタマ情報および製品情報に関するデータをアクセスすることができるようにしなければならない。
【0149】
4.初回データダウンロード
このためまずはじめに以下の役割が課される。すなわち、既存の第1のデータベース(ソースシステムAここではOLTP−R/3システム)におけるデータであって、インプリメントされている別のデータベースシステム(ターゲットシステムBここではMSシステム)によっても必要とされるデータが、初回データダウンロード(Initial Download)にあたりシステムAからシステムBへ伝送する。この関連で本発明によれば以下のような問題解決手段が提案される。
【0150】
既存のバックオフィスシステム(以下ではこのことをOLTP−R/3システムと称するがこれによっても汎用性が制約されるものではない)におけるデータ量は通例、非常に多い。したがって、他のシステムと交換すべきデータを詳しく指定する手段を提供しなければならない。本発明においてはこのことは有利にはフィルタリングによって行われる。
【0151】
このようなフィルタリングのために図7を参照しながら説明した抽出部が用いられ、これはOLTP−R/3システムによって提供される。この場合の特殊性は、抽出部マスタのかたちでMSシステムに対する標準化されたインタフェースが適用され、このインタフェースを介してMSシステムにおけるすべての問い合わせが行われることである。つまり、ターゲットデータシステムMSが標準化されたインタフェースを介してそのシステムが必要とするデータに対する要求を、ソースシステムOLTP−R/3にインプリメントされている抽出部へ伝送することによって、データがフィルタリングされる。
【0152】
さらに別の問題点は、初回データダウンロードをリーズナブルな時点で行えるようにすることである。このことは、一般にバックオフィスシステムに設けられている手段によって実現できない。なぜならばそのような手段は非常に大きいデータ量を迅速に伝送するようには構成されていないからである。本発明によればこの問題点は有利には、先に詳しく説明したバルク指向BDocと呼ばれる特別なデータコンテナを提供することによって解決される。
【0153】
さらに初回データダウンロードにおける問題点は、ターゲットデータベースシステムに伝送されるデータがソースデータベースシステムのきちんと定められた状態と規定の時点(スナップショット snapshot)で一致するよう保証することである。従来ではこの問題点は、初回データダウンロード中はソースデータベースシステムを変更に対しブロックすることで解決されており、あるいは変更が許可されているのであるならば、ソースデータベースの特別な手段を利用することで解決しているが、そのような手段によってデータベースに対し初回データダウンロードの独立したオペレーションが妨げられる。
【0154】
このような部分的な問題点を解決するため、本発明によれば以下でオンライン同期手順(online sync procedure)と呼ぶ方法が提案され、これについて図12を参照して説明する。この場合、ソースシステムOLTP−R/3にインプリメントされている抽出部は、ターゲットシステムMS内に格納されているフィルタ定義FDにより制御され抽出部マスタインタフェースEMを介して呼び出されるのであるが、この抽出部は通常はブロックで読み出され送出されるかたちで動作し、その際にこれはソースデータベースのダイナミックなデータ変更を無視する。このため、ターゲットシステムにより必要とされるデータバルクは矢印IL(Initial Load)の付された経路で伝送される。
【0155】
しかしこれと並行して、結果伝送部RSによる既述のデルタハンドリングも実行される。これにより、ソースシステム内で初回データダウンロード中に生じた変更がキューに格納される。通常のデルタダウンロード動作とは異なりこのキューはアンロックされるのではなく、初回データダウンロード期間中はロックされる(Queue-Stop QS)。初回データダウンロード終了後に変更キューがアンロックされ、初回データダウンロード中に実行された変更が矢印DL(Deltaload)によってシンボリックに表されたデルタダウンロードチャネルを介してターゲットシステムMSへ伝送される。このようにして、初回データダウンロード終了時点に関して一致した「スナップショット」が生じる。
【0156】
b)デルタダウンロード
デルタダウンロードの機能についても、上述の(殊に図5に基づく)説明ならびにデータマージ手順についてなされた説明が関連する。ここでの目的は、初回データダウンロード後に動作実行中、ソースデータベースシステムAとつながっているすべてのシステムに対しそれぞれ変更を加えることである。
【0157】
この機能は2つのサブステップで提供される:
a)実施された変更についてソースデータベースシステムに通知
b)変更およびその処理ならびに後続処理のためそれに続いてターゲットデータベースシステムへ転送
通例、実施された変更について通知するために変更ポインタが用いられるけれども、これは著しい欠点をもっている。まず第1に、起こり得る変更ごとにソースデータベースシステムのアプリケーションに変更ポインタを設けなければならない。これはたいていすべてのデータオブジェクトについて不可能なことであるが、少なくとも非常に手間がかかるしクリティカルなエラーの原因となる。他方、変更の通知はまえもって定められたタイムインターバルでしか行われない。
【0158】
このような部分的な問題点を解決するため、本発明によれば有利にはイベント技術が利用される。ソースデータベースシステムにおけるデータベースOLTP−DBへ変更を加えるルーチンに、イベント発生が組み込まれる。イベントディストリビュータEDを介して、イベントに対する予約を扱うファンクションモジュールがイベント発生時に呼び出される。このファンクションモジュールには、ターゲットデータベースシステムの相応のモジュール(図5では結果セーブエージェントRSAのコンポーネント)が属している。このようにしてMSシステムにおけるOLTP−R/3アダプタ(つまり一般的にいえばターゲットシステムのモジュール)は、ターゲットシステムに関連するソースデータベースシステム内の変更に関する情報をほぼ同時に受け取る。
【0159】
これに続いて行われるソースデータベースシステムからターゲットデータベースシステムへの変更の伝送は、ターゲットデータベースシステム内に格納されている既述のフィルタ基準FD(図12)に基づき実施される。その後、上述のデータマージ手順を用いてデータが処理され、やはりすでに説明したやり方でシステムを超えたクロスシステムプライマリキー(cross-system primary key)が生成される。
【0160】
データ伝送のその他の特殊性として挙げられるのは、(殊にデルタダウンロードにあたり)以下で説明するネットフィールド決定(net-field determination)が用いられることである。
【0161】
互いに無関係に同じデータセットにアクセスする多数のユーザによって実施される変更が相互に書き換えられるのを最小限に抑えるために有利であるのは、個々のデータセットにおいて変更されたフィールドだけを伝送することである。このことをネットフィールド伝送(net-field transmission)と称する。しかしながら、たとえばOLTP−R/3システムなどのようなERPバックオフィスシステムは一般に「すべて込みのフィールドないしはオールフィールド(all-field)」ベースでしか通信できず、つまりこのシステムはフィールド内容全体を伴ってデータセット全体を一度に伝送するだけである。したがってデータはデータチャネルDL(図12)を介してオールフィールドベースでターゲットシステムMSに転送され、これはそのような転送が結果伝送部RSによってトリがされたときに行われる。この欠点は本発明の有利な実施形態によれば次のようにして解消される。すなわち、ターゲットシステムつまり統合データベースCDのデータベースサービスCDSにおいて、フィールド平面における有効な変更が統合データベースCDの内容との比較により求められ、実際の変更だけがネットフィールドベースで後続処理に関与させるのである。
【0162】
詳しくはこれがどのように行われるかについて、次に図13および図14を参照しながら説明する。
【0163】
ネットフィールド伝送を支援するため、BDoc(すなわちターゲットデータベースシステムのデータオブジェクト)のすべてのセグメント、変更されたフィールドを反映するフィールドが挿入される。このフィールドを送信ビットフィールド send-bit field SBF と称する。これはたとえばRAW(32)タイプのものとすることができ、バイナリ表示で(好適にはHEXで格納されるかたちで)変更を受けたフィールドに対応する各ポジションにおいて「1」を有している。図13には、送信ビット情報SBFとフィールド情報FINとの対応関係が描かれている。この場合、消去も変更として表される。図示の事例ではたとえばフィールド1およびフィールド4のフィールド内容が(「A」と「C」に)変更されており、フィールド2およびフィールド8のフィールド内容が消去されている。付加的なフィールドSBFのフィールド内容は、フィールドの個数に対応するビット数をもつ関連部分Rと無視される非関連部分Lによって構成されている。
【0164】
データセットがオールフィールドベースでターゲットデータベースシステムへ転送される場合、ターゲットデータベースシステムMSのデータベースとの調整が行われる。この調整はデータベースCDのデータベースサービスCDSにおいて実行され、これについては図14に描かれている。この場合、データセットD1は、変更されたフィールド内容「X」をもちオールフィールドベースで伝送されるデータセットの実例である。データベースサービスCDSはそのデータセットを、データベースCD内に格納されている対応するデータセットD1′と比較し、内容「X」をもつフィールドだけが変更されていることを確認する。これに従い、変更された情報だけをもつデータセットD2が生成される。対応する送信ビットは「1」にセットされている。残りのフィールド内容は空にされている。
【0165】
c)同期合わせ
冒頭で説明したコンテキストにおけるセマンティックな統合とは、システム間の単純なデータ交換以上のことを意味している。可能性に応じてアプリケーションの動作を、有効データの処理の基礎を成すロジック(ビジネスロジック "business logic")に近づけるようにする。ビジネスロジックは、個々のデータベースシステムのレポジトリに格納されている制御データに高度に反映されており、それらはたとえば値の範囲、フィールドやレコードやデータベースの妥当性などのようなロジックをマッピングする。このためセマンティックな統合においては、レポジトリ制御情報もクロスシステムでレプリケーションされるようにする。OLTP−R/3システムの事例では、これはいわゆるカスタマイズテーブル(Tテーブル)である。しかしながらカスタマイズテーブルにおける変更は、OLTP−R/3システムでは変更ポインタによってもイベントによっても指示されない。このため適切な更新メカニズムを利用できなければ、MSシステムなどのターゲットデータベースシステムにおいてこれらのデータのレプリカは急速に古くなってしまう。
【0166】
このような事例においてもソースシステムとターゲットシステムとの間でデータ状態を絶えず同期合わせできるようにする目的で、すでに挙げたコンポーネント「リクエスト」および「コンペア」が使われる。図15および図16には、これによって実現される同期メカニズムが示されている。
【0167】
リクエストコンポーネントは、すでに説明したように初回データダウンロードと同じように動作する。任意のビジネスオブジェクトをOLTP−R/3システムからMSシステムへダウンロードするために、汎用抽出部 general extractor GEと呼ばれるモジュールが用いられ、これはフィルタ定義FDに従い抽出部マスタEMによって呼び出される。
【0168】
このようにしてダウンロードされたデータが統合データベースCDへ取り込まれる前に、図15においてCOMPの付されたコンペアモジュールが呼び出される。このコンペアモジュールはダウンロードされたデータをすでにデータベースCD内に存在しているデータと比較し、実際に変更されたデータだけを通過させる。さらにこのモジュールは、もはやオリジナル中には存在していないデータに対する消去指示も発する。
【0169】
図16にはこのために使用されるアルゴリズムが示されている。準備過程においてまずはじめにOLTP−R/3システムから受け取ったデータおよびこれに対してそれぞれ対応するデータベースCDからのテーブルが、それぞれメモリロケーションS2もしくはS2に用意される。データベースCDから対応するテーブルを選択する際、MSシステム内にしか含まれていないすべてのレコード(図16ではレコードレコードm1,m2)は選択されないよう、データがフィルタリングされる。その他のレコードにもMS固有のデータを有するフィールドが含まれている。データ伝送時のさらに別の制限によって、メモリ領域S1にはOLTP−R/3システムにおいても利用可能なデータだけが供給されるようになる。
【0170】
ついでメモリ領域S1とS2の内容の比較が行われ、これによればテーブルの一方が基準として選択され、そのテーブルにういて最初から最後まで段階的に進められ、他方のテーブルにおいて対応するエントリが探索される。この場合、パフォーマンスの理由で有利であるのは、エントリの個数の僅かな方のメモリテーブル(図16ではメモリ領域)を基準として選択することである。比較結果に依存して以下のような相応のアクションが導入される:
新しいエントリの生成: ”I”
ネットフィールドエントリの生成: ”U”
消去指示の生成: ”D”
アルゴリズムは以下のように表すことができる:
4.アップロード
既述のように、データベースシステムのセマンティックな統合の基本的な要素は、データのエントリや変更を1つのデータベース内だけでなく互いに結合された複数のデータベースまたはすべてのデータベースにおいて実行できるようにすることである。したがってたとえば、外勤従業員はカスタマにおいて新たなデータ(たとえば新たなオーダ)を自身のポータブルコンピュータに入力し、そのデータセットにおけるそのような変更をデータベースOLTP−DBにおいて持続的なものとすることができるようにすべきである。
【0171】
モバイルクライアントのレベルにおける変更は、図2を参照しながら説明したトランザクション層によって登録され、その際、このトランザクション層を介してモバイルクライアントはMSシステムおよびその固有のローカルデータベースLDと通信する。ポータブルコンピュータがミドルウェアサーバMSと接続される場合、変更されたデータがBDocとして伝達され、バックオフィスシステムOLTP−R/3にも伝送される。このために用いられるコンポーネントは図5を参照しながらすでに説明しており、その際に実行されるデータマージ手順については図11を参照しながらすでに説明した。
【0172】
このようなデータアップロードにおける基本的な要求は適切なコンフリクト対策の開発であり、その目的は様々な場所でエントリされたり変更されたりする各データ間のコンフリクトを阻止することである。結合システムにおいてそのつど1つの特定の個所においてのみデータの変更を許可するようにしたいわゆる「データメンテナンス優位(data maintenance ascendencies)」の定義であると、十分な統合を提供することはできない。多くの適用事例において用いられているLOW(Last One Wins)方式も、ERPバックオフィスシステムのデータを含むこのような結合システムには適していない。
【0173】
したがって本発明においては、LSC(Leading System Concept)と称する新規のコンフリクト対策が用いられる。LSC方式は、各データオブジェクトごとに管理する側のシステム(FS)を定義する。結合システムにおける他のすべてのシステムは管理される側のシステム(GS)である。GSの各変更はまずはじめ、FSによって操作しなければならない。通常の操作機能に対する基本的な相違点は、これはアプリケーションの境界を超えたファンクションであり、構造に互換性のない各システム間のコンフリクトを解消するために用いられる。
【0174】
LSC方式のインプリメントのためには、あとで説明する特別な機能が必要とされる。
【0175】
ここで説明している実施例の場合、MSシステムはすべてのデータオブジェクトついて管理される側のシステムである。管理される側のシステムは、以下の要求を満たすことができなければならない。
【0176】
−ユーザはデータの表示においていつでもその確認状態(承諾、拒否、未定)を識別できなければならない。
【0177】
−ユーザは自身の変更したデータを拒否するときに再びもとの値にアクセスできなければならない。
【0178】
−データオブジェクトは変更が確認されるまでロックされてはならない。つまり同じデータオブジェクトにおいてチェックすべき複数の変更を先行のチェックの終了を待たずとも相次いで続けることができなければならない。
【0179】
−結合されたシステム全体におけるデータの一致性を保証しなければならない。
【0180】
これらの要求はとりわけ2つのファンクションモジュールによって満たすことができ、それらをペンディングカウンタ(PC)およびインボックス(IB)と称する。
【0181】
ペンディングカウンタはChar(4)フィールドであり、これはデータ交換に関与するテーブルごとに(つまりBDocの各セグメントに)存在する。このフィールドを介して、データの目下の確認状態が定義される。これによってコントロールフラグが形成され、これはデータの確認状態をたとえば画面上に視覚的に表示するためにアプリケーションプログラムによって評価される。
【0182】
ペンディングカウンタは以下のかたちをとる:
”O”: OK
P<n>: ペンディング(=保留、まだ確認されていない)、ここで<n>は基準カウンタとして変更の回数をカウントアップする。
【0183】
F<n>: データセットはエラー状態にある。
【0184】
ペンディングカウンタは変更のたびにカウントアップされ、管理する側のシステムによって確認されると再び”0”になるまで再びカウントダウンされる。拒否の場合にもカウントダウンされるが、”P”ではなく”F”がセットされる。
【0185】
システム全体のけるデータの一致性を保証するために必要とされるのは、変更が承認されないときにはもとのデータ状態が管理される側のシステムにおいて再び形成(ロールバック)されるようにすることである。これは有利には、管理する側のシステム(この実例ではOLTP−R/3システム)が拒否と同時に(上述のように)データオブジェクトに含まれている「先行状態のイメージ(before image)」BIを管理される側のシステムへ送り戻すことによって行われる。このようにしてオリジナル状態を取り戻すことでロールバックを行うことができる。
【0186】
しかしながらこのようなやり方の欠点は、これにより個々のデータオブジェクトにおけるユーザの変更すべてが上書きされることにある。たとえばこれが100個以上の項目を含むオーダであって、それが場合によっては比較的僅かな不一致ゆえに拒否された場合には、変更のもととなった誤りのあるデータオブジェクトつまりはそれゆえに承認されなかったデータオブジェクトのデータを再びユーザが利用できるようにしなければならない。これはインボックスによって行われる。この場合、ユーザはエントリを便利なように整合させることができ、再び利用可能にすることができる。
【0187】
図17には1つの実施例に基づき、ペンディングカウンタおよびインボックスのファンクションが描かれている。その際、LDの付された行は、ペンディングカウンタPCの状態を表すフィールドとプライマリキーフィールドKと3つのデータフィールドDをそれぞれ有するローカルデータベースの内容をシンボリックに表している。
【0188】
第1のステップにおいて、まん中のデータフィールドの内容が変更される。情報をOLTP−R/3システムへ伝達するBDocには、変更された情報「2」しか含まれていない。
【0189】
次のステップにおいて2つのデータフィールドが変更される。変更された情報「B」と「3」も同様にBDocとして伝送される。さらに第4のステップにおいて第1の変更の確認が行われ、第5のステップにおいて第2の変更の確認が行われる。ペンディングカウンタPCはそれぞれ確認状態を表す。
【0190】
第6のステップにおいて管理する側のシステムにとって承認されない変更が行われ、これには星型のシンボルが付されている。この変更はエラーメッセージ「E」として拒否され、その結果、第8のステップにおいてその変更前の状態がリストアされる。これと同時に、(拒絶された)変更された状態がインボックスに配置され、これによりユーザはそれについて処理を続けることができる。その間に第7のステップで行われた第1のフィールドにおける許可された変更が、第9のステップにおいて確認される。
【0191】
先行イメージ(before image)の生成は、リジェクトサービスを用いたMSシステムのフローコントロールの制御のもとで行われる。これはBDocのヘッダにセットされたフラグに基づき、BDoc全体が承認されたのか拒否されたのかをチェックする。拒否の場合、リジェクトサービスはBDocの全データを統合データベースCDから抽出し、それをBDoc内で先行イメージとして利用できるようにする。BDoc全体が承認されればリジェクトサービスはその部分セグメントをその状態についてチェックする。部分セグメントが拒否された場合にはその内容がやはり統合データベースCDから抽出され、先行イメージにおいて得られるようにする。
【0192】
管理する側のシステムはLSC手順において、到来するデータをチェックし必要であれば拒否できるようでなくてはならない。このような機能はバックオフィスシステムにおいては一般に実装されている。この関連でやはり重要なその他の機能についてはすでに説明した。これにはデータマージ手順との関連で説明した受け入れの事例におけるデータ補足や、同じく説明済みの管理する側のシステムのプライマリキーの伝送が含まれる。
【0193】
5.これまで説明してきた結合システムの拡充ならびに変形
これまで示してきた実施例では基本的に、CRMフロントオフィスシステムの中央計算部を成すミドルウェアサーバMSとERPバックオフィスシステムの実例としてのOLTP−R/3システムとの間のデータ交換について説明してきた。
【0194】
とはえいえ既述の手順やアルゴリズムを他の事例にも適用することができる。たとえばミドルウェアシステムMSは既述の手順を利用して様々な別のデータベースシステムと利用することができる。それらのデータベースの論理構造は処理されるオブジェクトのレベルで少なくともオーバラップ部分をもっている一方、それらの構造はプログラミング技術的実装のレベルでは互換性のないものである。したがってMSシステムを、既述の手順を利用して様々な外部のデータシステム間の交換システムとして利用することができる。
【図面の簡単な説明】
【図1】 オフライン分散型データベースにおける本発明による結合システムの環境の外観を示す図である。
【図2】 本発明において適用されるフロントオフィスシステムのアーキテクチャに関する概観をCRMシステムの実例で示す図である。
【図3】 図2によるシステムのフローコントロールの典型的な流れをデータアップロードプロセスの実例として示す図である。
【図4】 図2によるシステムで適用されるデータオブジェクト(”BDoc”)の構造を示す図である。
【図5】 本発明に従って互いに結合された2つのシステムにおいてデータのアップロードおよびダウンロード時にはたらくコンポーネントのアーキテクチャを示す図である。
【図6】 ダウンロードの事例に関する図3に応じたフローチャートを示す図である。
【図7】 関与するデータベースシステムに他のデータベースシステム内に含まれているデータを初回にダウンロードするためのコンポーネントのアーキテクチャを示す図である。
【図8】 必要とされるプライマリキーをシステムを超えて供給する方法を説明するための原理図である。
【図9】 BDocおよび属するキーマッピングテーブルのセグメント構造に関する実例を示す図である。
【図10】 いくらか複雑なセグメント構造を有する図9によるBDocの構造に関する実例である。
【図11】 本発明に適したデータマージ手順の原理を説明する図である。
【図12】 初回ダウンロードにおける基本コンポーネントの共働の様子を示す基本原理である。
【図13】 本発明に適したネットフィールド伝送手順を説明するための2つの図である。
【図14】 本発明に適したネットフィールド伝送手順を説明するための2つの図である。
【図15】 データを同期合わせする手順を説明するための基本コンポーネントの原理図である。
【図16】 本発明に適した「コンペア」モジュールの機能を説明するための基本原理図である。
【図17】 本発明に適したデータアップデート時のコンフリクトを解消する手順の原理図である。
Claims (14)
- コンピュータに格納されたコンピュータプロセッサ命令として実装された方法において、
前記コンピュータプロセッサ命令により、プロセッサと記憶手段と入出力手段を有する少なくとも1つのコンピュータがデータネットワークを介して、ソースデータベースシステム(A)のコンピュータに格納されているソースデータベースシステム(A)と、ターゲットデータベースシステム(B)のコンピュータに格納されているターゲットデータベースシステム(B)との間で、前記コンピュータの記憶手段に格納されているデータを交換し、
データベースシステム(A,B)の各々は個々のプライマリキー生成ロジックを用いて、該データベースシステム(A,B)双方のコンピュータに格納されているデータオブジェクトの一義的な識別を行って、前記少なくとも1つのコンピュータのプロセッサに対し、各データオブジェクトのための個々のシステム固有のプライマリキーを生成させ、前記データベース(A,B)双方のコンピュータに格納されている前記プライマリキー生成ロジックは互いに独立しており、キージェネレータ(KG)が前記少なくとも1つのコンピュータのプロセッサに対し命令を実行させ、該命令により前記少なくとも1つのコンピュータは、
a)前記ソースデータベースシステム(A)のコンピュータに格納されているソースデータベースシステム(A)から前記ターゲットデータベースシステム(B)のコンピュータに格納されているターゲットデータベースシステム(B)へ、データネットワークを介して伝送されるべきデータオブジェクトのためのソースデータベースシステムのプライマリキーを、キーマッピングテーブル(KMT)と比較し、該キーマッピングテーブルには、ソースデータベースシステム(A)およびターゲットデータベースシステム(B)におけるコンピュータのプロセッサによりすでに生成されているソースデータベースシステムプライマリキーおよび対応するデータベースシステムプライマリキーを有するすべてのデータオブジェクトのためのソースシステムプライマリキー(K A , K B )が格納されており、
b)該ソースデータベースシステムプライマリキーが前記キーマッピングテーブルに存在しないと判定されたことに応答して、前記キージェネレータを用いてターゲットデータベースシステムプライマリキーを自動的に生成して、ターゲットデータベースシステム(B)のコンピュータにおける前記記憶手段のデータオブジェクト内に該ターゲットデータベースシステムプライマリキーを格納し、前記キーマッピングテーブル(KMT)において前記ソースデータベースシステムプライマリキーといっしょに、前記ソースデータベースシステム(A)のコンピュータにおける記憶手段に格納し、
c)前記ソースデータベースシステム(A)のソースデータベースシステムプライマリキーが前記キーマッピングテーブルに存在していると判定されたことに応答して、該ソースデータベースシステム(A)のコンピュータにおける記憶手段の前記データオブジェクト内に、対応するターゲットデータベースシステムプライマリキーを格納することを特徴とする方法。 - 前記プライマリキージェネレータ(KG)を前記ターゲットデータベースシステム(B)のコンピュータ内に統合する、請求項1記載の方法。
- 前記ターゲットデータベースシステム(B)のプライマリキー(KB,KMS)は、前記ソースデータベースシステム(A)におけるコンピュータのデータベースに格納されているデータの一部分ではない、請求項1記載の方法。
- 前記ターゲットデータベースシステムプライマリキーは、前記ソースデータベースシステム(A)におけるコンピュータの記憶手段に格納されているデータベースのデータの一部分ではない、請求項2記載の方法。
- コンピュータプロセッサ命令により、前記ターゲットデータベースシステム(B)におけるコンピュータのプロセッサが、該ターゲットデータベースシステム(B)におけるコンピュータの記憶手段に格納されているデータオブジェクトを前記ソー スデータベースシステム(A)のコンピュータへ送り戻すとき、前記データベースシステム(A,B)におけるコンピュータのプロセッサは、前記ターゲットデータベースシステムプライマリキーを前記データオブジェクトから分離し、該データオブジェクトを前記ソースデータベースシステム(A)におけるコンピュータの記憶手段に格納する、請求項1記載の方法。
- 前記ソースデータベースシステムにおけるコンピュータのプロセッサは、該ソースデータベースシステム(A)におけるコンピュータをOLTP−R/3データベースシステムとして動作させるOLTP−R/3命令を実行する、請求項1記載の方法。
- 前記ターゲットデータベースシステムにおけるコンピュータのプロセッサは、前記ソースベースシステム(A)におけるコンピュータをミドルウェアサーバシステムとして動作させる命令を実行する、請求項1記載の方法。
- コンピュータにより読み取り可能な記憶媒体において、
プロセッサ、記憶手段および入出力手段を有するコンピュータ上で、少なくとも1つの一方のコンピュータにおけるソースデータベースシステム(A)と少なくとも1つの他方のコンピュータにおけるターゲットデータベースシステム(B)とでデータを交換する方法を少なくとも実行させる命令が格納されており、
前記コンピュータの記憶手段におけるデータベースシステム(A,B)各々は、格納されているデータオブジェクトの一義的な識別を、前記プロセッサによりデータオブジェクト各々に対し個々のシステム固有のプライマリキーを生成させる個々のプライマリキー生成ロジックを利用して行い、
前記の2つのデータベース(A,B)のプライマリキー生成ロジックは互いに独立しており、前記命令には、前記データベース(A,B)双方におけるコンピュータのプロセッサが前記少なくとも1つのコンピュータに対し命令を実行させるステップが含まれていて、該命令により前記コンピュータは、
a)前記ソースデータベースシステム(A)のコンピュータに格納されているソースデータベースシステム(A)から前記ターゲットデータベースシステム(B)のコンピュータに格納されているターゲットデータベースシステム(B)へ、データネットワークを介して伝送されるべきデータオブジェクトのためのソースデータベースシステムプライマリキーを、キーマッピングテーブル(KMT)と比較し、該キーマッピングテーブルには、ソースデータベースシステム(A)およびターゲットデータベースシステム(B)におけるコンピュータのプロセッによりすでに生成されているソースデータベースシステムプライマリキーおよび対応するデサータベースシステムプライマリキーを伴うすべてのデータオブジェクトのためのソースシステムプライマリキー(K A , K B )が格納されており、
b)前記ソースデータシステムプライマリキーが前記キーマッピングテーブルに存在しないと判定されたことに応答して、前記キージェネレータを用いてターゲットデータベースシステムプライマリキーを自動的に生成して、ターゲットデータベースシステム(B)のコンピュータにおける記憶手段のデータオブジェクト内に該ターゲットデータベースシステムプライマリキーを格納し、前記キーマッピングテーブル(KMT)においてソースデータベースシステムプライマリキーといっしょに、前記ソースデータベースシステム(A)のコンピュータにおける記憶手段に格納し、
c)前記ソースデータベースシステム(A)のソースデータベースシステムプライマリキーが前記キーマッピングテーブルに存在していると判定されたことに応答して、該ソースデータベースシステム(A)の少なくとも1つのコンピュータにおける記憶手段の前記データオブジェクト内に、対応するターゲットデータベースシステムプライマリキーを格納することを特徴とする、
コンピュータにより読み取り可能な記憶媒体。 - 格納されている前記命令により前記ターゲットデータベースシステム(B)におけるコンピュータのプロセッサは、前記プライマリキージェネレータ(KG)を前記ターゲットデータベースシステム(B)におけるコンピュータの記憶手段内に統合 する、請求項8記載の記憶媒体。
- 格納されている前記命令により前記データベースシステム(A,B)双方におけるコンピュータのプロセッサは、前記ソースデータベースシステム(A)におけるコンピュータに格納されているデータの一部分としてではなく、ターゲットデータベースシステムプライマリキーを格納する、請求項8記載の記憶媒体。
- 格納されている前記命令により前記データベースシステム(A,B)双方におけるコンピュータのプロセッサは、前記ソースデータベースシステム(A)におけるコンピュータの記憶手段に格納されているデータの一部分としてではなく、ターゲットデータベースシステムプライマリキーを格納する、請求項9記載の記憶媒体。
- 格納されている前記命令により前記ターゲットデータベースシステム(B)におけるコンピュータのプロセッサは、
前記ターゲットデータベースシステム(B)におけるコンピュータの記憶手段に格納されているデータオブジェクトを、前記ソースデータベースシステム(A)のコンピュータへ送り戻し、
前記ターゲットデータベースシステムプライマリキーを前記データオブジェクトから分離し、
該データオブジェクトを前記ソースデータベースシステム(A)におけるコンピュータの記憶手段に格納する、請求項8記載の記憶媒体。 - 格納されている前記命令により前記ソースデータベースシステムにおけるコンピュータのプロセッサは、該ソースデータベースシステムのコンピュータをOLTP−R/3データベースシステムとして動作させるOLTP−R/3命令を実行する、請求項8記載の記憶媒体。
- 格納されている前記命令により前記ターゲットデータベースシステムにおけるコンピュータのプロセッサは、前記ソースデータベースシステムのコンピュータをミドルウェアサーバシステムとして動作させる命令を実行する、請求項8記載の記憶媒体。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP99120009A EP1093061A1 (de) | 1999-10-14 | 1999-10-14 | Integriertes Datenbank-Verbundsystem |
EP99120009.8 | 1999-10-14 | ||
PCT/EP2000/009973 WO2001027806A1 (de) | 1999-10-14 | 2000-10-11 | Integriertes datenbank-verbundsystem |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006202842A Division JP4397385B2 (ja) | 1999-10-14 | 2006-07-26 | コンピュータに格納されたコンピュータプロセッサ命令として実装されている方法およびコンピュータにより読み取り可能な記憶媒体 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2003511796A JP2003511796A (ja) | 2003-03-25 |
JP3887564B2 true JP3887564B2 (ja) | 2007-02-28 |
Family
ID=8239147
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001530749A Expired - Lifetime JP3887564B2 (ja) | 1999-10-14 | 2000-10-11 | 統合型データベース結合システム |
JP2006202842A Expired - Lifetime JP4397385B2 (ja) | 1999-10-14 | 2006-07-26 | コンピュータに格納されたコンピュータプロセッサ命令として実装されている方法およびコンピュータにより読み取り可能な記憶媒体 |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006202842A Expired - Lifetime JP4397385B2 (ja) | 1999-10-14 | 2006-07-26 | コンピュータに格納されたコンピュータプロセッサ命令として実装されている方法およびコンピュータにより読み取り可能な記憶媒体 |
Country Status (10)
Country | Link |
---|---|
US (2) | US6845378B1 (ja) |
EP (3) | EP1093061A1 (ja) |
JP (2) | JP3887564B2 (ja) |
AT (2) | ATE231260T1 (ja) |
AU (1) | AU765461B2 (ja) |
CA (1) | CA2353845C (ja) |
DE (2) | DE50004826D1 (ja) |
DK (2) | DK1237098T3 (ja) |
IL (2) | IL143509A0 (ja) |
WO (1) | WO2001027806A1 (ja) |
Families Citing this family (79)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030046017A1 (en) | 2001-06-06 | 2003-03-06 | Claudius Fischer | Deployment console for use with a computer system deploying software to remotely located devices |
US7464097B2 (en) | 2002-08-16 | 2008-12-09 | Sap Ag | Managing data integrity using a filter condition |
US7127475B2 (en) | 2002-08-15 | 2006-10-24 | Sap Aktiengesellschaft | Managing data integrity |
US7257818B2 (en) | 2002-08-29 | 2007-08-14 | Sap Aktiengesellschaft | Rapid application integration using functional atoms |
US7213227B2 (en) | 2002-08-29 | 2007-05-01 | Sap Aktiengesellschaft | Rapid application integration using an integrated development environment |
US7225425B2 (en) | 2002-08-29 | 2007-05-29 | Sap Aktiengesellschaft | Rapid application integration |
US7269665B2 (en) | 2002-08-29 | 2007-09-11 | Sap Ag | Isolated mapping point |
US7171432B2 (en) | 2002-08-29 | 2007-01-30 | Sap Aktiengesellschaft | Phased upgrade of a computing environment |
US7237225B2 (en) | 2002-08-29 | 2007-06-26 | Sap Aktiengesellschaft | Rapid application integration using reusable patterns |
US7277940B2 (en) * | 2002-08-29 | 2007-10-02 | Sap Ag | Managing uneven authorizations in a computer data exchange |
US7263698B2 (en) | 2002-08-29 | 2007-08-28 | Sap Aktiengesellschaft | Phased upgrade of a computing environment |
US7206910B2 (en) * | 2002-12-17 | 2007-04-17 | Oracle International Corporation | Delta object replication system and method for clustered system |
EP1611524A4 (en) * | 2003-03-19 | 2008-10-29 | Unisys Corp | SERVER CONSOLIDATION ANALYSIS |
US8519158B2 (en) * | 2004-03-12 | 2013-08-27 | Ligand Pharmaceuticals Incorporated | Androgen receptor modulator compounds and methods |
US7707432B2 (en) | 2004-08-13 | 2010-04-27 | Sap Ag | Enabling communication between an application program and services used by the application program |
US7593916B2 (en) * | 2004-08-19 | 2009-09-22 | Sap Ag | Managing data administration |
US7506006B2 (en) | 2004-09-03 | 2009-03-17 | Microsoft Corporation | Synchronization for smart clients |
US20060080468A1 (en) * | 2004-09-03 | 2006-04-13 | Microsoft Corporation | Smart client add-in architecture |
US7558783B2 (en) | 2004-09-03 | 2009-07-07 | Microsoft Corporation | Conversion between application objects and smart client objects |
WO2006031921A2 (en) * | 2004-09-15 | 2006-03-23 | Adesso Systems, Inc. | System and method for managing data in a distributed computer system |
US8140594B2 (en) * | 2004-09-17 | 2012-03-20 | Sap Ag | Advanced message mapping with sub-object key mapping |
US7457794B2 (en) | 2004-10-14 | 2008-11-25 | Sap Ag | Searching for customized processing rules for a computer application |
US7756809B2 (en) | 2004-10-14 | 2010-07-13 | Sap Ag | Apparatus and product of manufacture using execution points to select conditions and rules for business transaction processing |
US7756808B2 (en) | 2004-10-14 | 2010-07-13 | Sap Ag | Apparatus and product of manufacture for using condition data structures separately from rule data structures in business transactions |
US7761396B2 (en) | 2004-10-14 | 2010-07-20 | Sap Ag | Apparatus and product of manufacture for adaptive business transaction rule structures |
US7457793B2 (en) | 2004-10-14 | 2008-11-25 | Sap Ag | Investigating execution of a customized transaction process in a computer application |
US7457792B2 (en) | 2004-10-14 | 2008-11-25 | Sap Ag | Customizing transaction processing in a computer application by using pre-defined functions |
US7386578B2 (en) | 2004-10-29 | 2008-06-10 | Sap Ag | Associations between duplicate master data objects |
US7461091B2 (en) | 2005-06-09 | 2008-12-02 | Sap Aktiengesellschaft | Controlling data transition between business processes in a computer application |
US20070143305A1 (en) * | 2005-11-02 | 2007-06-21 | Sourcecode Technology Holding, Inc. | Methods and apparatus for storing functions associated with an electronic form |
US7996758B2 (en) * | 2005-11-02 | 2011-08-09 | Sourcecode Technologies Holding, Inc. | Methods and apparatus for storing data associated with an electronic form |
US20070130138A1 (en) * | 2005-11-02 | 2007-06-07 | Sourcecode Technology Holding, Inc. | Methods and apparatus for storing a collaboratively designed workflow process |
US20070208777A1 (en) * | 2005-11-02 | 2007-09-06 | Sourcecode Technology Holding, Inc. | Methods and apparatus for designing a workflow process using resource maps and process maps |
US20070136367A1 (en) * | 2005-11-02 | 2007-06-14 | Sourcecode Technology Holding, Inc. | Methods and apparatus for dynamically modifying a business object definition |
US8010940B2 (en) | 2005-11-02 | 2011-08-30 | Sourcecode Technologies Holdings, Inc. | Methods and apparatus for designing a workflow process using inheritance |
US20070143711A1 (en) * | 2005-11-02 | 2007-06-21 | Sourcecode Technology Holding, Inc. | Methods and apparatus for displaying a setup sequence |
US8224853B2 (en) * | 2005-11-02 | 2012-07-17 | Sourcecode Technologies Holdings, Inc. | Methods and apparatus for updating a plurality of data fields in an electronic form |
US8239226B2 (en) * | 2005-11-02 | 2012-08-07 | Sourcecode Technologies Holdings, Inc. | Methods and apparatus for combining properties and methods from a plurality of different data sources |
US9514163B2 (en) | 2005-11-17 | 2016-12-06 | International Business Machines Corporation | Database consolidation tool |
US7778965B2 (en) * | 2006-05-23 | 2010-08-17 | Sap Ag | Systems and methods for common instance handling of providers in a plurality of frameworks |
US7797322B2 (en) * | 2006-07-13 | 2010-09-14 | Sap Ag | Negative key mapping |
US8495519B2 (en) * | 2006-11-27 | 2013-07-23 | Sourcecode Technologies Holdings, Inc. | Methods and apparatus for displaying interprocess communication thumbnails |
US20080155518A1 (en) * | 2006-11-27 | 2008-06-26 | Sourcecode Technology Holding, Inc. | Methods and apparatus for tokenizing workflow process objects |
US20080155330A1 (en) * | 2006-11-27 | 2008-06-26 | Sourcecode Technology Holding, Inc. | Methods and apparatus for debugging a workflow process |
WO2008067312A2 (en) * | 2006-11-27 | 2008-06-05 | Sourcecode Technology Holding, Inc. | Methods and apparatus for modeling a workflow process in an offline environment |
US8141128B2 (en) * | 2007-02-20 | 2012-03-20 | Source Code Technologies Holdings, Inc. | Methods and apparatus for building and executing natural language workflow functions |
WO2008116218A1 (en) * | 2007-03-22 | 2008-09-25 | Sourcecode Technology Holding, Inc. | Providing context sensitive templates for a web based workflow design |
US20080306806A1 (en) * | 2007-03-23 | 2008-12-11 | Sourcecode Technology Holding, Inc. | Methods and apparatus for dynamically allocating tasks |
US20080270475A1 (en) * | 2007-04-27 | 2008-10-30 | Sap Ag | Data processing systems and methods for connecting business objects to data sources |
US20090037397A1 (en) * | 2007-05-03 | 2009-02-05 | Sourcecode Technology Holding, Inc. | Methods and apparatus for providing context search results in process design |
EP2145297A4 (en) * | 2007-05-08 | 2012-05-30 | Sourcecode Technology Holding Inc | METHODS AND APPARATUSES FOR EXPOSING DEFINITIONS OF WORKFLOW PROCESSES AS COMMERCIAL OBJECTS |
EP2171581A4 (en) * | 2007-05-24 | 2012-05-02 | Sourcecode Technology Holding Inc | METHODS AND APPARATUSES FOR MODELING COLLABORATIVE PROCESSES |
US20090024558A1 (en) * | 2007-07-16 | 2009-01-22 | Sap Ag | Methods and systems for storing and retrieving rejected data |
US7899835B2 (en) * | 2008-02-28 | 2011-03-01 | Caterpillar, Inc. | Method and system for reviewing business activity of a business entity |
US7996357B2 (en) | 2008-02-29 | 2011-08-09 | Plaxo, Inc. | Enabling synchronization with a difference unaware data source |
US7991740B2 (en) * | 2008-03-04 | 2011-08-02 | Apple Inc. | Synchronization server process |
US8655858B1 (en) * | 2008-11-13 | 2014-02-18 | Amazon Technologies, Inc. | Digital content reconstruction and distribution |
US8738584B2 (en) * | 2009-02-17 | 2014-05-27 | Microsoft Corporation | Context-aware management of shared composite data |
US8463743B2 (en) * | 2009-02-17 | 2013-06-11 | Microsoft Corporation | Shared composite data representations and interfaces |
US8739124B2 (en) | 2012-06-27 | 2014-05-27 | Sap Ag | Configuring integration capabilities for system integration |
US9015608B2 (en) * | 2012-07-16 | 2015-04-21 | Sap Se | Regenerating a user interface area |
US8924848B2 (en) * | 2012-07-16 | 2014-12-30 | Sap Se | Synchronizing a user interface area |
US8996565B2 (en) * | 2012-12-18 | 2015-03-31 | Sap Se | Systems and methods for in-memory database processing |
US9811687B2 (en) | 2013-03-15 | 2017-11-07 | International Business Machines Corporation | Common location of user managed authorization |
US10331765B2 (en) | 2013-05-24 | 2019-06-25 | Sourcecode Technology Holdings, Inc. | Methods and apparatus for translating forms to native mobile applications |
CN104216914B (zh) | 2013-06-04 | 2017-09-15 | Sap欧洲公司 | 大容量数据传输 |
US9231959B2 (en) | 2013-07-12 | 2016-01-05 | Sap Se | Multiple transaction interface framework |
US20150039656A1 (en) * | 2013-08-01 | 2015-02-05 | Synchronoss Technologies, Inc. | Enterprise address management system and a method thereof |
US9535933B2 (en) * | 2013-09-03 | 2017-01-03 | Acxiom Corporation | System and method for representing change values |
CN104268234B (zh) * | 2014-09-26 | 2018-05-29 | 东软集团股份有限公司 | 一种基于sql语句的数据同步方法和装置 |
JP6842071B2 (ja) * | 2016-05-31 | 2021-03-17 | 株式会社東新システム | データ交換システム、データ交換方法、及びデータ交換プログラム |
CN108319451B (zh) * | 2017-01-16 | 2021-09-07 | 医渡云(北京)技术有限公司 | 医疗数据补充方法和装置 |
US11120025B2 (en) * | 2018-06-16 | 2021-09-14 | Hexagon Technology Center Gmbh | System and method for comparing and selectively merging database records |
US11562033B2 (en) * | 2018-08-30 | 2023-01-24 | Open Text Sa Ulc | Systems and methods for enhanced content management interoperability services interfaces and repository integration |
CN110928867B (zh) * | 2018-08-31 | 2022-09-20 | 杭州海康威视数字技术股份有限公司 | 一种数据融合的方法及装置 |
US11696528B2 (en) * | 2019-10-11 | 2023-07-11 | Deere & Company | Settings propagation and synchronization across mobile work machines |
KR102345148B1 (ko) * | 2019-12-26 | 2021-12-29 | 조상근 | 생산물류 erp 자동화 시스템의 협력사 및 고객사의 상호연결관계 파라미터의 설정방법 |
JP6886055B1 (ja) * | 2020-02-28 | 2021-06-16 | 株式会社ビズリーチ | 制御装置及び制御方法 |
US20240281427A1 (en) * | 2023-02-22 | 2024-08-22 | Jpmorgan Chase Bank, N.A. | Method and system for utilizing a de-normalized master table structure for the processing of subscriptions |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4714995A (en) * | 1985-09-13 | 1987-12-22 | Trw Inc. | Computer integration system |
US5333316A (en) * | 1991-08-16 | 1994-07-26 | International Business Machines Corporation | Locking and row by row modification of a database stored in a single master table and multiple virtual tables of a plurality of concurrent users |
US5459860A (en) * | 1992-10-05 | 1995-10-17 | International Business Machines Corporation | Computerized system and process for managing a distributed database system |
US5873096A (en) | 1997-10-08 | 1999-02-16 | Siebel Systems, Inc. | Method of maintaining a network of partially replicated database system |
US5778373A (en) | 1996-07-15 | 1998-07-07 | At&T Corp | Integration of an information server database schema by generating a translation map from exemplary files |
US5870765A (en) * | 1996-10-09 | 1999-02-09 | Oracle Corporation | Database synchronizer |
US5937402A (en) * | 1997-06-19 | 1999-08-10 | Ontos, Inc. | System for enabling access to a relational database from an object oriented program |
US6385618B1 (en) * | 1997-12-22 | 2002-05-07 | Sun Microsystems, Inc. | Integrating both modifications to an object model and modifications to a database into source code by an object-relational mapping tool |
US6233585B1 (en) * | 1998-03-12 | 2001-05-15 | Crossworlds Software, Inc. | Isolation levels and compensating transactions in an information system |
US6625621B2 (en) * | 2000-01-04 | 2003-09-23 | Starfish Software, Inc. | System and methods for a fast and scalable synchronization server |
-
1999
- 1999-10-14 EP EP99120009A patent/EP1093061A1/de not_active Withdrawn
-
2000
- 2000-10-11 CA CA002353845A patent/CA2353845C/en not_active Expired - Lifetime
- 2000-10-11 AT AT00974383T patent/ATE231260T1/de active
- 2000-10-11 EP EP02010023A patent/EP1237098B1/de not_active Expired - Lifetime
- 2000-10-11 DK DK02010023T patent/DK1237098T3/da active
- 2000-10-11 EP EP00974383A patent/EP1151399B1/de not_active Expired - Lifetime
- 2000-10-11 AT AT02010023T patent/ATE256889T1/de active
- 2000-10-11 AU AU12716/01A patent/AU765461B2/en not_active Expired
- 2000-10-11 DE DE50004826T patent/DE50004826D1/de not_active Expired - Lifetime
- 2000-10-11 DE DE50001091T patent/DE50001091D1/de not_active Expired - Lifetime
- 2000-10-11 JP JP2001530749A patent/JP3887564B2/ja not_active Expired - Lifetime
- 2000-10-11 IL IL14350900A patent/IL143509A0/xx active IP Right Grant
- 2000-10-11 US US09/857,864 patent/US6845378B1/en not_active Expired - Lifetime
- 2000-10-11 DK DK00974383T patent/DK1151399T3/da active
- 2000-10-11 WO PCT/EP2000/009973 patent/WO2001027806A1/de active IP Right Grant
-
2001
- 2001-05-31 IL IL143509A patent/IL143509A/en unknown
-
2004
- 2004-01-02 US US10/749,557 patent/US7143079B2/en not_active Expired - Lifetime
-
2006
- 2006-07-26 JP JP2006202842A patent/JP4397385B2/ja not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
DE50001091D1 (de) | 2003-02-20 |
EP1151399A1 (de) | 2001-11-07 |
CA2353845C (en) | 2006-03-14 |
DE50004826D1 (de) | 2004-01-29 |
ATE256889T1 (de) | 2004-01-15 |
EP1093061A1 (de) | 2001-04-18 |
EP1237098B1 (de) | 2003-12-17 |
IL143509A (en) | 2007-08-19 |
JP2003511796A (ja) | 2003-03-25 |
US6845378B1 (en) | 2005-01-18 |
AU765461B2 (en) | 2003-09-18 |
ATE231260T1 (de) | 2003-02-15 |
DK1151399T3 (da) | 2003-04-07 |
JP4397385B2 (ja) | 2010-01-13 |
IL143509A0 (en) | 2002-04-21 |
US20040143606A1 (en) | 2004-07-22 |
WO2001027806A1 (de) | 2001-04-19 |
EP1151399B1 (de) | 2003-01-15 |
CA2353845A1 (en) | 2001-04-19 |
EP1237098A1 (de) | 2002-09-04 |
AU1271601A (en) | 2001-04-23 |
US7143079B2 (en) | 2006-11-28 |
DK1237098T3 (da) | 2004-03-15 |
JP2007012079A (ja) | 2007-01-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3887564B2 (ja) | 統合型データベース結合システム | |
US6910053B1 (en) | Method for data maintenance in a network of partially replicated database systems | |
US7366460B2 (en) | System and method for mobile data update | |
US7386575B2 (en) | System and method for synchronizing related data elements in disparate storage systems | |
US7310653B2 (en) | Method, system, and product for maintaining software objects during database upgrade | |
US4714996A (en) | Impact calculation for version management in a distributed information service | |
US5475833A (en) | Database system for facilitating comparison of related information stored in a distributed resource | |
US6240416B1 (en) | Distributed metadata system and method | |
US6256667B1 (en) | Intelligent messaging | |
US20050135273A1 (en) | Data management system and method for propagating product manufacturing information to disparate information systems | |
US20070011205A1 (en) | Data management system and method for propagating product manufacturing information to disparate information systems | |
US7213208B2 (en) | Data container for interaction between a client process and software applications | |
US20150046524A1 (en) | Data Management for Mobile Data System | |
EP0226734A2 (en) | Method and apparatus for managing obsolescence of data objects | |
US20070136265A1 (en) | Apparatus, system, and method for automated identity relationship maintenance | |
US8805785B2 (en) | Shared storage of categorization, labeling or tagging of objects in a collaboration system | |
US6941309B2 (en) | Object integrated management system | |
US20060271384A1 (en) | Reference data aggregate service population | |
EP1638019A2 (en) | Advanced object mapping by mapping key sub-object | |
US20040054640A1 (en) | Interaction between a client process and software applications | |
CN115730022A (zh) | 采用事件触发和流程编排的数据处理构建方法及平台系统 | |
JP2000137504A (ja) | 分散生産管理システム | |
JPH06290098A (ja) | 分散データベース処理方法 | |
JP4593290B2 (ja) | マスタデータ管理における配信 | |
WO2004025456A2 (en) | Interaction between a client process and software applications |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060127 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20060424 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20060501 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060726 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20061027 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061127 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3887564 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091201 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101201 Year of fee payment: 4 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101201 Year of fee payment: 4 |
|
RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: R3D02 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111201 Year of fee payment: 5 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121201 Year of fee payment: 6 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131201 Year of fee payment: 7 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |