Replikation für ADS Datenbanken

Viele Unternehmen, die sich in einem mandanten-basierten Umfeld bewegen kennen das Problem: Sofern nicht die Datenbank oder ein flexibles Regelwerk in der ERP einen Abgleich der Daten vornehmen kann, bleiben viele Wünsche im Bezug auf die Mandantenfähigkeit auf der Strecke. Oft bleibt nichts anderes übrig, als Daten manuell abzugleichen oder nachts komplette Datenbestände hin und her zu kopieren. Auf lange Sicht eine fehleranfällige und zudem unflexible Art der Datenpflege.

Der Kunde

Unser Kunde ist beliebiges Produktions-Unternehmen mit Filialen,welche zukünftig nur noch die Stammdaten aus der Datenbank der Zentrale verwenden sollen, die dort sauber gepflegt werden. Alle Standorte setzen aktuell CAMplusNT Version 7.7 mit der ADS Datenbank Version 9.1 ein.

Der Wunsch des Kunden besteht darin, verschiedene Stammdaten der installierten ERP an andere Instanzen / Filialen zu verteilen.

Der Abgleich soll folgende Kriterien bzgl. der Datenänderungen erfüllen:

  • Es muss jede Änderung und Neuanlage berücksichtigt werden
  • Änderungen dürfen nur vollständig oder gar nicht durchgereicht werden
  • Eine manuelle Nachbearbeitung soll ausgeschlossen werden
  • Änderungen sollen automatisch, zeitnah und schnell ausgeführt werden
  • Die Lösung muss flexibel und adaptiv sein

Der Kunde besteht darauf, dass zum Echtlauf alle Ziele umgesetzt sind!

Kriterien

Aufgrund der Anforderungen, stellen sich folgende relevante Fragen:

  1. Wie kann erkannt werden, ob Daten in der Datenbank neu eingefügt oder geändert wurden?
  2. Wie kann sichergestellt werden, dass Änderungen nicht nur erkannt, sondern auch vollständig in die Filialen übertragen werden - ohne manuelle Nachbearbeitung?
  3. Welche Möglichkeiten bestehen, alle Änderungen immer automatisch, zeitnah und schnell auszuführen?
  4. Welche Lösung ist flexibel und adaptiv genug für die Anforderungen?

 

Mögliche Einsatzzwecke (jetzt und später)

Nachfolgende sind noch einige Szenarien beschrieben, wie Daten ausgetauscht werden könnten.

  • Neue Daten und Datenänderungen einer Tabelle sollen unidirektional in eine oder mehrere Zieltabellen übertragen werden.
  • Nur neue Daten einer Tabelle sollen unidirektional in eine Zieltabelle übertragen werden.
  • Nur Änderungen in einer Tabelle sollen unidirektional in eine Zieltabelle übertragen werden.
  • Neue Daten und Datenänderungen sollen bidirektional zwischen einer oder mehreren Tabellen übertragen werden.
  • Nur neue Daten sollen bidirektional zwischen einer oder mehreren Tabellen übertragen werden.
  • Nur Datenänderungen sollen bidirektional zwischen einer oder mehreren Tabellen übertragen werden.

Diese Aufstellung ist nicht abschließend und die Szenarien der bidirektionalen Übertragung bedürfen weitreichender Planung. Zunächst wird deshalb nur von einer unidirektionalen Übertragung in eine oder mehrere Datenbanken ausgegangen.

Grundlagen

Dieses Konzeptpapier beschreibt mögliche Ansätze für die Replikation von Daten auf Basis der Datenbank ADVANTAGE DATABASE SERVER von SYBASE (ehemals Extended Systems).

Der ADVANTAGE DATABASE SERVER (im weiteren ADS abgekürzt) unterstützt verschiedenste Betriebszustände und Tabellenmodi und kennt eigene Erweiterungen für die Replikation von Daten zwischen verschiedenen Instanzen.

Voraussetzung für die Nutzung der Replikationsoptionen ist jedoch ein Tabellenmodus, der die Tabellen in ein Dictionary einbindet. Steht dieser Modus nicht zur Verfügung, wird die Replikation nicht direkt unterstützt.

Das hier vorliegende Replikationskonzept ist daher primär für Situationen gedacht, in denen kein Dictionary zur Verfügung steht.

Alle Beispiele basieren auf ADT Tabellen, da dieses Format beste Voraussetzungen für eine einfache Implementierung der Replikation bietet. Sowohl der Typ AUTOINC als auch der Typ ROWVERSION werden hier funktionell unterstützt und sind ideale Mechanismen zur Unterstützung der Replikation.

Unterstützung für Daten im Format VFP ist möglich, wenn alternativ statt ROWVERSION ein TIMESTAMP durch die Anwendung konsequent bei jedem INSERT/UPDATE gepflegt wird, da VFP nur den Typ AUTOINC kennt.

Unterstützung für Daten im Format CDX ist möglich, wenn alternativ statt ROWVERSION ein TIMESTAMP durch die Anwendung konsequent bei jedem INSERT/UPDATE und zudem ein eindeutiger Primärschlüssel gepflegt wird , da CDX weder AUTOINC noch ROWVERSION kennt.

Alle Beispiele und Funktionen basieren auf ADS 9.1, funktionieren größtenteils auch auf älteren Versionen des ADS.

Technische Voraussetzungen (für die mitgelieferte UC Installation)

  • Funktionsfähige ADS Datenbank ab Version 9.1 (zur Unterstützung von Transaktionen)
  • Testdaten im Format ADT (Unterstützung Daten VFP / CDX siehe oben)
  • Tabellen _REPMASTER und _REPSTATUS gemäß Definition in der Ausgangsdatenbank
  • Alle betroffenen Tabellen in Quell- und Zielinstanzen
  • Verbindung der Programme zur Datenbank im REMOTE-Modus
  • Eine Software, die den Datenaustausch zwischen den Instanzen steuern kann (beispielsweise DATANAUT UC)

 

Lösungsansatz

Aufgrund der Kenntnisse über die Möglichkeiten der ADS-Datenbank sowie der adaptiven Technologie von DATANAUT UC, besteht nun die Möglichkeit, in einem Projekt einen technologisch ausgereiften, sicheren und zudem sehr schnellen Datentransfer zwischen den Filialen herzustellen.

Erfüllung der Kriterien:

  1. Erkennung von Änderungen und Einfügungen:
    Die Erkennung aller Änderungen an den Daten einer Datenbanktabelle erfolgt über eine neu anzulegende beispielhaften Tabellenspalte namens _VERSION; diese bekommt den Datentyp ROWID(). Das Einfügen eines Datensatzes kommt einer Änderung gleich und ist entsprechend transparent.

    Jede Änderung in der Datenbank erhöht den in der Tabelle gespeicherten  Rückgabewert für die Funktion ROWID() um 1, und zwar immer dann, wenn ein Datensatz in die Datenbank geschrieben oder verändert wurde. Der Wert wird also immer erst dann inkrementiert, wenn der betreffende Datensatz vollständig auf die Festplatte geschrieben wurde.

    Dieser Mechanismus kann nun verwendet werden, um die von Änderungen betroffenen Daten festzustellen und gleichzeitig alle nicht geänderten Daten auszuschließen. Dies ist der beispielhafte Inhalt der Tabelle:

1

Nehmen wir an, eine Sachbearbeiterin macht eine Adress-Korrektur für den Kunden mit der Nummer 1002. Der Inhalt der Tabelle ist aktuell nun folgender:

2

Deutlich zu erkennen ist, dass die Datenbank nach der Änderung den Wert in der Spalte _VERSION um 1 erhöht hat.

Wenn nun vor dieser Änderung bereits eine Übertragung von Daten in die Filiale stattgefunden hat, ist es über eine SQL-Abfrage einfach möglich, die Datensätze zu filtern, die diesen ROWID()-Wert jetzt überschritten haben:

SELECT * FROM kundena WHERE _version >= 15

3

Durch diesen Mechanismus werden also sicher alle neuen oder geänderten Datensätze gefunden, wenn man einen bestimmten Ausgangswert hat. Hat man diesen nicht, kann 0 verwendet werden, um alle Sätze zu finden.

In nachfolgenden Übertragungs-Szenarien muss also nur dafür gesorgt werden, dass nach der Übertragung von Daten in ein Filial-System der relevante Vergleichswert gespeichert wird, um für spätere Übertragungen diesen Anhaltspunkt zu haben. In allen folgenden SWQL.-Codes wird dazu Bezug auf die Tabelle _REPMASTER genommen, die jeweils einen Steuer-Datensatz für jede zu replizierende Tabelle enthält.

Der Aufbau wie folgt (Ur-Zustand):

4

Der Aufbau nach Inbetriebnahme (siehe Feld VERSION):

5

Nach jedem Durchlauf der Replikationsprozesse, werden also im Feld VERSION für jede Tabelle die Datenstände gemerkt. Somit können einfach und schnell alle neuen und geänderten Datensätze für den nächsten Replikationsdurchgang ermittelt werden.

  1. Sicherstellung der Übertragung aller Änderungen

    Die Sicherstellung, das immer alle geänderten Daten komplett Übertragen werden, ist durch das Transaktionssystem der Datenbank geregelt. Aus diesem Grund darf die Anwendung nur im Modus REMOTE laufen.

  2. Erweiterung der Replikation

    Die Hinzunahme weiterer Tabellen ist einfach. Die Tabelle ist unter _REPMASTER einzutragen und mit der Sortierung zu versehen. Die Sortierung / Gruppierung dient lediglich der Unterscheidung verschiedener Datenkreise, kann jedoch auch verwendet werden, um eine bestimmte Abarbeitungsreihenfolge zu erzwingen.

    Das Feld AKTIV wird auf TRUE gesetzt, s.d. die Datenbank am Prozess teilnimmt. Zusätzlich ist im UC ein Übertragungs-SQL anzulegen. Alle anderen Mechanismen werden generisch gesteuert.

  3. Anpassungen der Datenbankstrukturen bei betroffenen Tabellen

    Sofern nicht vorhanden, sind folgende Felder in der QUELL-Datenbank anzulegen:
    1) _ID Typ AUTOINC
    2) _VERSION Typ ROWVERSION

  4. Sofern nicht vorhanden, sind folgende Felder in den ZIEL-Datenbanken anzulegen
    1) _ID Typ INTEGER
    2) _VERSION Typ INTEGER

    ACHTUNG: AUTOINC darf in den ZIEL-Datenbanken als Typ hier in diesem Beispiel nicht verwendet werden!

    Sofern ein automatisches Update-Programm die Datentypen verändert, sind diese nach dem Update anzupassen. Die Feldnamen sind nur beispielhaft und können frei gewählt werden. Es empfiehlt sich jedoch, die Benennung deutlich von der Benennung der „normalen“ Datenbankfelder abzugrenzen, beispielsweise durch den Unterstrich. Werden andere Feldnamen verwendet, sind zudem die SQL-Scripte und die _REP* Tabellen anzupassen, die die Steuerung der Replikation übernehmen

Neue Tabellen einbinden

  • Abschalten der UC-Prozesse
  • Eintragen der Tabelle in _REPMASTER auf der Quelldatenbank
  • Vergeben einer Ordnungsgruppe
  • Vorgabewert „Version = 0“ sollte gesetzt sein
  • Einfügen des Übertragungsskripts in den UC (mit den Echtnamen)
  • Setzen des Schalters AKTIV (definitiv zuletzt)!
  • Einschalten der UC-Prozesse

Durchführung von Datenbank-Updates

  • Abschalten der UC-Prozesse
  • Durchführung zuerst auf der Quelldatenbank (empfohlen)
  • Durchführung weiterer Update auf den Replikationszielen (auf Quelle kann schon wieder gearbeitet werden)
  • Durchführung der Prozedur REP_INIT
  • Einschalten der UC-Prozesse

Kompletten Bestandsabgleich für alle Tabellen erzwingen (REP_INIT)

  • Abschalten der UC-Prozesse
  • SQL auf _REPMASTER in Quelle: UPDATE _repmaster SET version = 0;
  • Einschalten der UC-Prozesse

Diese Prozedur kann nachts vom UC erzwungen werden, während der normale Replikationsprozess nicht läuft. REP_INIT ist jedoch normalerweise nicht nötig und behindert andere nächtliche Prozesse!