-
Gebiet der Erfindung
-
Die
vorliegende Erfindung betrifft allgemein das Gebiet der elektronischen
Datenverarbeitung und insbesondere ein Computersystem und ein Verfahren
zum Betreiben eines Computersystems zum Aktualisieren strukturierter
Daten.
-
Beschreibung des Stands der
Technik
-
In
WO 02/061612 A2 und
WO 02/061613 A2 sind
eine Datenstruktur für
Informationssysteme bzw. ein Datenbanksystem mit einer optimierten
Abfrageoption offenbart. Diese Dokumente beschreiben verbesserte
Datenstrukturen, auf deren Grundlage ein strukturierte Daten enthaltendes
Datenbanksystem wirksamer betrieben werden kann. Insbesondere enthält ein solches
verbessertes Datenbanksystem eine neue Suchmaschine auf Hauptspeicherbasis
für strukturierte
Daten, die nachstehend als schnelle Suchmaschine bezeichnet wird.
Die Daten befinden sich in Datenstrukturen, die für Lesezugriffe
im Hauptspeicher optimiert sind. Die Daten werden von einer Datenquelle
in der Art eines relationalen Datenbankverwaltungssystems repliziert.
Der Replikationsprozess beinhaltet das Extrahieren der Daten aus
der Datenquelle und das Laden der Daten in die schnelle Suchmaschine,
einschließlich
der Metadaten. Dieser Prozess kann zeitaufwendig sein. Es ist nicht
vorteilhaft, eine solche Anfangsladung regelmäßig zu wiederholen, beispielsweise
um eine spätere
Version der Daten zu erhalten.
-
Die
Rolle der schnellen Suchmaschine ist jene eines sekundären Datenspeichers,
während
die Datenbank noch der Master ist und auch für das Fortbestehen der Daten
verantwortlich ist. Die schnelle Suchmaschine ermöglicht einen
schnellen Zugriff auf die Daten während eines Erzeugungsvorgangs
und stellt ein vollständiges
Indexverhalten bereit. Dies bedeutet, dass anders als im Fall einer
Datenbank keine kostspieligen Auswahlanweisungen infolge fehlender
oder inkorrekter Indizes existieren. Die schnelle Suchmaschine ist
jedoch nicht für
das Fortbestehen der Daten verantwortlich. Diese Aufgabe bleibt noch
der Datenbank überlassen,
während
die schnelle Suchmaschine die Daten dauerhaft in zweidimensionalen
bzw. flachen Dateien hält,
um das Wiedergewinnen unter Verwendung dieser Dateien in einem Notfall
(beispielsweise nach einem Stromausfall) zu ermöglichen. Dies vermeidet eine neue
Anfangsladung der schnellen Suchmaschine. Für diese Dateien werden jedoch,
anders im Fall von Datenbankdateien, keine Sicherungen bzw. Backups erzeugt.
Falls ein Platten-Crash auftritt und Daten innerhalb der schnellen
Suchmaschine verloren gehen, ist eine neue Anfangsladung erforderlich.
-
Der
Zweck der schnellen Suchmaschine besteht darin, einen schnellen
Zugriff auf quasistatische Daten zu ermöglichen, welche eher den Charakter von
Auslegungs- oder Master-Daten als jenen von Transaktionsdaten haben.
Master-Daten weisen nur wenige Änderungen
auf, während
Transaktionsdaten permanent geändert
werden (beispielsweise die Erzeugung neuer Aufträge in einem Call-Center). Der Aktualisierungs mechanismus
des Kerns der schnellen Suchmaschine ist nicht in erster Linie dafür ausgelegt,
sehr große
Aktualisierungsvolumina zu behandeln (wie mehrere Millionen Aktualisierungen
an einer Tabelle pro Tag). Wenn die schnelle Suchmaschine Änderungen
empfängt,
speichert sie diese Änderungen
sofort in einer zweidimensionalen Datei. Die Änderungen werden periodisch
in die Hauptspeicher-Datenstrukturen
der schnellen Suchmaschine eingearbeitet. Dies bedeutet, dass die Änderungen nicht
sofort bei ihrem Empfang, sondern erst zu einem späteren Zeitpunkt
sichtbar sind. Wenn die schnelle Suchmaschine die Änderungen
an eine sendende Anwendung übergibt,
bedeutet dies nicht, dass die Daten bereits in der schnellen Suchmaschine
für die
Anwendung sichtbar sind. Dies bedeutet nur, dass die schnelle Suchmaschine
die Änderungen
erfolgreich in zweidimensionalen bzw. flachen Dateien gespeichert
hat und die Änderungen
in einem Notfall abrufen kann.
-
WO 02/095632 A2 betrifft
ein synchrones Änderungsdaten-Erfassungssystem
und eine Methodologie, wobei für
jede Anweisung einer Transaktion eine Transaktionskennung, welche
jede Transaktion eindeutig identifiziert, zusammen mit den Änderungsdaten
aufgezeichnet wird. Wenn die Transaktion angewiesen wird, werden
die Transaktionskennung und eine Systemänderungsnummer für die Anweisung
in einer Transaktionstabelle aufgezeichnet. Dieses Verfahren ist
zeitlich nicht sehr effizient, weil die grundlegende Notwendigkeit
besteht, jeder Transaktion eine individuelle Transaktionskennung
zuzuweisen.
-
In
dem Dokument "Extracting
Delta for Incremental Data Warehouse Maintenance", Ram P. u.a., Data Engineering, 2000,
Verhandlungen, 16th International Conference, San Diego, CA, USA,
29. Februar–März 2000,
Los Alamitos, CA, USA, Iee Comput. Soc. US, 29. Februar 2000 (2000-02-29),
S. 220–229,
XP010378715, ISBN: 0-7695-0506-6 sind mehrere Verfahren zum Extrahieren
von Änderungen an
Daten in einem Quellensystem, insbesondere Zeitstempel, differenzielle
Schnappschüsse,
Auslöser
und Archivprotokolle, beschrieben und analysiert.
-
In
dem Dokument von Jim Gray Reuter A: "Transaction processing: concepts and
techniques" 1993,
Transaction processing: concepts and techniques, S. 493–525, XP002947548,
Kapitel 9: Log Manager, ist beschrieben, wie ein so genanntes Transaktionsprotokoll
gelesen, geschrieben und gespeichert wird.
-
Das
Problem besteht darin, einen Mechanismus zu spezifizieren, so dass
die Anwendung Änderungen
an der schnellen Suchmaschine bereitstellen kann und die schnelle
Suchmaschine die Transaktionskonsistenz ihrer Daten gewährleisten
kann.
-
Zusammenfassung der Erfindung
-
Eine
Aufgabe der Erfindung besteht daher darin, ein Computersystem und
ein Verfahren zum Betreiben eines Computersystems mit verbesserten Aktualisierungs-
bzw. Updatemechanismen in einer Hauptspeicher-Suchmaschine gespeicherter
strukturierter Daten bereitzustellen. Diese Aufgabe wird durch Vorschlagen
eines Verfahrens zum Betreiben eines Computersystems mit den Merkmalen
des Anspruchs 1, eines Computersystems mit den Merkmalen des Anspruchs
12 und eines Computerprogramms mit den Merkmalen des Anspruchs 18
gelöst.
-
Demgemäß ermöglicht die
Erfindung eine periodisch ausgeführte
Aktualisierung einer Datenmenge, die als Anfangsladung von einer
Datenbank in einem Hauptspeicher einer Suchmaschine gespeichert
wird. Die Suchmaschine ist unter Verwendung in der Datenbank enthaltener
Daten mit einer Anwendung verbunden. Änderungen an der Datenmenge
in der Datenbank, die auftreten, nachdem die Anfangsladung im Suchmaschinen-Hauptspeicher
gespeichert wurde, werden beibehalten, und die periodische Aktualisierung
wird auf der Grundlage dieser beibehaltenen Änderungen ausgeführt.
-
Insbesondere
weist das Verfahren gemäß der Erfindung
folgende Schritte auf:
Übertragen
einer Datenuntermenge der Datenmenge als eine Anfangsladung von
der Datenbank über
die Anwendung zu der Suchmaschine,
Speichern der Anfangsladung
in einem Hauptspeicher der Suchmaschine,
Halten eines Datensatzes
jeglicher Änderungen
in der Datenuntermenge, die aufgetreten sind, seit die Datenuntermenge
als Anfangsladung übertragen und
gespeichert wurde und
Aktualisieren der Anfangsladung in dem
Suchmaschinen-Hauptspeicher
in periodischer Weise in vorgebbaren Zeitintervallen auf der Grundlage
des Datensatzes.
-
Gemäß einer
Ausführungsform
der Erfindung beinhaltet der Schritt des Haltens das Weiterleiten
eines Datensatzes der Änderungen
zu einem Funktionsmodul einer Dienstanwendungs programm-Schnittstelle
der Anwendung. Die Erfindung kann mit der Anwendung verwirklicht
werden, die eine so genannte Dienstanwendungsprogramm-Schnittstelle
(API) aufweist, welche aus einer Sammlung von Funktionsmodulen besteht,
welche spezielle Anforderungen der Anwendung bei der Verbindung
mit der Suchmaschine erfüllen.
-
Gemäß einer
Ausführungsform
der Erfindung kann der Datensatz von Änderungen eine Protokollierungstabelle
sein. Die Protokollierungstabelle gemäß der Erfindung ist das zentrale
Element bei der Aktualisierungskommunikation zwischen einer Anwendung
und einer Suchmaschine gemäß einer
Ausführungsform
der vorliegenden Erfindung. Die Protokollierungstabelle ist eine
transparente Tabelle, die sich vorteilhafterweise in der Anwendungsdatenbank befindet.
-
Gemäß einer
weiteren Ausführungsform
der Erfindung weist der Datensatz von Änderungen einen Schlüsselabschnitt
und einen Datenabschnitt auf, wodurch ein schnelles und zuverlässiges Identifizieren
eines Protokollierungsdatensatzeintrags ermöglicht wird. Vor dem Ändern in
der Protokollierungstabelle gespeicherter Daten werden sie in ihren Schlüsselabschnitt
und ihren Datenabschnitt zerlegt. Diese beiden Abschnitte oder Teile
werden getrennt in der Protokollierungstabelle gespeichert.
-
Zum
Gewährleisten
der Datenkonsistenz verriegelt das Funktionsmodul die Protokollierungstabelle
während
des Schritts des Speicherns des Datensatzes von Änderungen in der Protokollierungstabelle.
Beispielsweise ist das Verriegeln ein Verriegeln auf Zeilenebene
an Stelle des Verriegelns der gesamten Tabelle, wodurch die Wahrscheinlichkeit so
genannter Serialisierungseffekte in der Protokollierungstabelle
bzw. den Protokollierungstabellen verringert wird.
-
Die
Erfindung betrifft auch ein Computerprogramm mit einer Programmcodiereinrichtung,
welche für
das Ausführen
eines vorstehend beschriebenen erfindungsgemäßen Prozesses geeignet ist,
wenn das Computerprogramm auf einem Computer läuft. Das Computerprogramm selbst
sowie in einer auf einem computerlesbaren Medium gespeicherten Form werden
beansprucht.
-
Weitere
Merkmale und Ausführungsformen der
Erfindung werden anhand der Beschreibung und der anliegenden Zeichnung
verständlich
werden.
-
Es
sei bemerkt, dass die vorstehend erwähnten Merkmale und jene, die
nachstehend beschrieben werden, nicht nur in der spezifizierten
Kombination, sondern auch in anderen Kombinationen oder für sich verwendet
werden können,
ohne vom Schutzumfang der vorliegenden Erfindung abzuweichen.
-
Die
Erfindung ist in der Zeichnung anhand einer Ausführungsform beispielhaft schematisch
dargestellt und wird nachstehend detailliert mit Bezug auf die Zeichnung
erklärt.
Es sei bemerkt, dass die Beschreibung den Schutzumfang der vorliegenden Erfindung
in keiner Weise einschränkt
und lediglich eine Ausführungsform
der Erfindung erläutert.
-
Kurzbeschreibung der Zeichnung
-
Es
zeigen:
-
1 eine
schematische Darstellung eines Datenbankaktualisierungsmechanismus
und -systems gemäß der Erfindung,
-
2 in
weiteren Einzelheiten eine Protokollierungstabelle gemäß der Erfindung,
-
die 3 bis 11 sequenzielle
Schreib-, Lese- und Aktualisierungsschritte in Bezug auf die Protokollierungstabelle
gemäß der Erfindung,
-
12 ein
Flussdiagramm für
einen in Zusammenhang mit der Protokollierungstabellen-Datenübertragung
verwendeten Packungsalgorithmus und
-
13 eine
Zeitachse mit einer Sequenz von Arbeitsschritten zum Gewährleisten
der Transaktionsdatenkonsistenz.
-
Detaillierte Beschreibung
-
1 zeigt
eine Ausführungsform
eines Datenbanksystems gemäß der vorliegenden
Erfindung, das allgemein mit 10 bezeichnet ist. Das Datenbanksystem 10 gemäß der Erfindung
weist eine auf einem Host-Computer (nicht dargestellt) laufende
Anwendung 12, eine vorstehend erörterte schnelle Suchmaschine 14 sowie
eine Anwendungsdatenbank 16, die eine Anwendungsdatenmenge
enthält,
auf.
-
Die
Datenbank 16 ist mit der Anwendung 12 über eine
Datenbankschnittstelle 18 verbunden. Die Anwendung weist
weiter eine Dienstanwendungsprogramm-Schnittstelle (API) 20 zum
Verbinden der Anwendung 12 mit der Suchmaschine 14 auf.
-
Die
API 20 ist eine Sammlung geeigneter Funktionsmodule oder
-methoden, wie in 1 durch die gestrichelten Linien 21 in
der Schnittstelle 20 dargestellt ist. Die Funktionsmodule
oder -methoden 21 stellen die API-Funktionalität bereit.
Die Suchmaschine 14 weist wiederum auch eine entsprechende
API 22 auf. Die Anwendung 12 kommuniziert mit der
Suchmaschine 14 über
diese Dienst-API 20, d.h. durch Aufrufen von Funktionsmodulen 21 in
der Dienst-API 20 und
Empfangen der Antwort in Form der Ausgabeparameter eines Funktionsmoduls.
-
Die
Funktionsmodule 21 in der Dienst-API 20 und ihre
Ein- und Ausgabeparameterlisten
werden entsprechend den Anforderungen der Anwendung 12 ausgelegt.
Beispielsweise ist für
die Anwendung "Segment
Builder" in mySAP
CRM Marketing ein Funktionsmodul erforderlich, das Auswahlanweisungen
in disjunktiver Normalform empfängt
und eine Liste von Zählergebnissen
zurückgeben
kann, welche als ein Kuchendiagramm auf der Benutzerschnittstelle
dargestellt werden.
-
Das
Computersystem 10 ist in eine Anwendungsseite A und eine
Suchmaschinenseite S unterteilt, wie in 1 durch
die gestrichelte vertikale Linie L angegeben ist. Die Anwendungsseite
A könnte
beispielsweise eine in ABAP (Advanced Business Application Programming)
implementierte SAP-Anwendungsseite sein, die nachstehend als ABAP-Seite bezeichnet
wird.
-
Beim
Betriebsgebrauch des erfindungsgemäßen Systems wird durch die
Anwendung 12, beispielsweise durch einen Hintergrundauftrag
der Anwendung, der so genannte Anwendungsextraktoren aufruft, eine
so genannte Anfangs ladung (wobei es sich um eine Datenuntermenge
der in der Datenbank 16 enthaltenen Datenmenge handelt)
extrahiert. Diese Extraktoren können
als Funktionsmodule, -berichte oder -methoden implementiert werden.
Die Anfangsladung wird zur Suchmaschine 14 übertragen und
in einem Hauptspeicher 24 von dieser gespeichert. Der genaue
Prozess der Anfangsladung wird nicht in weiteren Einzelheiten erklärt, weil
er Fachleuten bekannt ist.
-
Die
Anwendung 12 und die schnelle Suchmaschine 14 können über eine
beliebige Fernkommunikationsschnittstelle kommunizieren, welche
die Funktionalität
des Aufrufens von Funktionen in anderen (fernen) Systemen bereitstellt.
Ein Beispiel eines solchen Fernkommunikationssystems ist die so
genannte Fernfunktionsaufruf-(RFC)-SAP-Schnittstelle, die in 1 als
Pfeil 26 dargestellt ist. Die Erfindung wird nachstehend
beispielhaft weiter anhand einer RFC-Schnittstelle als ein Fernkommunikationssystem
erklärt.
-
Jeder
Funktionsmodulaufruf in der Dienst-API 20 wird in mindestens
einen RFC-Aufruf für
die Suchmaschine umgewandelt. Die in 1 dargestellte
RFC-Schnittstelle ist der Austrittspunkt für die RFC-Aufrufe. Die RFC-Schnittstelle besteht aus
leeren Funktionsmodulen, die dazu dienen, den RFC-Aufruf zu einem
bestimmten vorgegebenen Ziel zu übertragen.
In dem System 10 gemäß der Erfindung
wird die schnelle Suchmaschine als ein registrierter RFC-Server betrieben.
-
Jegliche Änderungen
von Daten, die von der Anwendung vorgenommen werden, erreichen die Suchmaschine
durch einen Aktualisierungsmechanismus gemäß der Erfindung. Das zentrale
Element dieses Mechanismus ist eine in 1 dargestellte Protokollierungstabelle 28,
die sich zwischen der Dienst-API 20 und der RFC-Schnittstelle 26 befindet.
-
Die
Protokollierungstabelle 28 gemäß der Erfindung ist eine transparente
Tabelle in der Anwendungsdatenbank 16. Ein Aktualisierungsleserprozess
dient dazu, einen in der Protokollierungstabelle 28 enthaltenen
Datensatz von Änderungen über die RFC-Schnittstelle 26 zu
lesen. Der Aktualisierungsleserprozess könnte periodisch, beispielsweise
alle 30 Sekunden oder in einem anderen geeigneten Zeitintervall,
ausgeführt
werden. Gemäß einer
Ausführungsform
der Erfindung ist das Zeitintervall vorgebbar.
-
Der
Aktualisierungsleserprozess wird durch einen Aktualisierungsleser 30 ausgeführt, der
sich gemäß der Ausführungsform
der Erfindung auf der Suchmaschinenseite S befindet, wie in 1 dargestellt
ist. Es sei bemerkt, dass der Aktualisierungsleser 30 auch
in einer beliebigen anderen geeigneten Art implementiert werden
könnte,
beispielsweise in der API 20 auf der Anwendungsseite A.
Im letztgenannten Fall könnte
der Aktualisierungsleser beispielsweise ein periodisch ausgeführter Hintergrundauftrag
in einer ABAP-Umgebung sein, der die Suchmaschine mit Aktualisierungsdaten
versorgt ("Push"-Prozess), während im
erstgenannten Fall die Suchmaschine die Aktualisierungsdaten, die
sie benötigt,
aktiv abruft ("Pull"-Prozess).
-
Die
Protokollierungstabelle 28 dient demgemäß dazu, einen Datensatz von Änderungen
zu halten, die an der Anfangsladungsdatenmenge vorgenommen wurden,
seit diese Daten im Hauptspeicher 24 der Suchmaschine gespeichert
wurden.
-
2 zeigt
in weiteren Einzelheiten die Protokollierungstabelle 28 gemäß der Erfindung. 2 zeigt
nur die Elemente, die zum Erklären
des Aktualisierungsmechanismus benötigt werden. Insbesondere zeigt 2 auf
der linken Seite die Anwendung 12 mit der API 20,
die als ein lang gestrecktes vertikales Rechteck, das Funktionsmodule 21 enthält, dargestellt
ist. Die Funktionsmodule 21 sind als Kreise dargestellt,
was im Gegensatz zur Darstellung aus 1 steht,
wo die Funktionsmodule 21 als gestrichelte Linien dargestellt
sind. Es ist natürlich
zu verstehen, dass diese lediglich schematische Darstellungen der
Erfindung sind und dass Fachleuten die Funktionalität der identifizierten
Elemente, unabhängig
von ihrer jeweiligen zeichnerischen Erscheinung bewusst ist.
-
Ferner
zeigt 2 eine detailliertere Protokollierungstabelle 28,
die nachstehend erklärt
wird. Auf der rechten Seite der Protokollierungstabelle 28 in
der Darstellung aus 2 befindet sich die RFC-Schnittstelle 26,
die auch als ein lang gestrecktes vertikales Rechteck dargestellt
ist, das Funktionsmodule 27 enthält. Jenseits der vertikalen
gestrichelten Linie L, die die Grenze zwischen der Anwendungsseite
A und der Suchmaschinenseite S darstellt, befindet sich der Aktualisierungsleser 30,
der Teil der Suchmaschine (nicht dargestellt) ist.
-
Die
aktualisierten Datensätze
vieler verschiedener Suchmaschinen-Tabellen werden alle in einer
Protokollierungstabelle gespeichert. Es sei bemerkt, dass die in 2 dargestellte
Protokollierungstabelle 28 keine Warteschlange simuliert,
weil eine Warteschlange hier nicht benötigt wird. In der Protokollierungstabelle 28 wird
jeder Daten satz durch einen so genannten Protokollierungstabellen-Schlüssel 32 identifiziert,
der aus den Attributen Suchmaschinen-Tabellenname 34 und
Schlüssel 36 besteht.
-
Um
eine Änderung
vorzunehmen, ruft die Anwendung 12 ein bestimmtes Funktionsmodul 21 oder
eine bestimmte Methode in der Dienst-API 20 auf. Dieses
Funktionsmodul 21 empfängt
den vollständigen
Datensatz nach der Änderung.
Bevor der Datensatz in der Protokollierungstabelle 28 gespeichert
wird, wird er in seinen Schlüsselteil
und einen Datenteil zerlegt. Diese Teile werden getrennt in der Protokollierungstabelle 28 gespeichert.
Alle Schlüsselfelder
des Datensatzes werden unter Verwendung fester Längen oder veränderlicher
Längen
unter Verwendung eines Trennzeichens im Protokollierungstabellen-Schlüsselfeld
Schlüssel
verkettet. Das Feld Schlüssel 36 muss
groß genug
sein (beispielsweise CHAR 250), um den größten Schlüssel zu speichern, der in einer
der in der schnellen Suchmaschine 14 gespeicherten Tabellen
auftritt. Alle Felder des Datenteils eines Datensatzes werden unter
Verwendung fester Längen
oder veränderlicher
Längen
unter Verwendung eines Trennzeichens zu einer einzigen Zeichenkette
verkettet und in einer Spalte mit dem Titel Daten 38 gespeichert.
Diese Spalte Daten 38 muss breit genug sein, um den größten Datenteil zu
speichern, der in einer der in der schnellen Suchmaschine 14 gespeicherten
Tabellen auftritt.
-
3 zeigt,
wie die Anwendung 12 drei aktualisierte Datensätze in die
Protokollierungstabelle 28 gemäß der Erfindung schreibt, indem
sie ein geeignetes Funktionsmodul 21 in der Dienst-API 20 aufruft.
Das Schreiben der Datensätze
in die Protokollierungstabelle 28 ist eine Datenbankoperation.
Daher muss das Funktionsmodul 21 der Dienst-API 20 die Tabelle
für diesen
Schreibzugriff verriegeln (oder einreihen). Weil die Protokollierungstabelle 28 ein
gemeinsam genutztes Betriebsmittel ist, das zum Speichern der aktualisierten
Datensätze
für alle
schnellen Suchmaschinen-Tabellen
verwendet wird, wird ein Verriegeln auf Zeilenebene an Stelle eines
Verriegelns der gesamten Protokollierungstabelle verwendet, wodurch
die Wahrscheinlichkeit verringert wird, dass Serialisierungseffekte
an den Protokollierungstabellen auftreten.
-
Nachdem
die Daten in die Protokollierungstabelle 28 geschrieben
wurden, hebt das Funktionsmodul 21 in der Dienst-API 20 die
Verriegelung (die Einreihung) auf und kehrt zur Anwendung 12 zurück. Die
in der Ausführungsform
aus 3 dargestellten Datensätze beziehen sich auf zwei
verschiedene schnelle Suchmaschinen-Tabellen, nämlich Tab1 und Tab2. Sie weisen
die verketteten Schlüssel
A, B, Q auf. Ein Wert von 0 in der Fehlercodespalte 40 (oder ein
anderer geeigneter Standardwert) gibt an, dass keine Fehler aufgetreten
sind. Die Fehlercodespalte 40 wird nachstehend in weiteren
Einzelheiten erklärt.
-
Wie
in 4 dargestellt ist, ruft der periodisch geplante
Aktualisierungsleser 30 ein Funktionsmodul 27 in
der RFC-Schnittstelle 26 der Suchmaschine auf der Anwendungsseite
A auf. Dieses ist eines der Funktionsmodule 27 in der RFC-Schnittstelle 26,
das nicht leer ist, weil es den Code für die nach dem Aufruf des Aktualisierungslesers
auszuführenden
Aktionen enthält.
Das Funktionsmodul 27 verriegelt die Protokollierungstabelle 28,
um zu verhindern, dass die Anwendung 12 aktualisierte Datensätze in die
Tabelle schreibt. Als nächstes
liest das Funktionsmodul 27 alle Datensätze, für die das GESENDET- Hinweiszeichen 42 nicht
gesetzt ist, unter Verwendung einer Auswahlanweisung an der Anwendungsdatenbank 16.
-
5 zeigt,
dass das Funktionsmodul 27 in der RFC-Schnittstelle 26, das durch
den Aktualisierungsleserprozess aufgerufen wurde, nicht nur die aktualisierten
Datensätze
aus der Protokollierungstabelle 28 liest, sondern auch
die GESENDET-Hinweiszeichen 42 für die Datensätze, die
gelesen werden, setzt. Die Daten werden als Antwort auf den Aufruf
beispielsweise in Form einer internen ABAP-Tabelle zum Aktualisierungsleser 30 zurückgegeben. Das
Lesen der Daten aus der Protokollierungstabelle 28 und
das Setzen der GESENDET-Hinweiszeichen 42 sind Datenbankzugriffe.
Nachdem die Daten aus der Datenbank 12 gelesen wurden,
jedoch bevor sie zur schnellen Suchmaschine 14 gesendet
werden, wird die Tabellenverriegelung aufgehoben.
-
Mit
Bezug auf 6 sei bemerkt, dass die Anwendung 12 ein
Dienst-API-Funktionsmodul 21 aufruft, um die Protokollierungstabelle 28 zu
verriegeln und neue Datensätze
in die Tabelle zu schreiben. Die zuvor gesendeten Datensätze verbleiben
in der Protokollierungstabelle 28, weil die schnelle Suchmaschine 14 sie
noch nicht angewiesen hat. Nach dem Schreibvorgang entriegelt das Dienst-API-Funktionsmodul 21 die
Protokollierungstabelle 28.
-
Entsprechend 7 stellt
der Aktualisierungsleser 30, beim nächsten Mal, zu dem er aktiviert ist,
eine Liste von Fehlercodes 40 für alle zuvor gesendeten Datensätze bereit,
die nicht erfolgreich in der schnellen Suchmaschine 14 gespeichert
wurden. Genauer gesagt, bildet der interne Suchmaschinen-Aktualisierungsmechanismus
zuerst eine beständige
Dateikopie der aus der Protokollierungstabelle 28 gelesenen
aktualisierten Datensätze.
Falls diese Operation fehlschlägt,
ist das gesamte Bündel der
zu speichernden Datensätze
fehlerhaft, und andernfalls sind alle Datensätze fehlerfrei. Der interne Suchmaschinen-Aktualisierungsmechanismus
arbeitet in dem Sinne nach dem "Alles-oder-nichts-Prinzip", dass, falls einige
Datensätze
in einer Menge von Datensätzen
fehlerhaft sind, keine der anderen in der Menge erfolgreich gespeichert
werden können.
In dem in 7 dargestellten Fall werden
keine Fehler mitgeteilt, und die durch das Funktionsmodul 27 bereitgestellte
Fehlerliste ist leer. Dies bedeutet, dass alle im letzten Aufruf
des Aktualisierungslesers gesendeten Datensätze erfolgreich in der schnellen Suchmaschine 14 gespeichert
worden sind.
-
Das
durch den Aktualisierungsleser 30 aufgerufene Funktionsmodul 27 in
der RFC-Schnittstelle 26 verriegelt die Protokollierungstabelle 28 gegen Änderungen
durch die Anwendung 12. Das Funktionsmodul 27 löscht alle
Datensätze
mit GESENDET-Hinweiszeichen aus der Protokollierungstabelle 28,
weil kein Fehler mitgeteilt wurde. Das Bereitstellen der Fehlerliste
und das Löschen
der Datensätze mit
GESENDET-Hinweiszeichen sind eine Suchmaschinenverpflichtung.
-
In 8 werden
die letzten Datensätze,
die noch keine GESENDET-Hinweiszeichen haben, zum Aktualisierungsleser 30 weitergeleitet,
und GESENDET-Hinweiszeichen werden für sie in der Protokollierungstabelle 28 festgelegt.
Die Verriegelung der Protokollierungstabelle 28 wird dann
aufgehoben.
-
Mit
Bezug auf 9 wird die Anwendung nun mit
den folgenden Schritten fortgesetzt:
- • Aktualisieren
des Datensatzes Tab2_U durch Überschreiben
des existierenden Datensatzes mit neuen Daten (nicht durch Schreiben
eines neuen Datensatzes),
- • Schreiben
der neuen Delta-Daten Tab4_E, Tab3_M, Tab1_D in die Protokollierungstabelle 28,
- • Löschen der
Datensätze
Tab3_J und Tab1_D aus der schnellen Suchmaschine 14 durch
Setzen des LÖSCHEN-Hinweiszeichens in
der Spalte Löschen-Hinweiszeichen 44 für diese
beiden Datensätze
und Löschen
des GESENDET-Hinweiszeichens,
falls es gesetzt war.
-
Für Datensätze, die
in der schnellen Suchmaschine 14 zu löschen sind, sind keine Daten
erforderlich. Falls irgendein Datensatz in der Protokollierungstabelle
kein GESENDET-Hinweiszeichen
hat oder sein GESENDET-Hinweiszeichen verliert, wird er erneut gesendet.
In dem in 9 dargestellten Fall verlieren
Tab2_U (weil aktualisiert) und Tab3_J (weil gelöscht) ihr GESENDET-Hinweiszeichen.
-
Wie
in 10 dargestellt ist, geschieht der nächste geplante
Aufruf des Aktualisierungslesers 30. Der Leser 30 teilt
einen Fehler für
die zuvor gesendeten Datensätze
(siehe 8) mit. Weil das Verhalten des internen Aktualisierungsmechanismus der
Suchmaschine 14 so ist, dass entweder alle oder keine Datensätze der
Menge von Datensätzen
gespeichert werden, braucht der Leser 30 keine Liste von
Datensätzen
bereitzustellen, die einen Fehler haben. Es ist demgemäß offensichtlich,
dass in der hier beschriebenen und in 10 dargestellten
Situation in der schnellen Suchmaschine 14 keine der zuvor
gesendeten Datensätze
gespeichert sind. Daher ist es ausreichend, dass der Aktualisierungsleser
einen einzigen Fehlercode für
die gesamte Menge von Datensätzen
zurückgibt.
-
Wie
in 10 dargestellt ist, wird der Fehlercode 1234 für die zuvor
gesendeten Datensätze Tab1_K,
Tab2_U, Tab3_J mitgeteilt. In der Zeit, seit diese Datensätze gesendet
wurden, hat die Anwendung 12 jedoch die Datensätze Tab2_U
und Tab3_J in der Protokollierungstabelle 28 modifiziert.
Tab2_U wurde durch eine Aktualisierung überschrieben, und Tab3_J ist
in der schnellen Suchmaschine 14 zu löschen. Der einzige Datensatz,
der sich noch in demselben Zustand befindet, in dem er gesendet
wurde, ist der Datensatz Tab1_K. Daher wird der Fehlercode 1234
nur für
diesen Datensatz in das Feld Fehlercode geschrieben.
-
Abhängig von
dem Grund für
den Fehler (dem Fehlercode) können
die folgenden Aktionen ausgeführt
werden:
- • Die
Anwendung 12 wird über
den Fehler informiert, und es wird erwartet, dass sie eine Aktion vornimmt.
- • Die
Dienst-API 20 löscht
das GESENDET-Hinweiszeichen, um den Datensatz wieder zur schnellen
Suchmaschine 14 zu senden (beispielsweise eine definierte
Anzahl von Malen), ohne die Anwendung 12 zu informieren.
- • Der
fehlerhafte Datensatz bleibt in der Protokollierungstabelle 28,
und ein Administrator nimmt unter Verwendung eines Überwachungswerkzeugs
eine manuelle Aktion vor (in der Art eines manuellen Löschens oder
erneuten Sendens von ihm).
-
Die
schnelle Suchmaschine 14 nimmt an, dass ein Datensatz mit
einem Fehlercode > 0
erneut zu senden ist. Dies wird erreicht, indem einfach das GESENDET-Hinweiszeichen
gelöscht
wird. In 10 hat kein Datensatz in der
Protokollierungstabelle 28 ein GESENDET-Hinweiszeichen,
so dass keine Datensätze
aus der Tabelle entfernt zu werden brauchen (siehe Suchmaschinenverpflichtung,
wie vorstehend erklärt
wurde).
-
Mit
Bezug auf 11 sei bemerkt, dass alle Datensätze, die
gegenwärtig
in der Protokollierungstabelle 28 gespeichert sind, zur
schnellen Suchmaschine 14 gesendet werden. Es gibt jedoch
verschiedene Gründe,
aus denen ein Datensatz gesendet wird. Einige Datensätze sind
neu und werden nun zum ersten Mal gesendet. Ein Datensatz, nämlich Tab1_K,
hat einen Fehlercode > 0
und muss erneut gesendet werden. Das GESENDET-Hinweiszeichen dieses
Datensatzes wurde entfernt, so dass er sich wie ein neu hinzugefügter Datensatz
verhält
und zur schnellen Suchmaschine 14 gesendet wird. Statt
aus der Protokollierungstabelle 28 gelöscht zu werden, werden die
bereits angewiesenen Datensätze Tab2_U
und Tab3_J erneut zur schnellen Suchmaschine 14 gesendet,
weil das GESENDET-Hinweiszeichen nicht mehr gesetzt ist (die Anwendung
hat die Datensätze
geändert).
Datensätze,
bei denen das LÖSCHEN-Hinweiszeichen
gesetzt ist, sind in der schnellen Suchmaschine 14 zu löschen (es
werden keine Daten benötigt).
Falls die Änderungen
erfolgreich angewiesen wurden und die Anwendung 12 an ihnen
keine weiteren Änderungen
vornimmt, werden all diese Datensätze während des nächsten Aufrufs des Aktualisierungslesers
aus der Protokollierungstabelle 28 gelöscht.
-
Ein
Kommunikationsfehler infolge eines Verbindungsabbruchs kann zu den
folgenden Zeitpunkten auftreten: während einer Netzwerkübertragung, nachdem
der Aufruf vom Aktualisierungsleser 30 gesendet wurde,
jedoch bevor er beispielsweise an der RFC-Schnittstelle 26 auf
der Anwendungsseite A ankommt, nachdem der Aufruf von der RFC-Schnittstelle 26 gesendet
wurde, jedoch bevor er zum Aktualisierungsleser 30 zurückkehrt,
und während
der Verarbeitung des Aufrufs des Aktualisierungslesers auf der Anwendungsseite
A, beispielsweise wenn auf die Datenbank 16 zugegriffen
wird. In jedem dieser Fälle bekommt
der Aktualisierungsleser 30 einen Systemfehler als Rückgabecode
für den
Aufruf.
-
Die
Fehlersituation wird folgendermaßen behandelt. Beim ersten
Mal, wenn der Aktualisierungsleser 30 nach einem Verbindungsabbruch
aufgerufen wird, setzt er ein Hinweiszeichen "Wiederaufnahme_nach_Verbindungsabbruch". Falls dieses Hinweiszeichen
gesetzt ist, werden auf der Anwendungsseite A alle Datensätze, die
in der Protokollierungstabelle 28 gesammelt wurden, unabhängig vom
Status ihrer GESENDET-Hinweiszeichen, gesendet. Einige der Datensätze in der
Protokollierungstabelle 28 können aktualisiert worden sein (sogar
mehrere Male) und ihr GESENDET-Hinweiszeichen verloren haben. Andere
Datensätze
können nicht
aktualisiert worden sein, jedoch bereits zur schnellen Suchmaschine 14 gesendet
worden sein. Falls diese Datensätze
ein zweites Mal gesendet werden, wird keine Inkonsistenz hervorgerufen:
Dieselben Daten werden einfach zwei Mal gespeichert. Je länger die
Verbindung unterbrochen ist, desto wahrscheinlicher ist es, dass
eine große
Anzahl von Datensätzen
ihr GESENDET-Hinweiszeichen infolge anschließender Aktualisierungen verloren
hat.
-
Nach
einem Verbindungsabbruch kann die Anzahl der aktualisierten Datensätze in der
Protokollierungstabelle 28 zu groß sein, um sie in einem Ruf zu
senden. Vorteilhafterweise werden die Daten in der Protokollierungstabelle 28 gepackt,
falls dies geschieht. Ein Flussdiagramm für einen möglichen Packungsalgorithmus
ist in 12 dargestellt. Alle Datensätze mit
einem nicht geprüften
GESENDET-Hinweiszeichen müssen
bei einem Aufruf des Aktualisierungslesers gesendet werden (Schritt
S1 in dem Flussdiagramm aus 12). Die
Anzahl der zu sendenden Datensätze
kann an der Datenbank unter Verwendung einer Wählzählwert-(*)-Anweisung (Schritte
S2 bis S4) berechnet werden. Falls die Anzahl der zu sendenden Datensätze größer als
die zulässige
Maximalzahl (Grenze) von Datensätzen
je Aufruf (beispielsweise 1000) ist, wird ein Hinweiszeichen "letztes_Paket" auf ein Leerzeichen
gesetzt (Schritte S5 und S7). Der Aktualisierungsleser kehrt mit
einer Anzahl von Datensätzen
(beispielsweise 1000) und dem auf ein Leerzeichen gesetzten Hinweiszeichen "letztes_Paket" zur schnellen Suchmaschine
zurück
(Schritt S8). Weil das Hinweiszeichen auf das Leerzeichen gesetzt
ist, führt
der Aktualisierungsleser 30 sofort einen neuen Aufruf aus,
um das nächste
Paket von Datensätzen
abzurufen (Schritte S9 und S1). Falls der Aktualisierungsleser 30 mitteilt, dass
sich kein Fehler in der Fehlerliste befindet, werden während des
nächsten
Aufrufs die zuvor gesendeten Datensätze aus der Protokollierungstabelle
gelöscht.
Dies wird wiederholt, bis das Anwendungsfunktionsmodul das letzte
Paket gesendet hat und das Hinweiszeichen "letztes_Paket" auf X gesetzt hat (Schritt S6). Normalerweise
ist nur ein Aufruf je Zyklus des Aktualisierungslesers erforderlich.
Dann wird das Hinweiszeichen "letztes_Paket" sofort auf X gesetzt.
Gemäß der hier
beschriebenen Ausführungsform
der Erfindung werden die Schritte S1, S9 und S10 auf der Suchmaschinenseite
S durch den Aktualisierungsleser 30 ausgeführt und
die Schritte S2 bis S8 auf der Anwendungsseite A durch die RFC-Schnittstelle 26 ausgeführt.
-
Unter
weiterem Bezug auf 12 wird angenommen, dass sich
der Aktualisierungsleser 30 auf der Suchmaschinenseite
S befindet. Wie jedoch bereits vorstehend erklärt wurde und nachstehend in weiteren
Einzelheiten erörtert
wird, kann sich der Aktualisierungsleser 30 beispielsweise
auch auf der Anwendungs- oder ABAP-Seite A befinden. Auch in diesem
Fall kann die Packungslösung
angewendet werden.
-
13 zeigt,
wie die Transaktionskonsistenz gewährleistet wird, falls die Anwendung
synchrone Aktualisierungen an der Datenbank ausführt. Das Prinzip besteht darin,
den Einreihungs-/Ausreihungsmechanismus von SAP zu verwenden, weil
dieser Mechanismus gewährleistet,
dass nur eine Transaktion zu einer Zeit Daten in einer Anwendungstabelle und
der Protokollierungstabelle ändert.
Um dies zu erreichen, muss die Anwendung 12 den Einreihungs-/Ausreihungsmechanismus
richtig verwenden. Ferner muss die Anwendung 12 die Dienst-API 20 zwischen
der Einreihung und der ARBEITSANWEISUNG aufrufen, wie in 13 dargestellt
ist. Die ARBEITSANWEISUNG einer Anwendung gewährleistet das "Alles-oder-nichts"-verhalten. Falls
die ARBEITSANWEISUNG fehlschlägt,
werden entweder alle Änderungen
in den Anwendungstabellen und den entsprechenden Aktualisierungsdatensätzen in der
Protokollierungstabelle 28 in die Datenbank 16 geschrieben,
oder es werden keine der Änderungen in
die Datenbank 16 geschrieben (beispielsweise wenn eine
Aktualisierung abgebrochen wird). Aus diesem Grund benötigt die
schnelle Suchmaschine 14 keinen Wiederholungsmechanismus.
-
Datensätze in Tabellen
stellen eine technische Ansicht der Daten bereit, wodurch die Strukturen
betont werden, in denen sie gespeichert sind. Eine Anwendung behandelt
Daten vielmehr in Einheiten von Geschäftsobjekten, wie Kundenaufträge, Rechnungen,
Kaufaufträge,
Geschäftspartner,
Produkt usw. In einer Datenbank wird jedes Geschäftsobjekt infolge komplexer
Datenmodelle in Form vieler Datensätze in vielen verschiedenen
Tabellen gespeichert. Falls ein Geschäftsobjekt aktualisiert wird,
werden viele Datensätze
geändert.
Falls die Änderungen an
einem Geschäftsobjekt
durch Aufrufen eines geeigneten Funktionsmoduls einer Dienst-API
zur schnellen Suchmaschine gesendet werden, werden viele Datensätze, die
sich auf eine oder mehrere Suchmaschinen-Tabellen beziehen, in einer
so genannten logischen Arbeitseinheit (LUW) in die Protokollierungstabelle
geschrieben. Die Änderungen
an dem Geschäftsobjekt
sind nur konsistent, wenn entweder alle oder keine der relevanten
Datensätze
in die Protokollierungstabelle geschrieben werden. Falls nur ein
Teil der relevanten Datensätze
in die Protokollierungstabelle geschrieben wird, führt dies zu
einem inkonsistenten Zustand des Geschäftsobjekts innerhalb der schnellen
Suchmaschine, der beispielsweise darin besteht, dass nur zwei Drittel
eines Produkts aktualisiert werden. Eine logische Arbeitseinheit
oder LUW kann demgemäß als eine
logische Klammer um eine gegebene Anzahl von Datenbank- und Computersystem-Transaktionen,
die für
eine Aktualisierung benötigt
werden und die in ihrer Gesamtheit gespeichert/geschrieben werden,
um Dateninkonsistenzen zu vermeiden, angesehen werden.
-
Wie
bereits zuvor erklärt
wurde, wird das Problem gelöst,
indem der SAP-Einreihungsmechanismus verwendet wird, der das benötigte "Alles-oder-nichts"-Verhalten gewährleistet.
Daher enthält
die Protokollierungstabelle 28 immer ein konsistentes Bild
der Änderungen
eines Geschäftsobjekts in
Form mehrerer aktualisierter Datensätze, welche eine LUW darstellen.
Diese Einheit von Datensätzen ist
unteilbar, um zu gewährleisten,
dass das Bild der Änderungen
an dem Geschäftsobjekt
konsistent bleibt.
-
Es
gibt jedoch kein Feld in der Protokollierungstabelle 28,
das Informationen über
die Assoziation eines Datensatzes mit einer LUW, in der Art eines
Zählwerts
oder eines Zeitstempels, speichert. Der Aktualisierungsleser 30 hat
keine Informationen über
LUWs. Er liest Daten in Einheiten von Datensätzen und nicht in Einheiten
von LUWs.
-
Hierdurch
wird die Konsistenz der Daten nicht zerstört. Trotz der fehlenden LUW-Informationen
in der Protokollierungstabelle 28 kann der Aktualisierungsleser 30 aus
den folgenden Gründen
der schnellen Suchmaschine konsistente Daten bereitstellen:
Vollständige LUWs
in der Protokollierungstabelle: Es werden entweder alle Datensätze einer
LUW in der Protokollierungstabelle gespeichert oder keiner. Dies gewährleistet,
dass LUWs vollständig
sind (siehe vorstehende Erörterung).
-
Lesekonsistenz
gewährleistet:
Der SAP-Einreihungsmechanismus gewährleistet, dass entweder die
Anwendung Daten in die Protokollierungstabelle 28 schreibt
oder der Aktualisierungsleser 30 die Daten liest, jedoch
nicht beides gleichzeitig. Dies gewährleistet die Lesekonsistenz
für den
Aktualisierungsleser 30.
-
Lesen
von Daten in einem Schritt: Wenngleich der Aktualisierungsleser 30 nicht
zwischen den verschiedenen LUWs unterscheiden kann, werden jedes
Mal dann, wenn der Aktualisierungsleser 30 geplant wird,
alle Daten, deren GESENDET-Hinweiszeichen das Leerzeichen ist, gelesen.
Falls daher vollständige
LUWs in die Protokollierungstabelle 28 geschrieben werden,
werden vollständige
LUWs der schnellen Suchmaschine 14 bereitgestellt. Die Gruppierung
der Datensätze
und ihrer LUWs wird nicht zerstört.
-
Falls
die Daten in Portionen gelesen werden, unterbricht der Aktualisierungsleser 30 nicht
bevor alle Portionen gelesen wurden. Daher werden auch in diesem
Fall vollständige
LUWs der schnellen Suchmaschine 14 bereitgestellt. Weil
die Daten unter dem Schutz verschiedener Einreihungen gelesen werden,
ist es möglich,
dass zwischen zwei Einreihungen eine Anwendung die Daten in der
Protokollierungstabelle 28 ändern kann. Die GESENDET-Hinweiszeichen
der neu eingefügten
oder aktualisierten Datensätze
in der Protokollierungstabelle 28 sind jedoch auf das Leerzeichen
gesetzt, um anzugeben, dass sie während des aktuellen Planungszyklus
des Aktualisierungslesers 30 in einem der folgenden Pakete
der schnellen Suchmaschine 14 bereitgestellt werden.
-
Die
Konsistenz ist nur für
alle Pakete gemeinsam gewährleistet.
Falls ein Paket Fehler aufweist und zurückgewiesen wird, können die
anderen erfolgreich in der schnellen Suchmaschine 14 gespeicherten
Pakete unvollständige
und daher inkonsistente LUWs enthalten. Die schnelle Suchmaschine 14 kann
die Pakete aktualisierter Datensätze
jedoch nicht in ihre internen Datenstrukturen integrieren, bevor
alle Pakete erfolgreich empfangen worden sind. Falls Fehler auftreten,
werden ein oder mehrere Pakete zurückgegeben. Diese Datensätze verlieren dann
ihr GESENDET-Hinweiszeichen in der Protokollierungstabelle, so dass
sie während
des nächsten Zyklus
des Aktualisierungslesers wieder gesendet werden. Sobald alle Pakete
erfolgreich in der schnellen Suchmaschine 14 gespeichert
wurden, hat die schnelle Suchmaschine 14 einen konsistenten
und vollständigen
Satz von LUWs.
-
Entweder
werden alle aus der Protokollierungstabelle 28 gelesenen
Datensätze
erfolgreich in der schnellen Suchmaschine 14 gespeichert,
oder sie werden alle zurückgewiesen.
Demgemäß setzt sich
das "Alles-oder-nichts"-Verhalten auf der Ebene des Aktualisierungslesers 30 fort.
Im Fall eines Pakets je Zyklus des Aktualisierungslesers werden
entweder alle LUWs erfolgreich in der schnellen Suchmaschine 14 gespeichert,
oder es wird keine der LUWs gespeichert, es werden jedoch nie Teile
der LUWs gespeichert. Falls ein Packung verwendet wird, gewährleistet
die schnelle Suchmaschine 14, dass alle Pakete eines Zyklus
des Aktualisierungslesers erfolgreich gespeichert werden, bevor
sie in die Datenstrukturen des Hauptspeichers integriert werden.
Erst dann macht die schnelle Suchmaschine 14 die Aktualisierungen
für die
Anwendung 12 sichtbar.
-
Wie
vorstehend bereits skizziert wurde, kann der Aktualisierungsleserprozess
entweder auf der Suchmaschinenseite S oder auf der Anwendungsseite
A angeordnet werden.
-
Im
letztgenannten Fall ist der Aktualisierungsleser 30 ein
periodischer Hintergrundauftrag, der die Daten durch Aufrufen eines
geeigneten Funktionsmoduls in der RFC-Schnittstelle 26 in die schnelle
Suchmaschine 14 schiebt. Die folgende Liste von Vorteilen
und Nachteilen kann bei der Entscheidung, wo sich der Aktualisierungsleser 30 befinden
sollte, hilfreich sein:
Aktualisierungsleser auf der Seite
S der schnellen Suchmaschine: Vorteile: Die schnelle Suchmaschine steuert
den Aktualisierungsleserprozess und legt seinen Zeitablauf fest;
einfache Kommunikation der schnellen Suchmaschine mit dem Aktualisierungsleserprozess.
Nachteile: Die schnelle Suchmaschine holt Aktualisierungen aktiv
von der Anwendungsseite, so dass sie von Mechanismen, wie der Protokollierungstabelle,
die genau wie vorgeschrieben arbeiten müssen, abhängt; der Aktualisierungsleser
muss in anderen Umgebungen, wie Java-Anwendungen, möglicherweise
auf andere Weise arbeiten.
-
Aktualisierungsleser
auf der Anwendungsseite A: Vorteile: Die schnelle Suchmaschine ist
nicht für
das Holen von Aktualisierungen verantwortlich, Aktualisierungen
werden der schnellen Suchmaschine lediglich über eine definierte Schnittstelle
bereitgestellt, und die schnelle Suchmaschine braucht ihren Ursprung
nicht zu berücksichtigen.
Nachteile: Die schnelle Suchmaschine hat keine Kontrolle über den Aktualisierungsleserprozess
und seine Periodizität; die
Kommunikation zwischen dem Aktualisierungsleser und der schnellen
Suchmaschine erfolgt über
die API/das Netzwerk: Der Aktualisierungsleser versucht selbst dann,
wenn keine Verbindung vorhanden ist, periodisch die schnelle Suchmaschine
zu erreichen.
-
Einige
Vorteile des Suchmaschinen-Aktualisierungsmechanismus gemäß der Erfindung
unter Verwendung der Protokollierungstabelle gemäß der Erfindung sind: Die Anwendung
braucht nicht auf die schnelle Suchmaschine zu warten, während sie
eine Aktualisierung liest oder einen Fehler behandelt, weil der
Dienst-API-Aufruf zur Anwendung zurückkehrt, sobald die aktualisierten
Datensätze
in die Protokollierungstabelle geschrieben worden sind. Anders als eine
herkömmliche
Protokollierungsdatei kann die Protokollierungstabelle nicht unbegrenzt
wachsen, weil jeder aktualisierte Datensatz nur in einer Version,
d.h. der letzten, auftritt. Der Mechanismus gewährleistet eine Transaktionskonsistenz.
Die Lösung ist
einfach zu implementieren. Eine einfache Anzeigetransaktion kann
zum Überwachen
der Protokollierungstabelle verwendet werden.