JP2003511796A - 統合型データベース結合システム - Google Patents
統合型データベース結合システムInfo
- Publication number
- JP2003511796A JP2003511796A JP2001530749A JP2001530749A JP2003511796A JP 2003511796 A JP2003511796 A JP 2003511796A JP 2001530749 A JP2001530749 A JP 2001530749A JP 2001530749 A JP2001530749 A JP 2001530749A JP 2003511796 A JP2003511796 A JP 2003511796A
- Authority
- JP
- Japan
- Prior art keywords
- data
- database
- database system
- oltp
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 claims abstract description 79
- 230000008859 change Effects 0.000 claims description 31
- 238000012545 processing Methods 0.000 claims description 31
- 238000013507 mapping Methods 0.000 claims description 29
- 230000008569 process Effects 0.000 claims description 16
- 238000003860 storage Methods 0.000 claims description 9
- 238000012790 confirmation Methods 0.000 claims description 8
- 238000012986 modification Methods 0.000 claims description 6
- 230000004048 modification Effects 0.000 claims description 6
- 230000004044 response Effects 0.000 claims description 4
- 238000012795 verification Methods 0.000 claims description 2
- 230000000153 supplemental effect Effects 0.000 claims 4
- 238000004590 computer program Methods 0.000 claims 3
- 244000309464 bull Species 0.000 claims 1
- 238000012937 correction Methods 0.000 claims 1
- 230000010354 integration Effects 0.000 abstract description 15
- 230000005540 biological transmission Effects 0.000 description 37
- 230000006870 function Effects 0.000 description 34
- 239000003795 chemical substances by application Substances 0.000 description 25
- 238000010586 diagram Methods 0.000 description 25
- 230000000875 corresponding effect Effects 0.000 description 23
- 230000010076 replication Effects 0.000 description 13
- 238000000605 extraction Methods 0.000 description 10
- 230000004927 fusion Effects 0.000 description 8
- 230000009471 action Effects 0.000 description 7
- 238000004891 communication Methods 0.000 description 7
- 238000012546 transfer Methods 0.000 description 6
- 238000007726 management method Methods 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 230000008878 coupling Effects 0.000 description 4
- 238000010168 coupling process Methods 0.000 description 4
- 238000005859 coupling reaction Methods 0.000 description 4
- 230000001419 dependent effect Effects 0.000 description 4
- 230000001960 triggered effect Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 239000000284 extract Substances 0.000 description 3
- 238000001914 filtration Methods 0.000 description 3
- 239000011232 storage material Substances 0.000 description 3
- 238000013459 approach Methods 0.000 description 2
- 238000009826 distribution Methods 0.000 description 2
- 230000008676 import Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 238000002360 preparation method Methods 0.000 description 2
- 239000000047 product Substances 0.000 description 2
- 238000012384 transportation and delivery Methods 0.000 description 2
- 101000642819 Solanum tuberosum Soluble starch synthase 1, chloroplastic/amyloplastic Proteins 0.000 description 1
- 101000642821 Triticum aestivum Starch synthase 1, chloroplastic/amyloplastic Proteins 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- SILSDTWXNBZOGF-KUZBFYBWSA-N chembl111058 Chemical compound CCSC(C)CC1CC(O)=C(\C(CC)=N\OC\C=C\Cl)C(=O)C1 SILSDTWXNBZOGF-KUZBFYBWSA-N 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 230000011218 segmentation 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
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)
Abstract
Description
。
割を果たしている。
とデータベース管理システムによって構成されている。そしてそれらは、データ
ベースに格納されているデータが多種多様に処理されるような広範囲に及ぶコン
ピュータアプリケーションの基礎を成すことが多い。
e Planning)システムであり、たとえばドイツ連邦共和国 Walldorf のSAP 社に
よる OLTP-R/3 などである。それらによって人事や販売や在庫管理など様々な企
業分野におけるEDP支援を、1つの共通の中央データベースに基づき実現する
ことができる。この種のシステムはバックオフィスシステムと呼ばれることが多
い。
それらはしばしばSFA(Sales Force Automation)またはCRM(Customer R
elation Management)システムと呼ばれる。この種のシステムは殊に、カスタマ
アドバイス、カスタマサポートならびに販売におけるEDP要求に合わせてカス
タマイズされている。これには、企業の外勤従業員にポータブルコンピュータを
装備させ、このコンピュータによりデータベースシステムのモバイルクライアン
ト(mobile client)として、個々の外勤従業員が必要とするデータ(たとえば
その従業員の地区のカスタマに関するデータやその従業員の販売状況に関するデ
ータ)をもつ固有のローカルデータベースが提供される。このようなシステム(
フロントオフィスシステムと呼ばれることが多い)には、やはりデータベースを
有する中央コンピュータが含まれており、そのデータベースにはモバイルクライ
アントのデータの総計が格納されている。つまりこれはオフライン分散型データ
ベースシステムである。モバイルクライアントのほかにCRMシステムの中央コ
ンピュータとは他の外部のシステムも通信を行うことができ、たとえばカスタマ
のEDPシステムなどがそれを行うことができ、このシステムは一時的にまたは
定常的なデータコネクションを介して中央コンピュータに接続される。
雑である。それらのシステムのためには様々なコンポーネント間の通信能力、デ
ータ保全性およびデータの同期を確保するためにパワフルな方法がそれぞれ必要
とされ、その際、著しく多くのユーザ数を通信に含めることができるよう考慮し
なければならない。
れている一方で、構造的に互換性はないがかなりの部分で同じ(業務)データを
管理しているデータベースシステムを互いに融合させる確かな方法はまだない。
たとえばERPシステムでは通常、企業のカスタマに関する大規模なデータセッ
ト(たとえば住所、仲介者、処理されたオーダや仕入れ状況に関するデータなど
、また、補充交換部品納入に重要なカスタマのマシン装備に関するデータなど)
が格納されている。広範囲にわたり一致しているデータセットはCRMシステム
においても必要とされる。しかし実際には両方のシステムは、相互に互換性のな
いまったく異なるデータ構造をもっている。
ポートを受けて実行されるタスクである。(たとえば原価、個数、運搬費、およ
び場合によっては特別な条件を考慮した)一貫した業務の流れが基礎を成してい
るにもかかわらず、種々のデータベースシステムへの実装は完全に異なっている
ことがよくあり、つまり業務処理のインプリメントに利用されるアルゴリズム(
いわゆるビジネスロジック "Businesslogik")は非常に異なっている。とはいえ
当然ながら、価格決定を種々異なるシステムにおいてできりかぎり等しく取り扱
えるようにして同じ結果が得られるようにする必要がある。
題なくデータ交換できるよう相互に融合することである。ここでシステムの「融
合」とは、技術レベルでの結合を超えて、データ同期を実現し、それぞれ異なる
システムにおいてほぼ同じ動作が得られるような制御ロジックの交換を可能とす
ることである。複数のサブシステムから成る統合された1つの結合システムへの
このような融合を、ここではセマンティック・システムインテグレーション("s
emantic system integration")と称する。このためにはたとえば、 −システムの確実な技術的結合 −融合されたシステムにおける有効データの同期合わせ −融合されたシステムをコントロールするためのカスタマ固有の整合(カスタマ
イズデータ)の同期合わせ −データ変更の食い違いや他のデータ不一致が発生したときの適切なコンフリク
ト解消法 が必要とされる。
みのハードウェアテクノロジーおよびソフトウェアテクノロジーを利用すること
ができる。この場合、キューメカニズムが重要な役割を果たし、これによれば各
データ単位が正確に1回で伝送され(guaranteed delivery)、データが精確に
決められた順序で伝送されるようになる(In-Order-Processing)。セマンティ
ックなシステム統合のこのような部分的な観点については詳しく説明する必要は
ない。
に一般に出発点となり得るのは、様々なデータベースシステムがソフトウェア製
品の様々な「世界」に属する可能性のあることである。本発明の課題は、このよ
うな問題点を解決するシステムコンポーネントおよび方法を提供することである
。
たがってそれらのデータ構造を相互にマッピングしなければならない。しかもデ
ータ内容の整合が必要とされる(たとえば用語の使い方としてあるシステムの「
カスタマ customer」は別のシステムでは「バイヤ buyer」に対応している)。
これら両方の機能は、互換性のない2つのシステム間のデータ交換においてスタ
ンダードな役割設定である。慣用のシステム統合はこのような形式のコネクショ
ンに関するものである。これによれば、統合システム全体において有効でなけれ
ばならないデータの新たなエントリを、複数のシステムのうち中央システムと称
する1つのシステムにおいてのみ、データベース結合システム全体に対して有効
に実施することができる。しかしこのことは多くの事例において、たとえばCR
MシステムとERPシステムとの融合においては不十分である。なぜならばその
場合、重要な新たなデータは企業のヘッドオフィスにおいても(つまりERPシ
ステムにおいても)カスタマサポートにおいても(つまりCRMシステムにおい
ても)生じるものであり、新たに取り込まれた後には結合システム全体で利用で
きなければならないからである。
の新たなエントリを結合システムの各サブシステムにおいて実行できるようにし
ようという場合(つまり新たなエントリ実行後にけつごうしすてむのすべてのサ
ブシステムにおいて利用できるようにしようという場合)、そのためにはいかな
る時点でもデータオブジェクト識別のためシステムを超えて一義的なプライマリ
キーを利用できるようにしなければならない。その際、このようなプライマリキ
ーを数値範囲の割り当てやGUID(Global Unified Identifier)キーの割り
当てによって生成することが知られている。とはいえこれら両方のやり方は汎用
的に利用できるものではない。
を生成するために同じアルゴリズムが必要とされる。このことはそれぞれ異なる
メーカのシステムにおいて保証することはできない。また、同じメーカの種々の
システムであっても、様々なキー生成手順の実装されていることが多い。
すべてのシステムがGUID手順を利用しているときだけである。このこともや
はり多くの事例において保証できないことである。
つのデータベースシステムAとBとの間でデータを交換するための以下のような
方法が提案される。すなわちこの方法によれば、データベースシステムの各々は
、格納されているデータオブジェクトの一義的な識別のため、各データオブジェ
クトごとにプライマリキー生成ロジックを用いてシステム固有のプライマリキー
を生成し、両方のデータベースシステムAおよびBのプライマリキー生成ロジッ
クは互いに独立している。ここにおいて、ソースデータベースシステムAからタ
ーゲットデータベースシステムBへ伝送されるデータオブジェクトについて、シ
ステムを超えてクロスシステムで共有される新しいエントリに必要とされる一義
的な識別を可能にするため、 a)ソースデータベースシステムAからターゲットデータベースシステムBへ
伝送すべきデータオブジェクトのプライマリキーをキーマッピングテーブルと比
較するステップを実行し、該キーマッピングテーブルは、すでに2つのプライマ
リキーの生成されているすべてのデータオブジェクトのプライマリキーを有して
おり、 b)プライマリキーが前記キーマッピングテーブル内にまだ存在していなけれ
ば、自動的にターゲットデータベースシステムBのプライマリキーを生成してデ
ータオブジェクト内に格納し、ソースデータベースシステムAのプライマリキー
といっしょに前記キーマッピングテーブルに格納するステップと、 c)ソースデータベースシステムAのプライマリキーが前記キーマッピングテ
ーブル内で見つけられたならば、ターゲットシステムBの対応するプライマリキ
ーをデータオブジェクトに格納するステップを実行する。
成ロジックを使用しており、それらのロジックが互いにチューニングされていな
いような事例であっても、システムを超えて一義的なプライマリキーの生成(つ
まりはシステムを超えて共有される新たなエントリの実行)が実現される。この
場合、関与しているシステムの制御データメモリ(レポジトリ)内にキーロジッ
クが定義される。また、キージェネレータを用いて両方のロジックが互いにマッ
ピングされる。
トにおいて実行された変更に基づき第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)が実行される。
セットにおいて実行された変更に基づき第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)が実行される。
システム内におけるデータの新たなエントリまたは変更のための方法が提案され
る。これによれば、前記統合システムにおけるデータベースシステムのうち任意
の1つのデータベース内で共有されるデータを新たにエントリする際にデータコ
ンフリクトを避けるため、各データベースシステム間で交換可能な各データオブ
ジェクトごとに前記データベースシステムの一方を管理する側のシステムFSと
して定義し、該管理する側のシステムFSのデータセットにも属するデータオブ
ジェクトのデータを、管理される側のシステムGSにおいて新たにエントリまた
は変更するたびに、システムを超えた確認アルゴリズムを実行し、該アルゴリズ
ムにおいて、 a)変更を含むデータオブジェクトを管理する側のシステムFS(OLTP−
R/3)に伝送し、 b)管理する側のシステムFS内で、変更の承認または少なくとも部分的な拒
否として応答メッセージを生成し、 c)応答メッセージを含むデータオブジェクトを管理される側のシステムGS
(MS)へ送り戻す。
説明する特徴は、本発明の有利な実施形態を実現する目的で個別に用いることも
できるし、互いに組み合わせて使用することもできる。
環境の外観を示す図である。
ャに関する概観をCRMシステムの実例で示す図である。
ップロードプロセスの実例として示す図である。
)の構造を示す図である。
ップロードおよびダウンロード時にはたらくコンポーネントのアーキテクチャを
示す図である。
ある。
れているデータを初回にダウンロードするためのコンポーネントのアーキテクチ
ャを示す図である。
するための原理図である。
する実例を示す図である。
に関する実例である。
基本原理である。
ための2つの図である。
の原理図である。
本原理図である。
順の原理図である。
の適用事例は、販売EDPソリューション(Sales Force Automation; SFA)と
中央ERPシステムとの統合に関する。図1には、その種のシステムの周囲環境
に関する概観が描かれている。
、その従業員はカスタマ(Customer)Cと相談してたとえばカスタマの注文をと
る。外勤従業員SRは各々ポータブルコンピュータをもっており、これをモバイ
ルクライアント(Mobile Client)MCとも称し、ローカルデータベース(Local Database)LDに属している。ポータブルコンピュータはネットワークのノー
ドを成しており、これは常にネットワークと接続されているわけではなく、した
がってオフラインノードと称する。
スタマや製品の基本データ(マスタデータ)を格納している。外勤従業員SRは
たとえば注文情報を入力し、また、未処理の注文や処理済みの注文についての状
況の情報を得る。これらの機能を一時的に自律的に実現できるようにする目的で
、そのために必要とされるすべてのデータがローカルデータベースLDに格納さ
れている。
れによって有利にはオンライントランザクションプロセッシングを行うことがで
きる。ここに示されている実例ではこれはOLTP−R/3システムである。図
面および以下の説明ではそのシステムの用語で表すが、汎用性を制約するわけで
はない。これにはデータベースOLTP−DBが含まれている。その基本データ
は内勤従業員(In-House-Employee)IHEによってメンテナンスされる。
−R/3システムはフロントオフィスサーバと接続されており、これをミドルウ
ェアサーバ(MS Middleware Server)と呼ぶが、はやり汎用性を制約するわけ
ではない。このシステムもデータベースCD(Condolidated Database)を有し
ている。
テムを接続することができる。図示されているように、本部HOには外部システ
ムBWが配置されており、これはたとえばいわゆる "Business Information War
ehouse" として企業にとって重要な販売情報を分析する。これはデータベースB
W−DBを有している。図示されている事例の場合、これはバックオフィスサー
バOLTP−R/3からもMSシステムからもデータを受け取る。外勤フィール
ドFDにおいてたとえば、ネットワーク内の付加的なノードを成すカスタマシス
テム(Customer System)CSを常に(オンライン)または一時的に(オフライ
ン)MSシステムと接続することができる。このようにすればたとえば、カスタ
マの注文を外勤従業員を介在することなく処理することができる。
イアントMC、OLTP−R/3、オプションの外部システムBWおよびカスタ
マシステムCS)を有しているが、それらは互いに独立していない。それらはM
Sシステムによって結合され、このシステムによれば各サブスクライバが自身に
必要とされる許された情報を受け取るようになる。図示されている事例の場合、
ミドルウェアサーバMSは同時にこのような結合機能も果たし、これとモバイル
クライアントから成るCRMシステムの中央コンピュータを成しており、これは
オフライン分散型データベースシステムである。これが中央データベースシステ
ムOLTP−R/3と融合される。しかしながら本発明の基本原理をデータベー
スシステム融合に関する他の事例にも適用可能であり、つまりたとえば、2つま
たは複数の中央データベースシステムの融合あるいは2つまたは複数の分散型デ
ータベースシステムの融合にも適用することができる。
タマリレーションシップマネージメント Customer Relationship Management CR
M)に必要とされるすべての情報が含まれている。これは統合データベースCD
(consolidated data base)とも呼ばれる。なぜならばこれには(直前のデータ
交換時点で)ポータブルコンピュータにおけるすべてのローカルデータベースL
Dの内容が含まれているからである。これにより、ローカルデータベースLDに
必要なデータを供給して、たとえばデータの変更を伝達したり必要に応じてロー
カルデータベースLDをリストアすることができるようになる。
えば電話回線、インターネットまたはイントラネットを介して、MSシステムと
接続される。この場合、直前の接続以来収集されたデータがMSシステムに伝送
される。しかもポータブルコンピュータはその機会に、それぞれ先行する期間に
おける自身の固有の処理データと、(必要なかぎり)他のポータブルコンピュー
タおよび別のシステムの新たな入力データを受け取る。
ど業務処理に関連するので)ビジネスデータと呼ばれる。OLTP−R/3シス
テムの場合にはそこからビジネスオブジェクト("BDoc")が形成され、これは別
の処理のためのデータコンテナとして用いられる。たとえばある特定のオーダの
ためのビジネスオブジェクトはそのデータベース内に格納されているそのオーダ
に属するすべてのデータを有しており、これはそれらのデータがどのようにその
論理構造(リレーショナルデータベースのテーブル)内にあるかとは無関係であ
る。この構造はOLTP−R/3システムにとって知られているものであり、同
じようにして他のバックオフィスシステムにも適用される。
ータは、個々のデータベースにおける論理的に別個の部分に格納されており、こ
れをレポジトリと称する。
ティックである。これはひとたび設定されると、個々の企業における業務の流れ
の変更を比較的長い期間で変える必要がないかぎり、そのまま保持される。
ある。たとえば特定の販売地区に対する外勤従業員の管轄は頻繁に変わる可能性
が多い。このような変更によってそのつどデータ伝送のための基準の変更が生じ
る。それというのも、それぞれ必要とされる最小データだけをポータブルコンピ
ュータへ伝送すべきだからである。同じ理由で、ポータブルコンピュータ内で古
くなったデータを消去しなければならず、他方、最近になって重要になったデー
タを追加する必要がある。データ伝送基準は有利には、MSシステム内でいわゆ
るパブリケーション(publication)およびサブスクリプション(subscription
)として格納される。モバイルクライアントMCへの伝送基準およびデータの更
新プロセスを、以下ではリアライメント(realignment)と称する。
ので、ポータブルコンピュータへの伝送時にコピーする必要がある。1つよりも
多くの受信側へのこのような伝送を、以下ではレプリケーション(replication
)と称する。
にはモバイルクライアントMCが描かれ、下方にはOLTP−R/3システムお
よび外部システムBWが描かれている。図の他の部分には、データベースCDお
よびそれに属するメッセージ伝送サーバ(Message Transfer Server)MTSを
含めてMSシステムが示されている。
したがってその機能を複数のマシンに分散させることができ、たとえばデータベ
ースのために1つの別個のマシンを使用し、要求処理のために1つまたは複数の
マシンを使用することができる。メッセージ伝送サーバとして動作するマシンは
、全体としてアドミニストレーションステーション(アドミンステーション Adm
in Station)ASと称する。メッセージ伝送サーバMTSおよびそれに属するア
ドミニストレーションコンソール(アドミンコンソール Admin Console)ACは
有利には、Windows NT (登録商標)によって動作する1つのマシンにインスト
ールされる。その結果生じる可能性のあるマシンの境界は図中、破線で描かれて
いる。
用され、これをBDocと称する。これはモバイルクライアントMCとMSシス
テムとの間の通信にも用いられる。この場合、様々な種類のBDocを区別する
ことができる: −ポータブルコンピュータMCとフロントオフィスサーバCRM−MSとの間で
トランザクション結果とステータス情報を伝送するため、トランザクションBD
ocが使用される。それらを以下のようにさらに区別することができる: トランザクションBDocはトランザクション結果をモバイルクライアントM
CからMSシステムへ搬送する。この場合、モバイルクライアントがBDocを
成し、これはトランザクションの結果を有しており、それをMSシステムへ送信
する。
ンBDocの処理成功を表す。トランザクションBDocの処理がうまくいった
ならば、BDocのステータスがそれ相応に変化し、それを送ったモバイルクラ
イアントへ承認メッセージとしてBDocが送り戻される。この承認メッセージ
には、たとえばOLTP−R/3システムによって提供された付加的なデータあ
るいは統合データベースCDの変更された値も含まれている。その際、承認BD
ocには、変更された値だけまたはすべての値が含まれている。
のトランザクション結果をMSシステムからモバイルクライアントMCへ伝送す
る。インポートBDocにも、変更された値だけがまたはすべての値が含まれて
いる。さらにインポートBDocは、モバイルクライアントMCとは別のソース
からのデータ変更をMSシステムからモバイルクライアントへ伝送するためにも
利用される。
MSシステムにおいてエラーの発生したことを表す。この場合、エラーセグメン
トがBDocに挿入され、送信を行ったモバイルクライアントMCへエラーBD
ocとして送り戻される。エラーセグメントは、種々のエラー状態を表示するた
めに種々のレコードを有することができる。さらにエラーBDocには、「先行
の状態のイメージ」(before images)としてもとの値も含まれている。すべて
のフィールドは、統合データベースCDの目下の内容で満たされている。
イナリデータを伝送するために使用される。
ロード時などにMSシステムからモバイルクライアントMCへ大量のデータを伝
送するために使用される。
ができる。BDocをたとえば「カスタマ」、「オーダ」などとすることができ
る。
ばれるファンクションモジュールを用いて行われる。サービスは、BDocに適
用できる特別なファンクションを提供する。アダプタは特殊なタイプのサービス
であり、これによればMSシステム外におけるシステムとのコネクションが可能
となる。
ルデータベースLDとの通信も、もっぱらトランザクション層(Transaction La
yer)TLを介して行われる。パートレプリケートデータベースネットワークシ
ステム(part-replicated data base network system)の実例としてのミドルウ
ェアサーバMSとモバイルクライアントとのデータ交換にについての詳細は、国
際出願 PCT/DE00/01552 に示されており、これを本出願の参考文献とする。
のような特徴を有している。
取り、BDocをそのモバイルクライアントに伝送する。データ伝送はそれぞれ
1つのモバイルクライアントMCによって導入される。たとえばその目的で、Mi
crosoft の通信テクノロジーDCOMを利用することができる。
ージ用アダプタ(Inbound Message Adapter)IMAによって行われる一方、逆
方向で伝送されるメッセージは送出メッセージ用アダプタ(Outbound Message A
dapter)OMAによって伝送される。このようなデータ伝送は、qRFC(queu
ed Remote Function Call)と称するプロトコルによって行われる。これは処理
の順序を決定するためにキュー(queue)を利用するリモートファンクションコ
ールプロトコルである。
Cである。フローコントロールFCはBDocの処理を行い、到来するBDoc
を適正な順序でサービスおよびアダプタへルーティングし、必要であればエラー
処理プロシージャをトリガする。これはすべてのサービスおよびアダプタに対し
同じインタフェースを介して行われる。他方、このインタフェースにおけるメイ
ンパラメータはBDocである。フローはBDocタイプ固有に制御データメモ
リ(レポジトリ Repository)内で定義されている。
れ固有のアダプタOLTP−ADもしくはBW−ADを介してMSシステムと接
続されている。つまり外部システムはやはり各々固有のアダプタタイプをもって
おり、これもBDoc固有にレポジトリ内に定義されている。アダプタおよびそ
れに接続された外部システムとの間のデータ伝送チャネルのプロトコルおよびデ
ータ構造は、外部システムのタイプに固有のものである。
ータベース(consolidated database)CDに相応のデータを格納するために用
いられる。このサービスCDSは、データをデータベースに書き込むときにデー
タ一致性のチェックを実行しない。そのようなチェックは、データをMSシステ
ムへ伝送するコンポーネント(たとえばモバイルクライアントMCまたはOLT
P−R/3システム)によって実行する必要がある。データベースCDの読み出
しのため他のサービスはサービスCDSを利用するのではなく、図示されていな
い特別なハンドラを利用し、これはサービス、アダプタまたは他のハンドラから
呼び出される。
をもっている。レプリケーションパートは処理されたBDocを引き継ぎ、その
受け取り側を決定する。いっそう迅速に処理するため、そのために必要とされる
情報がルックアップテーブルから読み出される。目下処理されているBDocに
基づきルックアップ情報の変更の必要性をレプリケーションパートが確認すると
、そのレプリケーションパートはリアライメントハンドラをトリガする。リアラ
イメントハンドラはレプリケーションルールを評価して、必要とされるルックア
ップ情報を生成する。さらにリアライメントハンドラは受け取り側に対し新たな
データを提供し、不必要なデータを消去する命令を出す。この目的でリアライメ
ントハンドラは特別なハンドラを用いる。
論理的なデータの流れについてシステム全体を管理するために、アドミニストレ
ーションコンソールACが利用される。
けるフローコントロールの典型的な流れが示されている。この場合、フローコン
トロールFCのメッセージプロセッサ(Message Processer)MPによって実行
されるステップが、MP−FCと付された列に描かれている。第1および第3の
列には、サービスにより実行される処理ステップが示されている。最後の列には
、OLTP−R/3システムによって実行される処理ステップが示されている。
が(RFCを介して)到来メッセージIMAのためのアダプタを呼び出したとき
に始まる。到来メッセージIMAのためのアダプタによってメッセージプロセッ
サMP−FCがスタートする。
基本的に2つのフロープロシージャを区別することができ、1つは少なくとも部
分的にOLTP−R/3システムに関連するBDocタイプの処理のためのもの
であり、1つはその他のBDoc(MSシステム内でのみ巡回する)のためのも
のである。
して、メッセージプロセッサMPは呼び出される第1のサービスもしくはアダプ
タを決定する。(少なくとも部分的に)OLTP−R/3システムに関連するB
Docのタイプのために、第1のサービスとしてOLTP−R/3アダプタOL
TP−ADが呼び出される。その他のBDocのためにはOLTP−R/3アダ
プタは呼び出されない。BDocのタイプのためにOLTP−R/3アダプタを
呼び出すか否かの判定は、フローの決定時に下されており、つまりこのフロー内
では下されない。
BDocが本当にOLTP−R/3システムに関連するものなのかを決定する。
このことは必ずしもあてはまらない。それというのもOLTP−R/3システム
に対する関連性はBDocにのみ左右されるのではなく、その内容にも左右され
る可能性があるからである。1つの実例は、ビジネスオブジェクトタイプ「カス
タマ」のBDocである。このようなBDocにカスタマに関する情報が含まれ
ているならば、それはOLTP−R/3システムへ送られるが、販売渉外担当(
sales and distribution contact)に関する情報が含まれているなら、それはM
Sシステム内にしか格納されない。
が判定したならば、そのアダプタはそれに対してコールを送り、進行中のフロー
を中断する。OLTP−R/3システムにおける処理の終了後、それによってO
LTP−R/3アダプタへコールが送られ、そのアダプタは結果を引き継ぎ、フ
ローを再びスタートさせて、フローコントロールFCのメッセージプロセッサM
Pを呼び出す。
のかを決定する。BDocがOLTP−R/3システムに関連していないことを
OLTP−R/3アダプタが検出すると、そのアダプタはメッセージプロセッサ
MP−FCへコントロールを戻し、この場合もそのプロセッサは次に呼び出すべ
きサービスを決定する。
出される。このサービスは、BDocに含まれているデータを統合データベース
CD内で持続させる。
ーションおよびリアライメントサービスRPMが呼び出される。このサービスの
機能は、BDocがレプリケーション情報に作用を及ぼすか否かをチェックする
ことである。作用を及ぼすのであればリアライメントハンドラに対し、ルックア
ップ情報を更新しビジネスデータ分配のためにBDocを生成するオーダが形成
される。レプリケーションおよびリアライメントサービスRPMの第2のアクシ
ョンは、目下のBDocに受け取り側リストを追加することである。
達するために準備処理する目的で、送出メッセージOMA用のアダプタが呼び出
される。
DocはエラーBDocとして(つまりエラー情報を含むBDocとして)マー
キングされる。アップデートオペレーションにおいてリジェクトサービスは有効
な値を統合データベースCDから読み出す。すべてのオペレーションにおいて、
モバイルクライアントMCの先行の状態がマークされる。ついでBDocは、そ
れを送ってきたポータブルコンピュータへ送り戻される。そこにおいて相応のト
ランザクションが新たに実行される。
る。当然ながらエラー処理ルーチンも設けられているが、それについてはここで
は詳しく説明しない。
上部にはBDocタイプの定義構造が示されており、これはMSシステムのレポ
ジトリに格納されている。さらに下部には、同様にレポジトリ内に格納されてい
るBDoc自体の構造が描かれている。
から成る。BDocヘッダBDocヘッダ−Hにはコントロール情報が含まれて
おり、たとえばBDocのタイプ(「カスタマ」、「オーダ」...)、その送
り手(モバイルクライアントMC)ならびにタイムスタンプなどが含まれている
。さらにプライマリキーの複製も含まれていると、パフォーマンスの理由から有
利である。
ta Record)DRには本来のデータが含まれている。この構造は属するデータセ
グメント(Data Segment)DSの定義中で規定されている。このセグメントは、
実際の物理的なテーブルにおける一種のテーブルビューを成している。オプショ
ンとしてBDocにはさらに、1つまたは複数のエラーレコードER(Error Re
cord)をもつエラーセグメントESも含まれる。
ルドから成る。それらの領域に消去情報が含まれているならば、キーフィールド
だけに有効なデータが含まれている。また、それらの領域に「インサート」情報
または「アップデート」情報が含まれているならば、すべてのデータフィールド
に有効なデータが含まれているかまたは、変更されていないフィールドにプリセ
ット値(たとえば0.0)が含まれている。フィールドが満たされているのか利
用されていないのかを表す目的で、いわゆる「送信ビット」が使用される。この
場合、レプリケーションおよびリアライメントにあたり考慮しなければならない
プライマリキーとフィールドが常に(変更された否かとは無関係に)送られる。
送信ビットがセットされるのは、値が実際に変更されたときだけである。
イプ固有の構造に関する情報BDocは、BDocタイプの定義("BDoc Type D
efinition")内に含まれており、これはBDocボディ定義BDoc−BDとB
Docセグメント定義BDoc−SDから成る。BDocボディ定義BDoc−
BDは正確に1つのルートセグメントを有しており、これにはただ1つのデータ
レコードだけが含まれている。この条件は遵守しなければならず、その目的はB
Doc中に含まれている情報がそれぞれ個々のノードシステムへ伝達できるよう
にまたは別のやり方で処理できるようにするためである。たとえばタイプ「カス
タマ」のBDoc中には、ただひとりのカスタマに関する情報だけしか格納して
はならず、そうすることによってカスタマ情報を個々に所期のように個々のカス
タマごとに相応のノードシステムへ導くことができるようになるからである。相
前後するセグメントのデータレコードには依存するデータが含まれており、たと
えばカスタマのマシン装備に関するデータなどが含まれている。当然ながらこの
場合、1つのセグメントに対し複数のレコードを設けることができる。
ocの物理的な再生においてはそのような階層はない。階層関係は、依存するセ
グメントのデータレコードDRがそれらの上位のデータレコードのキーを有する
ことにより、BDoc内に収容されている。トランザクションBDocの場合に
はさらに(エラーレコード Error Record ERをもつオプションのエラーセグメ
ントを除いて)依存しないセグメントが設けられており、これをルートセグメン
トと称する。
Cが変更前に有していた値がMSシステムにとって重要である可能性がある。そ
のような「先行状態のイメージ」(before image)は固有のデータ領域に伝達さ
れ、それらは相応に特徴づけられている。
へ伝送するために、サービス指向BDocが用いられる。サービス指向BDoc
のボディは、一般情報をもつルートセグメントとバイナリデータを含むメモセグ
メントから成る。
Client Setup)およびリアライメント中のデータ伝送のために使用される。バル
ク指向BDocもタイプ固有に(つまりたとえばオブジェクトタイプ「カスタマ
」などのために)定義されている。とはいえそれらは、そのルートセグメントに
ただ1つのレコードだけしか収容してはならない、という制約を受けない。した
がってたとえばバルク指向BDocは複数のカスタマのデータを一度に伝送する
ことができる。
Sシステムとリンクする。これはデータを双方向で伝送するために用いられる。
データたとえばカスタマの注文がモバイルクライアントMCに入力され、OLT
P−R/3システムに転送される場合、これを「アップロード」と呼ぶ。データ
がOLTP−R/3システムに入力され、そこからMSシステムへ転送される場
合、これを「ダウンロード」と称する。
タダウンロード(Initial Download)によって、MSシステムの統合データベー
スCDはオペレーションの開始にあたりOLTP−R/3システムからのデータ
で満たされる。オンラインユーザがデータをOLTP−R/3システムへ入力し
、変更されたオブジェクトがMSシステムへ転送されるとき、デルタダウンロー
ドが行われる。このようなデルタダウンロードは、すべてのデータ形式について
可能なわけではない。これらの機能が利用できないならば、第3のダウンロード
メカニズムが使用され、これを以下では同期メカニズムと称する。
びOLTP−R/3システムのコンポーネントが示されている。MSシステムの
構成部分は、BDocの処理に必要とされるプロセスステップをコーディネート
するためのフローコントロールFC、OLTP−R/3アダプタOLTP−AD
ならびに3つのエージェントであり、それらはキージェネレータ(Keygenerator
)KG、マッピングエージェントMAおよびマージエージェント(Merging-Agen
t)MEAと称する。これらのエージェントはOLTP−R/3アダプタのため
の補助機能を果たす。
gramming Interface)SBを呼び出すためのコールフレームCFであり、これは
BDocの処理中に呼び出すことができる。スタンダードBAPIは変更を持続
的なものにするため、アップデートファンクションモジュール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システムへは、それに関連しないデータは伝送されな
い。
付加的にインプリメントされたOLTP−R/3システムの構成部である。
処理される。この処理のステップとして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システムにおい
て呼び出される。
って新たなオブジェクトを生成しようという場合にコールフレームは、そのオブ
ジェクトがすでに存在していてMSシステムの相応の要求に応じて生成されてい
るかのかについてチェックする。そうであればビジネスオブジェクトの新たな生
成の代わりにすでに処理されたデータが抽出され、MSシステムへ伝送されて戻
される。コールフレームの第2の役割は、MSシステムにおけるキーおよびオブ
ジェクトリファレンスとOLTP−R/3システムのキーおよびオブジェクトリ
ファレンスとの間で必要とされるマッピングを保証することである。さらに第3
の役割はコミットサイクルのハンドリングである。これにより、ただ1つのコミ
ットサイクルでBAPI処理が実行されるようになる。その結果、バックオフィ
スシステムOLTP−R/3へのデータの格納ならびにフロントオフィスシステ
ムMSへのデータの伝送が、1つの共通の処理単位で行われるようになる。
ことである。このためコールフレームは、それが受け取ったBDocの構造を汎
用的なBAPIの構造に置き換えるために必要とされるすべての情報を有してい
る。BAPIはBDocのデータを処理し、アップデートファンクションモジュ
ールUFMに対する呼び出しを有している。このファンクションモジュールは、
コールフレームがコミット命令をスタンダードBAPIへ出したときに稼働し始
める。アップデートファンクションモジュールはデータベースにおけるデータの
変更を持続的なものにする。さらにこのモジュールはイベントを発し、そのイベ
ントはイベントディストリビュータEDのサブスクライバへ分配される。これら
のサブスクライバの1つは結果伝送部RSである。これは変更されたデータを発
せられたイベントのパラメータとして受け取り、それを結果データAMDと混合
してそれをMSシステムへ伝送する。
Doc構造へマッピングして戻す。マージエージェントMEAは、OLTP−R
/3システムから到来した結果をMSシステムにおけるBDocと混合する。そ
の後、結果セーブエージェントRSAはBDocのためのフローコントロールを
開始し、BDocのステータスを変えて "OLTP Complete" とする。
の説明を補足的に参照されたい。
システムへ転送されたデータの伝送)は、アップロードと非常に似ている。図6
には、デルタダウンロードに基づき生じたBDocの処理における完全なフロー
コントロールが示されている。このアーキテクチャは図5に対応している。
で通信する内勤従業員IHEによって、ビジネスオブジェクトが生成される。ダ
イアローグプログラムDPはアップデートファンクションモジュールUFMを呼
び出し、稼働し始める。アップデートモジュールはイベントを発し、結果伝送部
RSはMSシステムにおける結果セーブエージェントを呼び出す。アップロード
プロセスとは異なり、結果伝送部RSがMSシステムへ伝送しなければならない
ような付加的なMSデータは存在しない。たとえば新たに生成されたオブジェク
トのためのMSキーなどのように欠けているMSデータはキージェネレータKG
によって生成され、キージェネレータ自体は結果セーブエージェントRSAによ
ってトリガされる。OLTP−R/3システムから受け取ったデータに対し新た
なBDocが生成され、図6に示されているように相応のコントロールフローを
実行するためフローコントロールがスタートする。
めに、初回のデータダウンロード(Initial Download)が必要とされる。ダウン
ロードすべきビジネスオブジェクトクラスは、カスタマ固有のシステム整合中に
決定される。しかもビジネスオブジェクトのインスタンスを、特定の属性値に依
存してフィルタリングすることができる。ついで、固有の出口(カスタマイクジ
ット Customer Exit)を利用することができる。
れている。初回データダウンロードドリガエージェント(Initial Download Tri
gger Agent)IDTAはプロダクションフェーズ開始前、初回データダウンロー
ドを導入するためシステムアドミニストレータによって始められる。初回データ
ダウンロードトリガエージェントは、OLTPダウンロードトリガエージェント
(OLTP Download Trigger Agent)ODTAを呼び出す。トリガはqRFCによ
って引き起こされる。これにより、初回データダウンロードアクションが正確に
1度実行されるようになる。OLTPダウンロードトリガエージェントODTA
は、選択されたビジネスオブジェクトクラスに対し抽出部マスタEMを呼び出し
、さらにこの抽出部マスタ自身はR/3抽出部EXTを呼び出す。抽出部マスタ
EMと抽出部EXTの相違点は、抽出部マスタはMSシステムとの共働に固有に
適合されたコンポーネントであるのに対し、抽出部EXTはOLTP−R/3シ
ステム内の他の関連においても使用される。
LTPデータベースOLTP−DBからオブジェクトデータを選び出す。さらに
抽出部マスタは処理すべきテーブルに関する情報も供給し、必ずしも完全なオブ
ジェクトを抽出しなくてもよいようにする。個々の抽出部マスタは選択されたオ
ブジェクトを結果伝送部RSへ伝送する。既述のように、固有の出口を用いて結
果伝送部において付加的なフィルタリングを実行することができる。
ェントRSAへ伝送する。そしてこのエージェントはマッピング用エージェント
MA、キー生成用エージェントKGならびに統合データベース用バルクストレー
ジエージェント(Bulk CDB Agent)BCAを呼び出す。マッピングエージェント
は、OLTP−R/3システムの構造をMSシステムの構造に変換する。キージ
ェネレータは、OLTP−R/3キーだけをもつオブジェクトのためのMSキー
を生成する。バルクストレージエージェントBCAは、ビジネスオブジェクトの
データを統合データベースDBへ書き込む。バルクストレージエージェントBC
AとMSシステムのデータベースサービスCDSとの相違点は、BCAは複数の
オブジェクトを同時に処理できるのに対し、CDSはそれぞれただ1つのビジネ
スオブジェクトのデータだけしか処理できないことである。
同時にダウンロードされる。とはいえこれは、互いに無関係なオブジェクトクラ
スについてのみ行われる。あるオブジェクトが他のオブジェクトに依存している
かぎりは(たとえば「カスタマ}の「オーダ」など)、それらは適切な順序で相
前後してダウンロードされる。この場合、望ましい順序におく目的で、各オブジ
ェクトはインスタンスのレベルではなくクラスのレベルでダウンロードされる。
、それらは他のアプリケーション領域(たとえば外部のアプリケーションBW)
のためにも用いられる。
タ基準が抽出部へ渡される。これはフィルタ基準に対応するすべてのビジネスオ
ブジェクトのキーを決定する。さらに第2のステップにおいて、本来の情報を読
み出すためキーリストを用いて抽出部マスタEMが呼び出される。そして抽出部
マスタは抽出部を用いて、別の処理のためにBDocとして必要とされる順序で
呼び出しに固有のデータをテーブルからフェッチする。
トの個数が決定される。抽出部はシリアルに動作可能であり、つまり1つのパス
を他のパスの次に処理することができる。パラレルの動作モードもオブジェクト
ごとのベースで可能である。
移される。マッピングはフィールドごとに実行される。この場合、複数のフィー
ルドを1つのフィールドに連結したり、あるいは1つのフィールドを複数の部分
に分けることができる。また、フィールドタイプがコンバートされる。さらにソ
ースフィールドから依存する情報が生成される。
キーを見つけるために用いられる。この場合、それぞれ1つのキージェネレータ
はBDocのタイプについて固有に、レポジトリ情報を利用して生成される。キ
ージェネレータエージェントを最新の状態に保持する目的で、キージェネレータ
を生成するためのジェネレータがレポジトリのジェネレータエージェントにおい
て1つのサブスクライバとして登録される。そしてこれは、対応するレポジトリ
の情報が変化したときに呼び出される。
キーに対しCRM−MSキーをここではGUID(globally unique identifier
)のかたちで使用する。必要とされるMSキーは種々の場所で探され、つまりま
ずはじめにキージェネレータのローカルテーブルにおいて探され、ついでキーマ
ッピングテーブルによって、最後に統合データベースCDにおいて探される。M
Sキーがみつからなければ新たなキーが生成され、種々のマッピングテーブルに
挿入される。
成されるのを避けるため、付加的なキーマッピングテーブルが必要とされる。キ
ージェネレータのローカルテーブルはオプションであり、パフォーマンス向上の
ためキャッシュとして用いられるだけである。
ースCDとの同期合わせのために2つのコンポーネントが設けられており、すな
わち「リクエスト」と「コンペア」とが設けられている。リクエストコンポーネ
ントは、初回データダウンロード用のコンポーネントと非常に似ている。これに
よって、所期のように特定のビジネスオブジェクトをOLTP−R/3データベ
ースOLTP−DBから統合データベースCDへダウンロードすることができ、
つまりはポータブルコンピュータMCのデータのレプリケーションを(フローコ
ントロールFCの制御のもとで)実行することができる。リクエストによって指
定されたフィルタ基準は初回データダウンロードの一般的なフィルタ基準と混合
され、その結果、初回データダウンロード中に処理されたデータの1つのサブセ
ットだけを選択できるようになる。このリクエストコンポーネントをインタラク
ティブにスタートさせることもできるし、バッチモードでスタートさせることも
できる。
ウンロードする。比較アクションの結果として得られる相違点によって、統合デ
ータベースCDにおいて行う必要のある変更が表され、これはその内容をOLT
P−R/3データベースOLTP−DBの内容と一致させることを目的としてい
る。その際、変更情報(「インサート」、「アップデート」、「デリート」)は
BDoc構造内に格納される。本来の比較アクション後に統合データベースDB
に対しその変更が適用され、それによってその変更をOLTP−DBと一致させ
るようにする。そして変更情報からBDocが生成され、ローカルデータベース
LDのレプリケーションのため(フローコントロールにより制御されて)モバイ
ルクライントMCが用いられる。
インテグレーションにとって重要であるのは、システムを超えてクロスシステム
もしくはシステムワイドでプライマリキーを供給することであり、これによって
データオブジェクトの一義的な識別を相互に融合するデータベースシステムの境
界を超えて実現することができる。
描かれている。キージェネレータKGは、ここでは一般的にAもしくはBの付さ
れたデータベースシステム(ソースシステム)において捕捉されたデータを受け
取る。これにはシステム固有の個々のプライマリキーKAもしくはKBが属して
いる。(ターゲットとなるシステムにおける)それぞれ他のプライマリキーにつ
いては、データセットにおいて空のフィールドが設けられている。キージェネレ
ータはキーマッピングテーブル(Key Mapping Table)KMTの内容を読み出し
、システムAまたはBの一方から供給されるデータセットのキーフィールドと比
較する。ソースシステム(たとえばKA)のプライマリキーがキーマッピングテ
ーブルKMT内にすでに存在しているならば、供給されたデータセットは既存の
エントリの変更(アップデート Update)に該当する。この場合、ターゲットと
なるシステム(たとえばKB)における対応のプライマリキーがキーマッピング
テーブルKMTから読み出され、データセットの空のフィールドにエントリされ
る。
つからなければ、それはデータセットの新たな生成(インサート Insert)であ
る。この場合、欠けているプライマリキー(たとえばKB)がキー生成モジュー
ル(Key Generate Module)KGMによって生成されてキーマッピングテーブル
KMTに書き込まれ、さらにそのキーは空のデータフィールドにエントリされる
。その後、データセットはターゲットとなるシステムにおいても一義的に識別可
能であり、ソースシステムのキーとターゲットシステムのキーは互いに一義的に
対応づけられる。
れたデータセグメントの複雑な構造をもつデータオブジェクトを有するデータベ
ースシステムにおいてこの原理を実施するための実際のやり方について説明する
。
れている。セグメントS1は階層的にいえばセグメントS2の一段上に配置され
ており、したがって子セグメントS2に対する親セグメントと呼ばれる。親セグ
メントは図示の事例ではBDocのルートセグメントである。
3システムのプライマリキーKR/3を有している。これらのキーの各々は、1
つまたは複数のセグメントフィールド内に格納されている。
イマリキーKMSと(3つのフィールドに格納されている)OLTP−R/3シ
ステムのキーKR/3を有している。さらに子セグメントのフィールドには上位
の親セグメントのキーも含まれており、このことは両方のセグメント間の矢印に
よって表されている。とはいえそれらのフィールドはキーのファンクションをも
っているのではなく、セグメント構造に関する情報に対するいわゆる外部キー(
foreign key)として用いられる。つまりそれらは、S2はセグメントS1の子
であることを表している。
矢印で表されている行にはセグメントS1とS2の各キーが書き込まれている。
ントS1(BDocのルートセグメント)、階層的にいえば下位に位置する子ジ
ェネレーションの2つのセグメントS2aおよびS2b、さらにはセグメントS
2aの子である孫ジェネレーションのセグメントS3が設けられている。たとえ
ばセグメントS1には「カスタマ」タイプのBDocのためにカスタマの名前と
住所をもたせることができ、セグメントS2aにはそのカスタマの担当員を、ま
た、フィールドS3にはその担当員の渉外情報(電話番号、サービス時間など)
を、さらにフィールドS2bにはそのカスタマの装備しているマシンに関する情
報を含めることができる。
のフィールドのみにおいて)両方のデータベースシステムのキーKMSおよびK R/3 を有しており、この場合、依存するシステムはそれぞれ親ジェネレーショ
ンのキーを外部キーとして有している。図10の右側に描かれているキーマッピ
ングテーブルは、やはり両方のシステムの対応を示している。
タリーブされた多数の階層平面をもつ非常に複雑なデータ構造を有している可能
性があり、その際、セグメントはしばしばきわめて多くの個数のデータレコード
を有している。これに加えて、特別な要求を考慮するため特殊な構造エレメント
の必要とされることも多い。たとえば個々のデータレコードのデータに対し、そ
れらが下方の階層平面にあるにもかかわらず、迅速にアクセスできるようにする
ことの要求されることが多い。このような状況において好適であるのは、階層的
に深いセグメントにおいて必要とされるキーを比較的高い階層のセグメントにお
ける特別なフィールドに格納することである。たとえば図10に描かれているよ
うに、第2のセグメントS2aの第1のデータレコードのコードC1Mを有する
キーがセグメントS1の特別フィールドSF内にエントリされており、その目的
はたとえばS1にコーディングされているカスタマの最も重要な担当員に対する
ダイレクトなアクセスを可能にすることである。このような構造上の特殊性によ
って、上述の方法の実施は実際にはとても困難になる。
る。このアルゴリズムは2つのプログラム部分から成り、それらをPASS−I
およびPSS−IIと称する。
の必要とされるすべてのセグメントに対し)、およびすべてのデータセットに対
し、コメント「KMSを満たす」の付けられたアルゴリズムセクションが実行さ
れる。このアルゴリズムセクションではまずはじめに、プライマリキーのフィー
ルドが空であるか否かの問い合わせが行われる。空であるならば、存在するキー
KR/3のもとでキーマッピングテーブルにおいて、エントリが存在するか否か
が探索される。場合によっては、対応するMSプライマリキーがキーマッピング
テーブルから取り出され、BDocへエントリされる。
マリキーとして生成され、KR/3もKMSもキーマッピングテーブルにエント
リされる。さらにBDocへのKMSのエントリが行われる。
が実行される。MS親キーのためのフィールドが空であれば、読み出しポジショ
ンがBDoc内の親セグメントにおかれ、しかもこれは対応するKR/3を含む
データレコードにおかれる。その後、対応するKMSが親セグメントから取り出
され、子セグメントの外部キーフィールドにエントリされる。
から始めて)BDocのすべてのセグメントが処理されてしまうまで何度も実行
される。
レポジトリに格納されたテーブルによって制御される。このテーブルには、PA
SS−Iでは不可能である充填アクション(フィルアクション)が記述されてい
る。これには、(図10に描かれているように)階層的に低い方のセグメントか
らの値の充填と、親平面よりも高い階層平面(つまりたとえば2つの平面だけ高
い平面すなわち親の親の平面)からのキーの充填が属している。
有している。
ルドからターゲットテーブルと称するBDocのセグメントへの充填アクション
が発生する。
ーブルについて{ FETCHテーブルから値を読み込む (Cond=R/3)であれば{ //BDoc内の値 SrcTblにおけるBDocにポジショニング(KR/3) SrcTbl−>SrcFldをDestTbl−>Dest
Fldに書き込み }そうでなければ{ //CDからの値 フィルタ=CondでSrcTblにおけるCDにポジショニング CDSrcTbl−>SrcFldをDestTbl−>Dest
Fldに書き込み } } } 処理されるBDocのすべてのセグメントについて、およびセグメントがDe
stTblとしてエントリされているFETCHテーブル内のすべてのエントリ
について、FETCHテーブルから値が読み出される。その後、条件判定が行わ
れる。Cond=R/3とセットされていれば、それはBDoc内のキー値の伝
送のことであり、この場合、ソースセグメントにおけるソースフィールドの内容
がターゲットセグメント内のターゲットフィールドへ伝送される。条件Cond
が別の値を有しているならば、BDoc自体からまたは統合データベースCDか
ら値が引き継がれ、後者の場合、データベースCD内のソーステーブルへのアク
セスが行われ、その内容がターゲットセグメントのターゲットフィールドへ伝送
される。
つのシステムにおいて所定のタイプのデータオブジェクトに対して存在するデー
タがそれぞれ異なることである。たとえばCRMシステムにおけるデータオブジ
ェクト「カスタマ」には、個々のカスタマ担当員または準備されている販売交渉
(opportunities)に関する情報の含まれている可能性があり、これをERPシ
ステムは必要としない。これに対し、ERPシステムにおけるデータオブジェク
ト「カスタマ」は、たとえば取引関係開始以来のカスタマのすべての勘定のよう
な情報を有しており、これをCRMシステムは必要とせず、したがってそこで処
理されるデータオブジェクトについてセグメントは設けられていない。
ばシステムの一方においてつまりフロントオフィスシステムMSにおいて、互い
に融合されるシステムの両方のキーKMSおよびKR/3がホールドされるのに
対し、バックオフィスシステムにはそのキーKR/3だけがホールドされる。
であるのは「データマージ手順(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呼出部B
Cから分配されてそこに保管される。その後、OLTPアダプタは残りの情報D Mix およびKMSをOLTP−R/3システムへ伝送する。ソースシステムK MS のキーはターゲットシステムOLTP−R/3システムにおいて分離され、
補助データAMDというメモリ領域に保管される。
システム(OLTP−R/3システム)において生成されたデータオブジェクト
を処理するために必要とされる。それらの補助データは通例、対応するデータフ
ィールドのためのプリセット値(デフォルト値)である。
はターゲットシステムにおいて一般に行われているロギングルーチンを用いるこ
とで非同期にチェックされ、データベースOLTP−DBに格納される。
ィストリビュータEDによって殊に結果伝送部RSへ伝達され、結果伝送部はこ
れに応じてデータをロギングから受け取る。得られたデータパケットはDR/3 ,DMixおよびKR/3から成る。結果伝送部RSは保管されていたMSキー
KMSを挿入し、MSシステムに関係しないデータDR/3を取り除く。その後
、データパケットDMix,KMSおよびKR/3としてMSシステムへの伝送
が行われる。MSシステム内において、保管されていたデータDMSが結果セー
ブエージェントRSAにより再び付け加えられ、その結果、データDMS,DM ix ,KMSおよびKR/3を有する完全なBDocが後続処理(たとえばデー
タベースCDにおける統合化およびそれに続くモバイルクライントMCへのレプ
リケーション)のために得られる。
へのデータのアップデートごとに行われる。OLTP−R/3システムにおける
データ変更(デルタダウンロード)にあたりこの手順の一部分がロギングルーチ
ンからスタートして実行されるが、その際には当然ながらMSキーKMSを加え
ることはできない。これはその場合には上述のようにしてキージェネレータKG
によって生成される。
通に利用されるデータを別個にメンテナンスしなくても済むようにし、互いに融
合されたデータベースシステム中に存在するデータを共通に利用できるようにす
ることである。たとえばCRMフロントオフィスシステムは、企業のERPバッ
クオフィスシステム内に格納されているカスタマ情報および製品情報に関するデ
ータをアクセスすることができるようにしなければならない。
ベース(ソースシステムAここではOLTP−R/3システム)におけるデータ
であって、インプリメントされている別のデータベースシステム(ターゲットシ
ステムBここではMSシステム)によっても必要とされるデータが、初回データ
ダウンロード(Initial Download)にあたりシステムAからシステムBへ伝送す
る。この関連で本発明によれば以下のような問題解決手段が提案される。
ムと称するがこれによっても汎用性が制約されるものではない)におけるデータ
量は通例、非常に多い。したがって、他のシステムと交換すべきデータを詳しく
指定する手段を提供しなければならない。本発明においてはこのことは有利には
フィルタリングによって行われる。
られ、これはOLTP−R/3システムによって提供される。この場合の特殊性
は、抽出部マスタのかたちでMSシステムに対する標準化されたインタフェース
が適用され、このインタフェースを介してMSシステムにおけるすべての問い合
わせが行われることである。つまり、ターゲットデータシステムMSが標準化さ
れたインタフェースを介してそのシステムが必要とするデータに対する要求を、
ソースシステムOLTP−R/3にインプリメントされている抽出部へ伝送する
ことによって、データがフィルタリングされる。
ようにすることである。このことは、一般にバックオフィスシステムに設けられ
ている手段によって実現できない。なぜならばそのような手段は非常に大きいデ
ータ量を迅速に伝送するようには構成されていないからである。本発明によれば
この問題点は有利には、先に詳しく説明したバルク指向BDocと呼ばれる特別
なデータコンテナを提供することによって解決される。
ステムに伝送されるデータがソースデータベースシステムのきちんと定められた
状態と規定の時点(スナップショット snapshot)で一致するよう保証すること
である。従来ではこの問題点は、初回データダウンロード中はソースデータベー
スシステムを変更に対しブロックすることで解決されており、あるいは変更が許
可されているのであるならば、ソースデータベースの特別な手段を利用すること
で解決しているが、そのような手段によってデータベースに対し初回データダウ
ンロードの独立したオペレーションが妨げられる。
同期手順(online sync procedure)と呼ぶ方法が提案され、これについて図1
2を参照して説明する。この場合、ソースシステムOLTP−R/3にインプリ
メントされている抽出部は、ターゲットシステムMS内に格納されているフィル
タ定義FDにより制御され抽出部マスタインタフェースEMを介して呼び出され
るのであるが、この抽出部は通常はブロックで読み出され送出されるかたちで動
作し、その際にこれはソースデータベースのダイナミックなデータ変更を無視す
る。このため、ターゲットシステムにより必要とされるデータバルクは矢印IL
(Initial Load)の付された経路で伝送される。
行される。これにより、ソースシステム内で初回データダウンロード中に生じた
変更がキューに格納される。通常のデルタダウンロード動作とは異なりこのキュ
ーはアンロックされるのではなく、初回データダウンロード期間中はロックされ
る(Queue-Stop QS)。初回データダウンロード終了後に変更キューがアンロッ
クされ、初回データダウンロード中に実行された変更が矢印DL(Deltaload)
によってシンボリックに表されたデルタダウンロードチャネルを介してターゲッ
トシステムMSへ伝送される。このようにして、初回データダウンロード終了時
点に関して一致した「スナップショット」が生じる。
びにデータマージ手順についてなされた説明が関連する。ここでの目的は、初回
データダウンロード後に動作実行中、ソースデータベースシステムAとつながっ
ているすべてのシステムに対しそれぞれ変更を加えることである。
ベースシステムへ転送 通例、実施された変更について通知するために変更ポインタが用いられるけれ
ども、これは著しい欠点をもっている。まず第1に、起こり得る変更ごとにソー
スデータベースシステムのアプリケーションに変更ポインタを設けなければなら
ない。これはたいていすべてのデータオブジェクトについて不可能なことである
が、少なくとも非常に手間がかかるしクリティカルなエラーの原因となる。他方
、変更の通知はまえもって定められたタイムインターバルでしか行われない。
技術が利用される。ソースデータベースシステムにおけるデータベースOLTP
−DBへ変更を加えるルーチンに、イベント発生が組み込まれる。イベントディ
ストリビュータEDを介して、イベントに対する予約を扱うファンクションモジ
ュールがイベント発生時に呼び出される。このファンクションモジュールには、
ターゲットデータベースシステムの相応のモジュール(図5では結果セーブエー
ジェントRSAのコンポーネント)が属している。このようにしてMSシステム
におけるOLTP−R/3アダプタ(つまり一般的にいえばターゲットシステム
のモジュール)は、ターゲットシステムに関連するソースデータベースシステム
内の変更に関する情報をほぼ同時に受け取る。
スシステムへの変更の伝送は、ターゲットデータベースシステム内に格納されて
いる既述のフィルタ基準FD(図12)に基づき実施される。その後、上述のデ
ータマージ手順を用いてデータが処理され、やはりすでに説明したやり方でシス
テムを超えたクロスシステムプライマリキー(cross-system primary key)が生
成される。
ドにあたり)以下で説明するネットフィールド決定(net-field determination
)が用いられることである。
れる変更が相互に書き換えられるのを最小限に抑えるために有利であるのは、個
々のデータセットにおいて変更されたフィールドだけを伝送することである。こ
のことをネットフィールド伝送(net-field transmission)と称する。しかしな
がら、たとえばOLTP−R/3システムなどのようなERPバックオフィスシ
ステムは一般に「すべて込みのフィールドないしはオールフィールド(all-fiel
d)」ベースでしか通信できず、つまりこのシステムはフィールド内容全体を伴
ってデータセット全体を一度に伝送するだけである。したがってデータはデータ
チャネルDL(図12)を介してオールフィールドベースでターゲットシステム
MSに転送され、これはそのような転送が結果伝送部RSによってトリがされた
ときに行われる。この欠点は本発明の有利な実施形態によれば次のようにして解
消される。すなわち、ターゲットシステムつまり統合データベースCDのデータ
ベースサービスCDSにおいて、フィールド平面における有効な変更が統合デー
タベースCDの内容との比較により求められ、実際の変更だけがネットフィール
ドベースで後続処理に関与させるのである。
照しながら説明する。
ベースシステムのデータオブジェクト)のすべてのセグメント、変更されたフィ
ールドを反映するフィールドが挿入される。このフィールドを送信ビットフィー
ルド send-bit field SBF と称する。これはたとえばRAW(32)タイプのも
のとすることができ、バイナリ表示で(好適にはHEXで格納されるかたちで)
変更を受けたフィールドに対応する各ポジションにおいて「1」を有している。
図13には、送信ビット情報SBFとフィールド情報FINとの対応関係が描か
れている。この場合、消去も変更として表される。図示の事例ではたとえばフィ
ールド1およびフィールド4のフィールド内容が(「A」と「C」に)変更され
ており、フィールド2およびフィールド8のフィールド内容が消去されている。
付加的なフィールドSBFのフィールド内容は、フィールドの個数に対応するビ
ット数をもつ関連部分Rと無視される非関連部分Lによって構成されている。
転送される場合、ターゲットデータベースシステムMSのデータベースとの調整
が行われる。この調整はデータベースCDのデータベースサービスCDSにおい
て実行され、これについては図14に描かれている。この場合、データセットD
1は、変更されたフィールド内容「X」をもちオールフィールドベースで伝送さ
れるデータセットの実例である。データベースサービスCDSはそのデータセッ
トを、データベースCD内に格納されている対応するデータセットD1′と比較
し、内容「X」をもつフィールドだけが変更されていることを確認する。これに
従い、変更された情報だけをもつデータセットD2が生成される。対応する送信
ビットは「1」にセットされている。残りのフィールド内容は空にされている。
の単純なデータ交換以上のことを意味している。可能性に応じてアプリケーショ
ンの動作を、有効データの処理の基礎を成すロジック(ビジネスロジック "busi
ness logic")に近づけるようにする。ビジネスロジックは、個々のデータベー
スシステムのレポジトリに格納されている制御データに高度に反映されており、
それらはたとえば値の範囲、フィールドやレコードやデータベースの妥当性など
のようなロジックをマッピングする。このためセマンティックな統合においては
、レポジトリ制御情報もクロスシステムでレプリケーションされるようにする。
OLTP−R/3システムの事例では、これはいわゆるカスタマイズテーブル(
Tテーブル)である。しかしながらカスタマイズテーブルにおける変更は、OL
TP−R/3システムでは変更ポインタによってもイベントによっても指示され
ない。このため適切な更新メカニズムを利用できなければ、MSシステムなどの
ターゲットデータベースシステムにおいてこれらのデータのレプリカは急速に古
くなってしまう。
タ状態を絶えず同期合わせできるようにする目的で、すでに挙げたコンポーネン
ト「リクエスト」および「コンペア」が使われる。図15および図16には、こ
れによって実現される同期メカニズムが示されている。
と同じように動作する。任意のビジネスオブジェクトをOLTP−R/3システ
ムからMSシステムへダウンロードするために、汎用抽出部 general extractor GEと呼ばれるモジュールが用いられ、これはフィルタ定義FDに従い抽出部
マスタEMによって呼び出される。
れる前に、図15においてCOMPの付されたコンペアモジュールが呼び出され
る。このコンペアモジュールはダウンロードされたデータをすでにデータベース
CD内に存在しているデータと比較し、実際に変更されたデータだけを通過させ
る。さらにこのモジュールは、もはやオリジナル中には存在していないデータに
対する消去指示も発する。
いてまずはじめにOLTP−R/3システムから受け取ったデータおよびこれに
対してそれぞれ対応するデータベースCDからのテーブルが、それぞれメモリロ
ケーションS2もしくはS2に用意される。データベースCDから対応するテー
ブルを選択する際、MSシステム内にしか含まれていないすべてのレコード(図
16ではレコードレコードm1,m2)は選択されないよう、データがフィルタ
リングされる。その他のレコードにもMS固有のデータを有するフィールドが含
まれている。データ伝送時のさらに別の制限によって、メモリ領域S1にはOL
TP−R/3システムにおいても利用可能なデータだけが供給されるようになる
。
一方が基準として選択され、そのテーブルにういて最初から最後まで段階的に進
められ、他方のテーブルにおいて対応するエントリが探索される。この場合、パ
フォーマンスの理由で有利であるのは、エントリの個数の僅かな方のメモリテー
ブル(図16ではメモリ領域)を基準として選択することである。比較結果に依
存して以下のような相応のアクションが導入される: 新しいエントリの生成: ”I” ネットフィールドエントリの生成: ”U” 消去指示の生成: ”D” アルゴリズムは以下のように表すことができる: S1内のすべてのエントリについて{ S2内で得られるならば{ 該当しない先行のすべてのS2エントリについて新たなエントリ(”I
”)を生成 変更であれば ネットフィールドエントリ(”U”)を生成 }そうでなければ 消去指示(”D”)を生成 } 4.アップロード 既述のように、データベースシステムのセマンティックな統合の基本的な要素
は、データのエントリや変更を1つのデータベース内だけでなく互いに結合され
た複数のデータベースまたはすべてのデータベースにおいて実行できるようにす
ることである。したがってたとえば、外勤従業員はカスタマにおいて新たなデー
タ(たとえば新たなオーダ)を自身のポータブルコンピュータに入力し、そのデ
ータセットにおけるそのような変更をデータベースOLTP−DBにおいて持続
的なものとすることができるようにすべきである。
トランザクション層によって登録され、その際、このトランザクション層を介し
てモバイルクライアントはMSシステムおよびその固有のローカルデータベース
LDと通信する。ポータブルコンピュータがミドルウェアサーバMSと接続され
る場合、変更されたデータがBDocとして伝達され、バックオフィスシステム
OLTP−R/3にも伝送される。このために用いられるコンポーネントは図5
を参照しながらすでに説明しており、その際に実行されるデータマージ手順につ
いては図11を参照しながらすでに説明した。
策の開発であり、その目的は様々な場所でエントリされたり変更されたりする各
データ間のコンフリクトを阻止することである。結合システムにおいてそのつど
1つの特定の個所においてのみデータの変更を許可するようにしたいわゆる「デ
ータメンテナンス優位(data maintenance ascendencies)」の定義であると、
十分な統合を提供することはできない。多くの適用事例において用いられている
LOW(Last One Wins)方式も、ERPバックオフィスシステムのデータを含
むこのような結合システムには適していない。
規のコンフリクト対策が用いられる。LSC方式は、各データオブジェクトごと
に管理する側のシステム(FS)を定義する。結合システムにおける他のすべて
のシステムは管理される側のシステム(GS)である。GSの各変更はまずはじ
め、FSによって操作しなければならない。通常の操作機能に対する基本的な相
違点は、これはアプリケーションの境界を超えたファンクションであり、構造に
互換性のない各システム間のコンフリクトを解消するために用いられる。
される。
トついて管理される側のシステムである。管理される側のシステムは、以下の要
求を満たすことができなければならない。
識別できなければならない。
なければならない。
同じデータオブジェクトにおいてチェックすべき複数の変更を先行のチェックの
終了を待たずとも相次いで続けることができなければならない。
ができ、それらをペンディングカウンタ(PC)およびインボックス(IB)と
称する。
に関与するテーブルごとに(つまりBDocの各セグメントに)存在する。この
フィールドを介して、データの目下の確認状態が定義される。これによってコン
トロールフラグが形成され、これはデータの確認状態をたとえば画面上に視覚的
に表示するためにアプリケーションプログラムによって評価される。
基準カウンタとして変更の回数をカウントアップする。
テムによって確認されると再び”0”になるまで再びカウントダウンされる。拒
否の場合にもカウントダウンされるが、”P”ではなく”F”がセットされる。
が承認されないときにはもとのデータ状態が管理される側のシステムにおいて再
び形成(ロールバック)されるようにすることである。これは有利には、管理す
る側のシステム(この実例ではOLTP−R/3システム)が拒否と同時に(上
述のように)データオブジェクトに含まれている「先行状態のイメージ(before image)」BIを管理される側のシステムへ送り戻すことによって行われる。こ
のようにしてオリジナル状態を取り戻すことでロールバックを行うことができる
。
トにおけるユーザの変更すべてが上書きされることにある。たとえばこれが10
0個以上の項目を含むオーダであって、それが場合によっては比較的僅かな不一
致ゆえに拒否された場合には、変更のもととなった誤りのあるデータオブジェク
トつまりはそれゆえに承認されなかったデータオブジェクトのデータを再びユー
ザが利用できるようにしなければならない。これはインボックスによって行われ
る。この場合、ユーザはエントリを便利なように整合させることができ、再び利
用可能にすることができる。
のファンクションが描かれている。その際、LDの付された行は、ペンディング
カウンタPCの状態を表すフィールドとプライマリキーフィールドKと3つのデ
ータフィールドDをそれぞれ有するローカルデータベースの内容をシンボリック
に表している。
報をOLTP−R/3システムへ伝達するBDocには、変更された情報「2」
しか含まれていない。
「B」と「3」も同様にBDocとして伝送される。さらに第4のステップにお
いて第1の変更の確認が行われ、第5のステップにおいて第2の変更の確認が行
われる。ペンディングカウンタPCはそれぞれ確認状態を表す。
われ、これには星型のシンボルが付されている。この変更はエラーメッセージ「
E」として拒否され、その結果、第8のステップにおいてその変更前の状態がリ
ストアされる。これと同時に、(拒絶された)変更された状態がインボックスに
配置され、これによりユーザはそれについて処理を続けることができる。その間
に第7のステップで行われた第1のフィールドにおける許可された変更が、第9
のステップにおいて確認される。
ステムのフローコントロールの制御のもとで行われる。これはBDocのヘッダ
にセットされたフラグに基づき、BDoc全体が承認されたのか拒否されたのか
をチェックする。拒否の場合、リジェクトサービスはBDocの全データを統合
データベースCDから抽出し、それをBDoc内で先行イメージとして利用でき
るようにする。BDoc全体が承認されればリジェクトサービスはその部分セグ
メントをその状態についてチェックする。部分セグメントが拒否された場合には
その内容がやはり統合データベースCDから抽出され、先行イメージにおいて得
られるようにする。
要であれば拒否できるようでなくてはならない。このような機能はバックオフィ
スシステムにおいては一般に実装されている。この関連でやはり重要なその他の
機能についてはすでに説明した。これにはデータマージ手順との関連で説明した
受け入れの事例におけるデータ補足や、同じく説明済みの管理する側のシステム
のプライマリキーの伝送が含まれる。
中央計算部を成すミドルウェアサーバMSとERPバックオフィスシステムの実
例としてのOLTP−R/3システムとの間のデータ交換について説明してきた
。
たとえばミドルウェアシステムMSは既述の手順を利用して様々な別のデータベ
ースシステムと利用することができる。それらのデータベースの論理構造は処理
されるオブジェクトのレベルで少なくともオーバラップ部分をもっている一方、
それらの構造はプログラミング技術的実装のレベルでは互換性のないものである
。したがってMSシステムを、既述の手順を利用して様々な外部のデータシステ
ム間の交換システムとして利用することができる。
観を示す図である。
る概観をCRMシステムの実例で示す図である。
ドプロセスの実例として示す図である。
を示す図である。
ドおよびダウンロード時にはたらくコンポーネントのアーキテクチャを示す図で
ある。
データを初回にダウンロードするためのコンポーネントのアーキテクチャを示す
図である。
の原理図である。
を示す図である。
例である。
ある。
ある。
ある。
である。
Claims (16)
- 【請求項1】 2つのデータベースシステムAとBとの間でデータを交換す
る方法であって、 データベースシステムの各々は、格納されているデータオブジェクトの一義的
な識別のため、各データオブジェクトごとにプライマリキー生成ロジックを用い
てシステム固有のプライマリキー(KAないしはKB)を生成し、両方のデータ
ベースシステムAおよびBのプライマリキー生成ロジックは互いに独立しており
、 ソースデータベースシステムA(OLTP−R/3)からターゲットデータベ
ースシステムB(MS)へ伝送されるデータオブジェクトについて、システムを
超えて共有される新しいエントリに必要とされる一義的な識別を可能にするため
、 a)ソースデータベースシステムAからターゲットデータベースシステムBへ
伝送すべきデータオブジェクトのプライマリキー(KA)をキーマッピングテー
ブル(KMT)と比較するステップを実行し、該キーマッピングテーブルは、す
でに2つのプライマリキー(KAおよびKB)の生成されているすべてのデータ
オブジェクトのプライマリキー(KAおよびKB)を有しており、 b)プライマリキー(KA)が前記キーマッピングテーブル(KMT)内にま
だ存在していなければ、プライマリキージェネレータ(KG)によって自動的に
ターゲットデータベースシステムBのプライマリキー(KB)を生成してデータ
オブジェクト内に格納し、ソースデータベースシステムAのプライマリキー(K A )といっしょに前記キーマッピングテーブル(KMT)に格納するステップと
、 c)ソースデータベースシステムAのプライマリキー(KA)が前記キーマッ
ピングテーブル(KMT)内で見つけられたならば、ターゲットシステムBの対
応するプライマリキー(KB)をデータオブジェクトに格納するステップを実行
することを特徴とする、 2つのデータベースシステムAとBとの間でデータを交換する方法。 - 【請求項2】 前記プライマリキージェネレータ(KG)をターゲットデー
タベースシステムB内に統合する、請求項1記載の方法。 - 【請求項3】 ターゲットデータベースシステムB(MS)のプライマリキ
ー(KB,KMS)は、ソースデータベースシステムA(OLTP−R/3)の
データベースに格納されているデータの一部分ではない、請求項1または2記載
の方法。 - 【請求項4】 ソースデータベースシステムA(OLTP−R/3)へデー
タオブジェクトを送り戻すとき、ソースデータベースシステムB(MS)のプラ
イマリキー(KB,KMS)を該データオブジェクトから分離して保管する、請
求項3記載の方法。 - 【請求項5】 第1のデータベースシステムA(OLTP−R/3)内のデ
ータセットにおいて実行された変更に基づき第2のデータベースシステムB(M
S)内のデータセットを更新する方法であって、 第1のデータベースシステムA(OLTP−R/3)のデータセットは、第2
のデータベースシステムB(MS)には関連しないデータ(DR/3)も、第2
のデータベースシステムBに関連するデータ(DMIX)も有しており、 各データベースシステムにおけるデータを、それぞれシステム固有のプライマ
リキー(KMS,KR/3)を有するデータオブジェクトのかたちで処理し、 該データを第2のデータベースシステムB(MS)において両方のシステム固
有のプライマリキー(KR/3およびKMS)とともに格納し、 a)第2のデータベースシステムB(MS)には関連しないデータ(DR/3 )をデータオブジェクトから分離するステップと、 b)第1のデータベースシステムA(OLTP−R/3)から第2のデータベ
ースシステムB(MS)へデータオブジェクトを転送するステップと、 c)データベースシステムB(MS)に固有のキー(KMS)を生成し、生成
されたキー(KMS)をデータオブジェクトに追加するステップと、 d)生じたデータオブジェクト(BDoc)を第2のデータベースシステムB
(MS)の格納ルーチンに組み込み、該データオブジェクト中に含まれているデ
ータを第2のデータベースシステムB(MS)のデータベース(CD)に格納す
るステップの少なくとも一部を実行することを特徴とする、 第2のデータセットB内のデータセットを更新する方法。 - 【請求項6】 データオブジェクトのデータレコードを格納ルーチンに組み
込む前に補足値(DMS)によって補い、該補足値は第2のデータベースシステ
ムB(MS)のデータセットに対応する、請求項5記載の方法。 - 【請求項7】 第2のデータベースシステムB(MS)内のデータセットに
おいて実行された変更に基づき第1のデータベースシステムA(OLTP−R/
3)内のデータセットを更新する方法であって、 第2のデータベースシステムB(MS)のデータセットは、第1のデータベー
スシステムA(OLTP−R/3)に関連しないデータ(DMS)も第1のデー
タベースシステムAに関連するデータ(DMIX)も有しており、 各データベースシステムにおけるデータをデータオブジェクトのかたちで処理
し、該データオブジェクトはそれぞれシステム固有のプライマリキー(KMS,
KR/3)を有しており、 第1のデータベースシステムA(OLTP−R/3)内のデータをそのシステ
ム固有のプライマリキー(KR/3)とのみいっしょに格納する、 第1のデータベースシステムA内のデータセットを更新する方法において、 a)第1のデータベースシステムA(OLTP−R/3)に関連しないデータ
(DMS)をデータオブジェクトから分離し、該データを第2のデータベースシ
ステムB(MS)内に保管するステップと、 b)前記データオブジェクトを第2のデータベースシステムB(MS)から第
1のデータベースシステムA(OLTP−R/3)へ転送するステップと、 c)第2のデータベースシステムB(MS)のためのシステム固有のキー(K MS )を前記データオブジェクトから分離し、該キー(KMS)を第1のデータ
ベースシステムA(OLTP−R/3)に保管するステップと、 d)生じたデータオブジェクトを第1のデータベースシステムA(OLTP−
R/3)の格納ルーチンに取り込み、該データオブジェクトに含まれているデー
タを第1のデータベースシステムA(OLTP−R/3)のデータベースに格納
するステップの少なくとも一部を実行することを特徴とする、 第1のデータベースシステムA内のデータセットを更新する方法。 - 【請求項8】 前記データオブジェクトのデータレコードを格納ルーチンに
取り込む前に補足値(DD)で補い、該補足値は第1のデータベースシステムA
(OLTP−R/3)のデータセットに対応する、請求項7記載の方法。 - 【請求項9】 e)第1のデータベースシステムA(OLTP−R/3)の
データベース(OLTP−DB)の格納の結果としてイベントをトリガするステ
ップと、 f)第2のデータベースシステムB(MS)において前記イベントのために設
けられたコンポーネント(RSA)によりイベントを受け取るステップと、 g)データベースシステムB(MS)に固有の保管されたキー(KMS)を追
加するステップと、 h)第1のデータベースシステムA(OLTP−R/3)に固有のデータ(D R/3 )を取り除くステップと、 i)両方のデータベースシステムに関連するデータ(DMIX)、データベー
スシステムB(MS)に固有のキー(KMS)およびデータベースシステムA(
OLTP−R/3)に固有のキー(KR/3)を有するデータオブジェクトとし
て、第2のデータベースシステムBへデータを転送するステップと、 j)第2のデータベースシステムB(MS)内に保管された第1のデータベー
スシステムに関連しないデータ(DMS)を追加するステップの少なくとも一部
分を実行する、 請求項7または8記載の方法。 - 【請求項10】 複数のデータベースシステム(OLTP−R/3,MS)
を有する統合システム内におけるデータの新たなエントリまたは変更のための方
法において、 前記統合システムにおけるデータベースシステムのうち任意の1つのデータベ
ース内で共有されるデータを新たにエントリする際にデータコンフリクトを避け
るため、各データベースシステム間で交換可能な各データオブジェクトごとに前
記データベースシステムの一方(OLTP−R/3)を管理する側のシステムF
Sとして定義し、 該管理する側のシステムFS(OLTP−R/3)のデータセットにも属する
データオブジェクトのデータを、管理される側のシステムGS(MS)において
新たにエントリまたは変更するたびに、システムを超えた確認アルゴリズムを実
行し、該アルゴリズムにおいて、 a)変更を含むデータオブジェクトを管理する側のシステムFS(OLTP−
R/3)に伝送し、 b)管理する側のシステムFS内で、変更の承認または少なくとも部分的な拒
否として応答メッセージを生成し、 c)応答メッセージを含むデータオブジェクトを管理される側のシステムGS
(MS)へ送り戻すことを特徴とする、 複数のデータベースシステムを有する統合システム内におけるデータの新たな
エントリまたは変更のための方法。 - 【請求項11】 管理される側のシステムGS(MS)のデータベースLD
は、変更されたデータオブジェクトの確認状態をカウンタフィールドを用いて記
録し、該カウンタフィールドの計数状態は該カウンタフィールドに割り当てられ
たデータセットにおいて変更が生じるたびにカウントアップし、応答メッセージ
のたびにカウントダウンして、管理される側のシステムGS(MS)におけるカ
ウンタフィールドにより確認状態およびまだ応答のない変更の個数の表示を可能
にする、請求項10記載の方法。 - 【請求項12】 変更が少なくとも部分的に拒否された場合、データ変更前
の状態の先行イメージを利用して、管理される側のシステムGS(MS)内でそ
の状態をリストアする、請求項10または11記載の方法。 - 【請求項13】 エラーメッセージの場合、補正および後続処理のため管理
される側のシステムGS(MS)において誤って変更された状態も利用可能にす
る、請求項12記載の方法。 - 【請求項14】 ディジタルコンピュータのメモリにそのままロード可能で
あり、コンピュータにおいて実行されるとき、請求項1から13のいずれか1項
記載の方法のステップを実行するために用いられるソフトウェアセクションを有
していることを特徴とする、 コンピュータプログラム製品。 - 【請求項15】 請求項14記載のコンピュータプログラム製品を有するコ
ンピュータに適した記憶媒体。 - 【請求項16】 請求項15記載のコンピュータプログラム製品を有するデ
ータベースネットワークシステム。
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 true JP2003511796A (ja) | 2003-03-25 |
JP3887564B2 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) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006099760A (ja) * | 2004-09-03 | 2006-04-13 | Microsoft Corp | スマートクライアントアドインアーキテクチャ |
KR20210082921A (ko) * | 2019-12-26 | 2021-07-06 | 조상근 | 생산물류 erp 자동화 시스템의 협력사 및 고객사의 상호연결관계 파라미터의 설정방법 |
Families Citing this family (77)
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 |
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 |
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
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006099760A (ja) * | 2004-09-03 | 2006-04-13 | Microsoft Corp | スマートクライアントアドインアーキテクチャ |
KR20210082921A (ko) * | 2019-12-26 | 2021-07-06 | 조상근 | 생산물류 erp 자동화 시스템의 협력사 및 고객사의 상호연결관계 파라미터의 설정방법 |
KR102345148B1 (ko) | 2019-12-26 | 2021-12-29 | 조상근 | 생산물류 erp 자동화 시스템의 협력사 및 고객사의 상호연결관계 파라미터의 설정방법 |
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 |
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 |
JP3887564B2 (ja) | 2007-02-28 |
DK1237098T3 (da) | 2004-03-15 |
JP2007012079A (ja) | 2007-01-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3887564B2 (ja) | 統合型データベース結合システム | |
US7366460B2 (en) | System and method for mobile data update | |
US6539381B1 (en) | System and method for synchronizing database information | |
US6910053B1 (en) | Method for data maintenance in a network of partially replicated database systems | |
CN100449548C (zh) | 数据库同步方法及系统 | |
US9256655B2 (en) | Dynamic access of data | |
US7269604B2 (en) | System of and method for transparent management of data objects in containers across distributed heterogenous resources | |
US6256667B1 (en) | Intelligent messaging | |
US20150046524A1 (en) | Data Management for Mobile Data System | |
CN101185077A (zh) | 根据/利用第一数据库构建、同步和/或操作第二数据库的计算机网络及相应过程 | |
US8805785B2 (en) | Shared storage of categorization, labeling or tagging of objects in a collaboration system | |
US8626716B1 (en) | Service broker enhancements | |
US7506000B2 (en) | Method and system for programming disconnected data | |
US5615372A (en) | Network definition modifying system | |
JPH06290098A (ja) | 分散データベース処理方法 | |
US20070162492A1 (en) | Reconstruction of historic business object state | |
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 |