DE19858163A1 - Verfahren zum Übertragen von Informationen zwischen Datenbeständen Client-Applikationen - Google Patents

Verfahren zum Übertragen von Informationen zwischen Datenbeständen Client-Applikationen

Info

Publication number
DE19858163A1
DE19858163A1 DE19858163A DE19858163A DE19858163A1 DE 19858163 A1 DE19858163 A1 DE 19858163A1 DE 19858163 A DE19858163 A DE 19858163A DE 19858163 A DE19858163 A DE 19858163A DE 19858163 A1 DE19858163 A1 DE 19858163A1
Authority
DE
Germany
Prior art keywords
information
database
data
client application
electronic device
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.)
Ceased
Application number
DE19858163A
Other languages
English (en)
Inventor
Ludger Woelfel
Michael Kuschke
Andreas Timmermann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NAVARASOFT Ltd
Original Assignee
NAVARASOFT Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by NAVARASOFT Ltd filed Critical NAVARASOFT Ltd
Priority to DE19858163A priority Critical patent/DE19858163A1/de
Publication of DE19858163A1 publication Critical patent/DE19858163A1/de
Ceased legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • G06F16/252Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application

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)
  • Information Transfer Between Computers (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Auslesen von Informationen aus mindestens einem Datenbestand und zum Weiterleiten dieser ausgelesenen Informationen an mindestens eine Client-Applikation und/oder mindestens einen Empfänger unter Verwendung eines elektronischen Geräts, wobei von der mindestens einen Client-Applikation an das Gerät übermittelte Informationen von dem elektronischen Gerät an den jeweiligen Datenbestand weitergeleitet werden, wobei jeder aus einem Datenbestand ausgelesenen Information eine Gruppe von Informationen automatisch eine Kennung zugefügt wird, wobei die Kennung den jeweiligen Datenbestand und/oder die Information selbst kennzeichnet und die Kennung mit an die Client-Applikation bzw. den Empfänger übermittelt wird.

Description

Die Erfindung betrifft ein Verfahren zum Auslesen von In­ formationen aus mindestens einem Datenbestand und zum Weiterleiten dieser ausgelesenen Informationen an minde­ stens eine Client-Applikation.
In der heutigen Welt sind Daten in den verschiedensten Formaten und Datenbankanwendungen auf verteilt angeordne­ ten Speichermedien abgelegt. In der Anfangszeit der elek­ tronischen Datenverarbeitung wurden von Unternehmen in Eigenentwicklung verschiedenste Datenbankformate und -konzepte entwickelt.
Um einen variablen Zugriff auf die verschiedenen Daten­ bankformate zu ermöglichen, existieren heute eine Viel­ zahl von unterschiedlichen Technologien, mittels derer der Zugriff auf Daten unterschiedlicher Anwendung möglich ist. Neben einer großen Menge von spezifischen Schnitt­ stellen zum Zugriff auf Daten verschiedenster Unterneh­ mensanwendung gibt es auch eine Zahl von Ansätzen dieses Problem übergreifend zu lösen.
So existieren z. B. von der Firma Microsoft® die Schnitt­ stellensysteme OLE DB sowie ODBC. Mittels dieser Schnitt­ stellen ist es möglich, Daten aus verschiedenen relatio­ nalen und nicht relationalen Datenquellen auszulesen so­ wie Daten in diese Datenbanken hineinzuschreiben. Mittels dieser Interfacetechniken ist es relativ leicht möglich, neue Anwendungen an bereits bestehende Datenbanken und Plattformen anzubinden. Das Microsoft Konzept ermöglicht somit einen einheitlichen Zugriff auf verschiedenste Da­ ten und Datenbankformate.
Zudem existiert ein UN-Standard zum Austausch von struk­ turierten Nachrichten zwischen unterschiedlichen Organi­ sationen und Unternehmen aus den Bereichen Verwaltung, Handel und Transport. Dieser Standard wird auch EDIFACT (Electronic Data Interchange For Administration Commerce Transport) genannt. Innerhalb dieses Standards werden so­ genannte Konverter eingesetzt, welche Informationen aus Unternehmensanwendungen extrahieren und in die normierte Form von EDIFACT überführen. Diese Konverter werden auch zur Übermittlung dieser Nachrichten an den entsprechenden Empfänger eingesetzt.
Ferner existiert das System CORBA (The Common Object Re­ quest Broker Architecture) welches 1991 von der Object Managment Group (OMG) vorgestellt wurde. CORBA ermöglicht die Kommunikation unterschiedlichster Anwendungen an von­ einander getrennten Orten. CORBA definiert datenübertra­ gungsneutrale Austauschformate für die unterschiedlichen und miteinander zu verknüpfenden Applikationen. Die Ab­ bildung der Formate wird statisch vorgenommen. Ein geän­ dertes Format erfordert ein Re-Design und eine erneute Übersetzung der Applikation. Der Fokus liegt bei CORBA auf der Verteilung und Auffindung von Informationen.
Nachteilig bei den vorbeschriebenen Systemen ist, daß die Applikationen direkt und statisch mit den Datenbanken bzw. Beständen oder anderen Applikationen verknüpft sind bzw. sein müssen, und daß bei sich ändernden Strukturen die Applikationen neu erstellt bzw. die Zuordnungs-Links neu definiert werden müssen. Ein weiterer Nachteil bei diesen Systemen ist, daß ein Zugriff auf Daten einer Da­ tenbank nur dann erfolgen kann, wenn die Datenbank einen sofortigen Zugriff zuläßt. Umgekehrt können Daten aus der Datenbank nur dann der jeweiligen Client-Applikation übergeben werden, wenn diese mit dem Datenbestand direkt verbunden ist.
Aufgabe der vorliegenden Erfindung ist es daher, ein Ver­ fahren bereitzustellen, mittels dem es möglich ist, In­ formationen zwischen einem Datenbestand und einer Client- Applikation auszutauschen, ohne das die Client- Applikation permanent mit dem den jeweiligen Datenbestand verwaltenden elektronischen Gerät in Verbindung ist.
Diese Aufgabe wird erfinderisch durch ein Verfahren mit den Merkmalen des Anspruchs 1 gelöst. Weitere erfinderi­ sche Ausgestaltungen des Verfahrens gemäß Anspruch 1 er­ geben sich durch die Merkmale der Unteransprüche.
Mittels des erfindungsgemäßen Verfahrens ist es möglich, beliebige EDV-Anwendungen miteinander zu koppeln. Ver­ schiedene Unternehmensanwendungen unterscheiden sich oft grundlegend in Bezug auf die Art und Weise mit der sie Informationen für andere Anwendungen bereitstellen. Häu­ fig ist eine solche Möglichkeit nicht direkt vorgesehen. Entsprechende Schnittstellen können, falls vorhanden, als sogenannte APIs oder auch als Datenbankschnittstellen ausgelegt sein. So wie sich die Zugriffsschnittstellen unterscheiden, unterscheiden sich auch die Darstellungs­ formate von Daten, die in Unternehmensanwendungen zum Einsatz kommen. Die Darstellungsformate von Daten sind somit ebenso als Informationen von Datenbeständen anzuse­ hen, welche es gilt zwischen den einzelnen Unterneh­ mensapplikationen bzw. zwischen einem Datenbestand und einer Client-Applikation, auszutauschen. Auch hierfür ist das erfindungsgemäße Verfahren geeignet.
Das erfindungsgemäße Verfahren bedient sich der bekannten Technologien zur Transformation und Übertragung von sta­ tischen Informationen aus unterschiedlichen Applikatio­ nen. Das erfindungsgemäße Verfahren ist jedoch darüber hinaus in der Lage, auch dynamische Informationen zwi­ schen den Datenbeständen und den Client-Applikationen auszutauschen. Das Verfahren kann auch als ein Applikati­ onsadapter angesehen werden, welcher zwischen die Daten­ bestände und dem mindestens einen Empfängern bzw. dessen verwendeter Client-Applikation(en) geschaltet ist.
Unter dynamischen Informationen versteht man das Verhal­ ten bzw. das sich Ändern von Unternehmensanwendungen, al­ so um Ereignisse, die sich in der normalen Nutzung der Unternehmensanwendung ergeben. Beispiele für solche Er­ eignisse sind das Einfügen oder Ändern von Datensätzen. Diese Information muß zusammen mit der entsprechenden statischen Information den jeweiligen Empfängern bereit­ gestellt werden.
Mittels des erfindungsgemäßen Verfahrens ist es möglich, daß der aktuelle Stand von Datenbeständen jeweils zwi­ schengespeichert und für den zu verschiedensten Zeiten erfolgenden Zugriff der Client-Applikationen zur Verfü­ gung gestellt wird.
Bedingt durch die flexible Auslegung und Ausgestaltung des erfindungsgemäßen Verfahrens ist die Verarbeitung von strukturierten und unstrukturierten Daten unter zu Hilfe­ nahme von bekannten Technologien und Interfaces bzw. Zu­ griffstechnologien auf Daten relationaler Datenbanken oder z. B. E-mail-Anwendungen problemlos möglich. So wird mittels des vorgestellten Verfahrens eine übergreifende Technologie bereitgestellt, die die jeweiligen, meist auf einen speziellen Bereich beschränkten Technologien zusam­ menfaßt. Auch ist das Zuordnen und die Zustellung von In­ formationen an andere Komponenten problemlos möglich. Es ist oft so, daß im Zuge der Verarbeitung einer Informati­ on die Notwendigkeit erwächst, Informationen anderer An­ wendungen gleichfalls zu verarbeiten und bereitzustellen. Auch hierfür ist das erfindungsgemäße Verfahren anwend­ bar.
Bedingt durch das vorteilhafte Zwischenspeichern von Da­ tensätzen aus Unternehmensanwendungen ist ein Sperren bzw. Locking der Datensätze in den Datenbeständen nicht notwendig. Durch einen geeigneten Datensynchronisations­ prozeß werden die Daten bzw. Informationen sowie deren Struktur und Darstellung stets auf dem Server bzw. dessen zugeordnetem Speicher aktuell gehalten.
Es ist selbstverständlich, daß mittels des Verfahrens Da­ ten über verschiedenste Übertragungsstrecken bzw. Medien übertragen werden können.
Beim Auslesen von Informationen aus Datenbeständen er­ folgt eine Transformation von Metadaten der Datenbestände in ein einheitliches Metadaten-Model. Die transformierten Informationen im einheitlichen Metadaten-Model werden mit einer individuellen Kennung versehen zwischengespeichert und hierdurch für das Übergeben an die jeweiligen Empfän­ ger bereitgestellt. Die Empfänger können sich zu beliebi­ gen Zeitpunkten mit dem elektronischen Gerät und dem hiermit verbundenen Speicher verbinden, wobei nach dem Verbinden die jeweiligen Informationen an den Empfänger übertragen werden. Hiernach kann sich der Empfänger wie­ der vom elektronischen Gerät abkoppeln und im abgekoppel­ ten Zustand die Informationen verändern oder neue Infor­ mationen auf Basis der Strukturen bereits bestehender In­ formationen erstellen. Sofern sich der Empfänger erneut an das elektronische Gerät anschließt, werden bevorzugt nur die Informationen, welche verändert oder neu hinzuge­ fügt worden sind an das elektronische Gerät übermittelt und umgehend an den jeweiligen Datenbestand überführt. Bei dem Überführen von dem elektronischen Gerät zum je­ weiligen Datenbestand wird eine Rücktransformation vorge­ nommen, wobei das Verfahren automatisch die Strukturen abgleicht und bei einem Fehlschlagen des Abgleichungsvor­ gangs ein Signal erzeugt, wonach z. B. ein Administrator manuell die Rückführung der Informationen in den jeweili­ gen Datenbestand vornehmen kann, wodurch ein Verlust von Informationen ausgeschlossen werden kann.
Es ist zudem vorteilhaft möglich, Profile für einen Emp­ fänger oder auch eine Gruppe von Empfängern zu definie­ ren, so daß an diese jeweils bestimmte Informationen au­ tomatisch von bestimmten Datenbeständen übertragen wer­ den, so daß diesen Empfänger stets die aktuellen Informa­ tionen der Datenbestände zur Verfügung steht. Hierbei ist es möglich, Informationen von bestimmen Datenbeständen mit Informationen des gleichen Datenbestandes oder ande­ rer Datenbestände zu koppeln, so daß beim Auslesen von Informationen zusätzliche Informationen anderer Datenbe­ stände ebenfalls mit ausgelesen und gleichzeitig mit an den jeweiligen Empfänger übertragen werden.
Es ist ebenfalls möglich, daß Datenbestände Informationen mittels eines Notifikationsmechanismus automatisch an den Adapter übertragen, sofern sich diese geändert haben. Hierbei ist es möglich, nicht die Information an sich, sondern lediglich Nachrichten bzw. Notifikationen an den Server oder Adapter zu senden, so daß dieser daraufhin die Informationen aus dem jeweiligen Datenbestand aus­ liest. Es ist zudem möglich, den Adapter derart einzu­ richten, daß er in bestimmten Zeitabständen Datenbestände überprüft und bei sich geänderten Daten bzw. Informatio­ nen diese ausliest und zur Weiterübertragung an den mit diesen Informationen verknüpften Empfänger speichert.
Zudem ist es mittels des Verfahrens möglich, Formularlay­ out und -strukturdaten für deren Weiterverarbeitung in einem Formulargestaltungswerkzeug bereitzustellen, so daß Formularlayout und -strukturdaten ebenfalls aktuell zwi­ schengespeichert werden können und die Client- Applikationen automatisch den geänderten Formularlayouts und -strukturdaten der jeweiligen Datenbestände bzw. des einheitlichen Metadaten-Models angepaßt werden können. Derartige Informationen über Formular-Layouts können auch auf dem Server bzw. dem elektronischen Gerät des erfin­ dungsgemäßen Verfahrens generiert und gespeichert sein und werden bei Bedarf an die jeweilige Client-Applikation übermittelt.
Mittels des erfindungsgemäßen Verfahrens bzw. Adapters ist somit die Überwachung von Informationen und deren Zu­ standsänderungen möglich. Unter Zustandsänderung versteht man hierbei das Erzeugen von neuen Informationen, das Verändern bestehender und das Löschen vorhandener Infor­ mationen.
Wie bereits ausgeführt, sind Informationen strukturiert in Datenbanken oder in unstrukturierten Datenquellen ab­ gelegt. Im Falle eines E-mail-Systems besteht diese Struktur beispielsweise aus den Informationseinheiten "Absender", "Empfänger", "Betreff" und "Text". Diese Be­ schreibung der Informationseinheiten werden im folgenden als Metadaten bezeichnet. Im Beispiel einer E-Mail sind diese Metadaten statisch. Bei einer Datenbank für ein Lieferantensystem sind diese Metadaten dagegen veränder­ bar. Bei den Zustandsänderungen derartiger Metadaten wird wie folgt unterschieden:
  • 1. Das Erzeugen von neuen Metadaten (erstellen einer neuen Tabelle in der Datenbank)
  • 2. Das Verändern bestehender Metadaten (hinzufügen, löschen oder ändern einer Tabelle)
  • 3. Das Löschen vorhandener Metadaten (löschen einer Tabelle, einer Datenbank)
Auch diese Vorgänge werden als Zustandsänderung betrach­ tet und vom Verfahren bzw. Adapter überwacht.
Nachfolgend wird das erfindungsgemäße Verfahren anhand von Zeichnungen näher erläutert.
Es zeigen:
Fig. 1 eine Architektur für die Anwendung des erfin­ dungsgemäßen Verfahrens;
Fig. 2 ein Ablaufdiagramm für die Konfiguration des erfindungsgemäßen Verfahrens für eine Architek­ tur gemäß Fig. 1;
Fig. 3 schematische Darstellung der Ereignisverarbei­ tung beim Verfahren,
Fig. 4 ein Ablaufdiagramm zur Abfrage, Transformation und Weitergabe von Informationen,
Fig. 5 ein Ablaufdiagramm für das Rücksenden von einer Client-Applikation an den zugehörigen Datenbe­ stand.
Die Fig. 1 zeigt eine mögliche Architektur, für welche das erfindungsgemäße Verfahren einsetzbar ist. Die Archi­ tektur ist in die Bereiche A, B und C unterteilt. Der Be­ reich A kennzeichnet mögliche Datenbestände, wie z. B. ei­ ne OLE DB-Datenbank, SAP R/3-System, ein Help-Desksystem, ein Dateisystem oder einen E-mail-Server. Der Bereich C kennzeichnet Empfänger, wie z. B. die beiden Clients A und B. Die Clients können über beliebige Übertragungsstrecken und/oder -netze mit dem Server verbunden werden, welcher im Bereich B angeordnet ist. Der Server speichert Anwen­ dungsdaten, Strukturinformationen, Nutzerinformationen oder Formularinformationen, welche nachfolgend allgemein mit Informationen bezeichnet werden. Der Server kann dazu genutzt werden, daß Verfahren zu steuern.
Über spezielle Schnittstellenadapter, wie z. B. ein ODBC- Adapter zum Zugriff auf Datenbanken oder einen SAP R/3- Adapter zum Zugriff auf SAP R/3-Systeme, können Daten zwischen den Bereichen A und C ausgetauscht werden. Wich­ tig ist hierbei, daß die aus dem Bereich A ausgelesenen Informationen jeweils mit einer Kennung versehen werden, welche mit an die Clients A und B des Bereichs C übermit­ telt werden. Wenn die Informationen von den Client- Applikationen A oder B zurück an den Server übergeben werden, besitzen sie immer noch ihre Kennung, wodurch der Server des Bereichs B in der Lage ist, die Informationen an den richtigen Datenbestand zurückzuübergeben. Der Ser­ ver des Bereichs B weist Speichermedien auf, welche die Anwendungsdaten, Strukturinformationen, Nutzerinformatio­ nen und Formularinformationen zwischenspeichern.
Zur Initialisierung des Verfahrens für jeden Empfänger bzw. jede Art von Client-Applikation und die zugehörigen Datenbestände, werden in einem ersten Schritt, wie in Fig. 2 dargestellt, über die jeweiligen Adapter vorhandene Metadaten der Datenbestände des Bereichs A eingelesen und in ein internes Format konvertiert. Dabei werden die er­ mittelten Datentypen auf die internen Datentypen des Ad­ apters umgesetzt.
Interne Datentypen sind z. B.:
  • 1. Number (int, short, long, byte, word, dword)
  • 2. Decimal (float, double)
  • 3. Date
  • 4. Time
  • 5. Timestamp
  • 6. String
  • 7. BLOB (Binary Large Object)
  • 8. Compound data types (Strukturen)
Alle Datentypen verfügen über Attribute, die beispiels­ weise im Fall des Datentyps String die maximale Länge festlegen. Das interne Format dieser Informationen ist z. B. XML.
Ein Beispiel für E-mail-Metadaten ist:
Die Konvertierung der Metadaten in das interne Format kann je nach Auslegung und Mächtigkeit des Systems entwe­ der automatisch oder aber auch manuell erfolgen.
Nachdem z. B. die Nutzerinformationen übernommen bzw. kon­ vertiert worden sind (Programmschritt 2.1) kann das Ver­ fahren derart eingerichtet werden, daß entweder ein Noti­ fikationshändler (2.3) installiert wird oder ein Timer (2.2) zur Abfrage von Nutzerinformationen eingerichtet wird, der ermöglicht, daß in bestimmten Zeitintervallen die Nutzerinformation aus dem jeweiligen Datenbestand ausgelesen und mit den gespeicherten Informationen ver­ glichen wird und somit stets die aktuellsten Nutzerinfor­ mationen vom Server verwaltet und gespeichert werden. Das Einrichten eines Timers zur Abfrage von Nutzerinformatio­ nen geschieht im Schritt 2.4. Anschließend wird in den Schritten 2.5 bis 2.8 die Formularinformation übernommen und entsprechend der Möglichkeiten der jeweiligen Daten­ bestände im Bereich A ein Notifikationshändler eingerich­ tet (Schritt 2.7).
Ein Notifikationshändler kann nur dann eingerichtet wer­ den, wenn der jeweilige Datenbestand bei Änderung seines Datenbestandes automatisch ein Signal erzeugen kann, der den Server informiert, daß sich der Datenbestand geändert hat, so daß der Server anschließend über den jeweiligen Adapter die Informationen auf seinem Speicher aktualisie­ ren kann. Sofern ein entsprechendes Notifikationssystem bei dem jeweiligen Datenbestand nicht existiert, kann ein entsprechender Timer zur periodischen Abfrage der jewei­ ligen Information eingerichtet werden.
Für die Initialisierung der Strukturinformationen werden die Schritte 2.9 bis 2.12, für die Initialisierung der Anwendungsdaten werden die Schritte 2.13 bis 2.16 durch­ geführt. Hiernach ist die Initialisierung des Systems ab­ geschlossen. Es versteht sich von selbst, daß die Initia­ lisierung auch in anderer Reihenfolge erfolgen kann.
Sofern ein Notifikationshändler installiert worden ist, wird nachfolgend von passiver Überwachung gesprochen. Die passive Überwachung wird gewählt, wenn die Zielapplikati­ on bzw. der Informationslieferant ein Notifikationsmecha­ nismus bereit stellt. Als Beispiel kann das Remedy ARS System dienen. In diesem System kann sich eine Applikati­ on als Empfänger für Notifikation registrieren. Bei jeder Informationsänderung innerhalb des Systems werden alle registrierten Empfänger über diese Zustandsänderung be­ nachrichtigt (notifiziert). Bestandteil dieser Notifika­ tion ist die Kennung der geänderten Informationsein­ heit/Metadaten. Der Adapter ermittelt und transformiert die Daten und leitet diese an den Server weiter.
Sofern kein Notifikationsmechanismus bereitgestellt kann ein Timer installiert werden. In diesem Fall wird nach­ folgend von aktiver Überwachung gesprochen.
Nach der Initialisierung überwacht das Verfahren die Zu­ standsänderung der Informationen der Datenbestände.
Wie bereits erläutert, wird für jede ausgelesene Informa­ tion eine Kennung generiert, welche der Informationsein­ heit beigefügt wird. Sollte eine Informationseinheit meh­ rere Zustandsänderungen durchlaufen, so sorgt das Verfah­ ren dafür, daß dieser Informationseinheit immer dieselbe Kennung vergeben wird.
Ein Beispiel für das zuordnen einer Kennung zu einer e-Mail ist nachfolgend angegeben:
Die Fig. 3 zeigt ein Ablaufschema für das erfindungsge­ mäße Verfahren im Überblick. Der Start des Systems ist mit 3.0 bezeichnet. Nach dem Start wird die Konfiguration des Systems (3.1) durchgeführt. Die Konfiguration des Sy­ stems ist in Fig. 2 dargestellt und vorgehend beschrie­ ben. Nachdem das System konfiguriert ist, wird eine War­ teschleife 3.2 solange durchlaufen, bis entweder ein Ti­ mer abgelaufen ist und das periodische Abfragen von In­ formationen gestartet wird oder aber eine Notifikation von einem Datenbestand empfangen wird. Hiernach werden die jeweiligen Informationen aus dem Datenbestand abge­ fragt in die interne Modeldarstellung transformiert. Die jeweiligen Programmschritte zum Abfragen, Transformieren und Weitergeben sind mit 3.3 bis 3.6 gekennzeichnet. Der jeweilige Ablauf ist in Fig. 4 detailliert als Flußdia­ gramm dargestellt. Ausgehend von dem Programmschritt 4.0, welcher z. B. dem Konfigurieren des Systems (Schritt 3.1 der Fig. 3) entsprechen kann, wird zu Beginn eine Abfra­ ge dahingehend durchgeführt, ob ein Timer installiert ist (aktive Überwachung) oder ob eine passive Überwachung durchgeführt werden soll. Sofern eine passive Überwachung installiert ist, wird der Programmschritt 4.3 ausgeführt, wodurch das System auf eine Notifikation für die jeweili­ ge Information des jeweiligen Datenbestandes wartet. So­ fern die aktive Überwachung eingerichtet ist, wird ausge­ hend von Programmschritt 4.1 zum Programmschritt 4.2 ver­ zweigt, woraufhin der Timer initialisiert wird und auf den Ablauf des Timers gewartet wird.
Nachdem eine Notifikation empfangen oder der Timer abge­ laufen ist wird Programmschritt 4.4 ausgeführt, wobei die Informationen aus dem jeweiligen Datenbestand abgefragt werden. Anschließend werden die Informationen gemäß Pro­ grammschritt 4.5 in die interne Modeldarstellung trans­ formiert und gespeichert. Sofern ein Weiterleiten der In­ formationen an den jeweiligen Empfänger möglich ist, wer­ den die Informationen im Schritt 4.6 an diesen weiterge­ geben. Sofern zusätzliche Informationen mit den bereits abgefragten Informationen verknüpft sind, wird die Schleife bestehend aus dem Programmschritten 4.4 bis 4.6 und 4.7 solange durchlaufen, bis sämtliche Informationen abgefragt sind. Hiernach verzweigt das Verfahren je nach gewählter Überwachungsart (aktiv oder passiv) zu den Schritten 4.2 oder 4.2.
Der Programmablauf gemäß der Fig. 4 kann für sämtliche Informationen wie z. B. Anwendungsdaten, Strukturinforma­ tionen oder Formularinformationen identisch sein.
Die Verzweigung gemäß Programmschritt 4.7, bei der anhand vorgegebener Regeln überprüft wird, ob abhängige Informa­ tionen aus anderen Datenbeständen extrahiert oder an die­ se gesandt werden müssen, ist abhängig von den eingerich­ teten Profilen und Regeln. Diese Regeln definieren mit­ tels der Metadaten die Abhängigkeit zwischen zwei Infor­ mationstypen. Abhängige Informationseinheiten werden über den Wert eines Feldes bestimmt. Alle Informationseinhei­ ten des als abhängig definierten Adapters, in denen bei einem definierten Feld die gleichen Werte enthalten sind, werden abgefragt bzw. extrahiert und nach dem oben be­ schriebenen Verfahren übermittelt.
Die Fig. 5 beschreibt das Zurücksenden von Informationen von einer Client-Applikation an den jeweiligen Datenbe­ stand. Neue oder geänderte Informationen werden von der Client-Applikation an das System übermittelt. Anhand der übergebenen Kennung kann der Adapter die Information in dem jeweiligen Datenbestand bzw. der Zielapplikation er­ mitteln und entsprechend, abhängig vom Status neu eintra­ gen oder überschreiben oder aber auch löschen. Sofern die Daten nicht direkt an die Zielapplikation bzw. den Daten­ bestand weitergeleitet werden können, werden diese vom Server auf seinem Speichermedium zwischengespeichert. So­ bald ein Weiterleiten möglich ist, wird dies über den je­ weiligen Adapter erfolgen und je nach Status die zwi­ schengespeicherte Information auf dem zugeordneten Spei­ cher gelöscht.

Claims (14)

1. Verfahren zum Auslesen von Informationen aus mindes­ tens einem Datenbestand und zum Weiterleiten dieser ausgelesenen Informationen an mindestens eine Cli­ ent-Applikation und/oder mindestens einen Empfänger unter Verwendung eines elektronischen Geräts, wobei von der mindestens einen Client-Applikation an das Gerät übermittelte Informationen von dem elektroni­ schen Gerät an den jeweiligen Datenbestand weiterge­ leitet werden, wobei jeder aus einem Datenbestand ausgelesenen Information oder Gruppe von Informatio­ nen automatisch eine Kennung zugefügt wird, wobei die Kennung den jeweiligen Datenbestand und/oder die Information selbst kennzeichnet und die Kennung mit an die Client-Applikation bzw. den Empfänger über­ mittelt wird.
2. Verfahren nach Anspruch 1, dadurch ge­ kennzeichnet, daß die Kennung mindestens eine Bestimmungsadresse eines Empfängers beinhaltet oder eine weitere Kennung zugefügt wird, die die mindestens eine Bestimmungsadresse beinhaltet.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die Informationen auf mindestens einem dem elektronischen Gerät zuge­ ordneten Speicher gespeichert werden.
4. Verfahren nach einem der Ansprüche 1 bis 3, da­ durch gekennzeichnet, daß die Über­ mittlung von Information von einem Datenbestand an eine Client-Applikation bzw. einen Empfänger auf­ grund einer Anforderung der Client-Applikation oder des Empfängers, in vorbestimmbaren Zeitintervallen oder aufgrund einer Änderung der Informationen des Datenbestandes erfolgt.
5. Verfahren nach Anspruch 4, dadurch ge­ kennzeichnet, daß mindestens ein Anforde­ rungsprofil und/oder mindestens eine Verknüpfungsre­ gel für jede Client-Applikation und/oder jeden Emp­ fänger oder für Gruppen von Empfängern definierbar ist, anhand derer Informationen aus den Datenbestän­ den ausgewählt werden und zur Weiterleitung an eine oder mehrere Client-Applikationen oder Empfänger auf dem Speicher zwischengespeichert werden.
6. Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, daß in vorbestimmbaren Zeitintervallen, welche insbesondere durch das je­ weilige Anforderungsprofil definierbar sind, die be­ reits aus dem jeweiligen Datenbestand ausgelesenen und auf dem Speicher gespeicherten Informationen mit den Informationen des jeweiligen Datenbestandes hin­ sichtlich Änderungen verglichen werden und bei geän­ derter Information des jeweiligen Datenbestandes die neue Information des Datenbestandes auf dem Speicher gespeichert wird.
7. Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, daß aufgrund einer Mit­ teilung des Datenbestandes selbst, die bereits aus dem jeweiligen Datenbestand ausgelesenen und auf dem Speicher gespeicherten Informationen mit den im Da­ tenbestand gespeicherten neuen Informationen über­ schrieben oder ergänzt werden.
8. Verfahren nach Anspruch 6 oder 7, dadurch gekennzeichnet, daß bei nächster Gele­ genheit oder zu vorbestimmbaren Zeiten die neu ge­ speicherte Information bzw. Gruppe von Informationen an die jeweilige Client-Applikation oder den jewei­ ligen Empfänger übermittelt wird.
9. Verfahren nach Anspruch 7 oder 8, dadurch gekennzeichnet, daß das elektronische Gerät eine Nachricht generiert, sofern ein Anpassen bzw. Zuordnen der alten, bereits gespeicherten In­ formation an die neue Struktur der neuen Information automatisch nicht möglich ist.
10. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß das elektronische Gerät eine Nachricht generiert, sofern ein Anpassen bzw. Zuordnen der von der Client- Applikation oder dem Empfänger zurückgelieferten In­ formation(en) mit dem auf dem Speicher oder in dem jeweiligen Datenbestand gespeicherten Informati­ on(en) nicht möglich ist.
11. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß von einer Client-Applikation nur Informationen an das elektronische Gerät übermittelt werden, die von der Client-Applikation neu erzeugt oder verändert worden sind, wobei diese Informationen anschließend von dem elektronischen Gerät an den jeweiligen Datenbestand übermittelt werden.
12. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß eine Verknüpfung und/oder Zuordnung zwischen den Daten­ strukturen und/oder Programmasken zwischen dem min­ destens einen Datenbestand und der mindestens einen Client-Applikation vorgebbar ist.
13. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß in Abhängigkeit der aus einem Datenbestand ausgelesenen Information(en) weitere Informationen zur Weiterlei­ tung an einen Adressaten oder eine Client- Applikation aus weiteren Datenbeständen ausgelesen werden und auf dem Speicher gespeichert werden.
14. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß eine Information eine E-Mail, ein Datensatz aus einer Da­ tenbank, ein Dokument, eine Datenbankstruktur, der Aufbau einer Benutzerschnittstelle ist.
DE19858163A 1998-12-16 1998-12-16 Verfahren zum Übertragen von Informationen zwischen Datenbeständen Client-Applikationen Ceased DE19858163A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE19858163A DE19858163A1 (de) 1998-12-16 1998-12-16 Verfahren zum Übertragen von Informationen zwischen Datenbeständen Client-Applikationen

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE19858163A DE19858163A1 (de) 1998-12-16 1998-12-16 Verfahren zum Übertragen von Informationen zwischen Datenbeständen Client-Applikationen

Publications (1)

Publication Number Publication Date
DE19858163A1 true DE19858163A1 (de) 2000-06-21

Family

ID=7891355

Family Applications (1)

Application Number Title Priority Date Filing Date
DE19858163A Ceased DE19858163A1 (de) 1998-12-16 1998-12-16 Verfahren zum Übertragen von Informationen zwischen Datenbeständen Client-Applikationen

Country Status (1)

Country Link
DE (1) DE19858163A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10045080A1 (de) * 2000-09-12 2002-03-28 Ganesh Puri Sebastian Jung Verfahren und Vorrichtung zur Aufzeichnung und Ausführung von Abfragen aus Datennetzen
EP1271362A2 (de) * 2001-06-20 2003-01-02 Navarasoft Limited Verfahren zum Behandeln einer Abfrage
DE10157633A1 (de) * 2001-11-26 2003-08-28 Siemens Ag Medizinische Systemarchitektur mit einer komponentenorientierten Architektur zur Befundung und Dokumentation
EP1755046A1 (de) * 2005-08-17 2007-02-21 Deutsche Post AG Verfahren und Anordnung von Vorrichtungen zur Bereitstellung von Daten mehrerer Datensysteme an wenigstens einem Client

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19712470A1 (de) * 1997-03-25 1998-10-01 Ibm Übertragen von Daten mittels dynamisch programmierbaren Datenobjekten in heterogenen Netzen
DE19725264A1 (de) * 1997-04-09 1998-10-15 Ibm Verfahren und Einrichtung zur Optimierung der Auslastung von Leitungsressourcen bei Informationsanforderungen in einem Informationsnetz
DE19712127A1 (de) * 1997-03-22 1998-10-22 Lutz Dr Hagner Vorrichtung zum Zwischenspeichern von Programmteilen in lokalen Netzen ohne lokale oder lokal zentralisierte Programm- oder Daten- und Programmspeicherung zur Beschleunigung der Programmabarbeitung und Optimierung der Datenübertragung zu entfernt stehenden zentralen Applikations- und Datenservern

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19712127A1 (de) * 1997-03-22 1998-10-22 Lutz Dr Hagner Vorrichtung zum Zwischenspeichern von Programmteilen in lokalen Netzen ohne lokale oder lokal zentralisierte Programm- oder Daten- und Programmspeicherung zur Beschleunigung der Programmabarbeitung und Optimierung der Datenübertragung zu entfernt stehenden zentralen Applikations- und Datenservern
DE19712470A1 (de) * 1997-03-25 1998-10-01 Ibm Übertragen von Daten mittels dynamisch programmierbaren Datenobjekten in heterogenen Netzen
DE19725264A1 (de) * 1997-04-09 1998-10-15 Ibm Verfahren und Einrichtung zur Optimierung der Auslastung von Leitungsressourcen bei Informationsanforderungen in einem Informationsnetz

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10045080A1 (de) * 2000-09-12 2002-03-28 Ganesh Puri Sebastian Jung Verfahren und Vorrichtung zur Aufzeichnung und Ausführung von Abfragen aus Datennetzen
DE10045080C2 (de) * 2000-09-12 2003-03-20 Ganesh Puri Sebastian Jung Verfahren und Vorrichtung zur Aufzeichnung und Ausführung von Abfragen aus Datennetzen
EP1271362A2 (de) * 2001-06-20 2003-01-02 Navarasoft Limited Verfahren zum Behandeln einer Abfrage
EP1271362A3 (de) * 2001-06-20 2005-10-12 Navarasoft Limited Verfahren zum Behandeln einer Abfrage
DE10157633A1 (de) * 2001-11-26 2003-08-28 Siemens Ag Medizinische Systemarchitektur mit einer komponentenorientierten Architektur zur Befundung und Dokumentation
EP1755046A1 (de) * 2005-08-17 2007-02-21 Deutsche Post AG Verfahren und Anordnung von Vorrichtungen zur Bereitstellung von Daten mehrerer Datensysteme an wenigstens einem Client
WO2007019996A1 (de) * 2005-08-17 2007-02-22 Deutsche Post Ag Verfahren und anordnung von vorrichtungen zur bereitstellung von daten mehrerer datensysteme an wenigstens einem client
JP2009505248A (ja) * 2005-08-17 2009-02-05 ドイチェ ポスト アーゲー 様々なデータシステムのデータを少なくとも1つのクライアントに供給する方法、及びそのための装置の配置

Similar Documents

Publication Publication Date Title
EP1151399B1 (de) Integration heterogener Datenbank-Systeme
EP1194865B1 (de) Verfahren zur datenpflege in einem netzwerk teilweise replizierter datenbanksysteme
DE69936818T2 (de) Protokoll zum Austausch von Konfigurationsdaten in einem Computernetzwerk
DE10049569B4 (de) Zugriff und Aktualisierung einer Konfigurationsdatenbank von verteilten physischen Orten innerhalb eines Prozeßsteuerungssystems
DE10049503B4 (de) Zugriff und Aktualisierung einer Konfigiurationsdatenbank von verteilten Physischen Orten innerhalb eines Prozessteuersystems
DE60310255T2 (de) Skalierbarer datenzugang in einem beliebig grossen dokument
DE60220676T2 (de) Konsistente lesevorgänge in einer verteilten datenbankumgebung
DE69505561T2 (de) Verfahren und gerät um unterbaumstrukturen in einer netzwerkdatei zu verschieben
DE69719564T2 (de) Dynamischer dateiverzeichnisdienst
EP1258812B1 (de) Virtuelle Datenbank heterogener Datenstrukturen
DE69624579T2 (de) System und verfahren für eine verteilte objektverwaltungsumgebung an mehreren orten
DE69832002T2 (de) Übertragungssystem und Übertragungsverfahren,Empfangssystem und Empfangsverfahren
DE3889904T2 (de) Namensverwaltung für ein digitaldatenverarbeitungssystemnetzwerk.
DE10311082B4 (de) Elektronikdokumentmanagementverfahren
DE112017006106T5 (de) Erzeugen von, Zugreifen auf und Anzeigen von Abstammungsmetadaten
DE19607149A1 (de) Verfahren zum rechnergestützten Abgleich mehrerer, in mindestens einem Rechner gespeicherten Dateikopien einer gespeicherten Datei
DE69633373T2 (de) Verfahren und Gerät zur Programmierung eines Aufgabentickets in einem Dokumentenverarbeitungssystem
DE19858163A1 (de) Verfahren zum Übertragen von Informationen zwischen Datenbeständen Client-Applikationen
EP1285315B1 (de) Informationsverarbeitungssystem und verfahren zu dessen betrieb
DE19607132B4 (de) Verfahren zum rechnergestützten Abgleich mehrerer, in mindestens einem Rechner gespeicherten Dateikopien einer gespeicherten Datei
EP0825525B1 (de) Verfahren zur Unterstützung des Erzeugens eines Objektes
EP1675045A1 (de) Austausch von Beschreibungsdaten zwischen Projekten mit Hilfe von Inter-Project-Interfaces
EP1397891A2 (de) Verfahren und system zum netzkonfigurationsmanagement und netzbestandsmanagement
EP1202173A2 (de) System zur effizienten Übertragung von Teilobjekten in verteilten Datenbanken
DE10209794A1 (de) Datenkommunikationssystem

Legal Events

Date Code Title Description
OM8 Search report available as to paragraph 43 lit. 1 sentence 1 patent law
OP8 Request for examination as to paragraph 44 patent law
8131 Rejection