Steuerparameter für die selektive Datenübernahme

Mit diesem Programm können können Steuerparameter hinterlegt werden, um für bestimmte, sehr umfangreiche Dateien bei einem Release-Wechsel oder einer Migration nur eine Teilmenge von Daten zu übernehmen. Dies ist insbesondere für die finale Datenübernahme zum Echtstart sinnvoll, für die in der Regel nur wenig Zeit zur Verfügung steht. Zum Beginn des Projekts müssen die Dateien vollständig übernommen werden. Für weitere Übernahmen reicht es, das fehlende Delta der Daten zu übernehmen.

Der primäre Schlüsselbegriff für einen Eintrag ist der Name der Datei, auf die sich die Einschränkung bezieht. Dies muss eine im Datei-Explorer hinterlegte physische Datei sein, und sie muss als "Anwendungsdatei" gekennzeichnet sein. (Nur diese Dateien werden bei einem Release-Wechsel übernommen.)

Es gibt zwei verschiedene Methoden, um die Einschränkung der Datenübernahme zu steuern.

Selektion über ein Datumsfeld

Die herkömmliche Methode, die auf der Oberfläche als "alternative Methode" gekennzeichnet ist, ermöglicht die Selektion anhand eines Feldnamens und eines Datums. Diese Methode ist sowohl für einen Release-Wechsel als auch für eine Migration aus der oxaion Business Solution möglich.

Beispiel:

Für die Lager-Positionsdatei LPSDAP wird der Feldname 'BGZT' und das Abgrenzungsdatum '01.11.2025' angegeben. Dann wird die where-Bedingung für die zu löschenden und die zu übernehmenden Daten um folgende Klausel ergänzt:

... and PSBGZT >= '2025-11-01'

Hinweis:

Bei dieser Methode ist zu beachten, dass keine Datumsfelder verwendet werden, die sich ändern können, z.B. das Datum der letzten Änderung xxYLAE. Wenn sich ein Datum ändert, dann wird der Datensatz vor der Übernahme nicht gelöscht. (Denn der vorhandene Datensatz hat ja noch ein älteres Datum.) Beim Versuch, den Datensatz einzufügen, kommt es dann zu einem doppelten Schlüssel und zum Abbruch der Übernahme für diese Datei.

Selektion über das Journal bzw. Archiv

Diese Methode ist deutlich flexibler, da sie das Archiv bzw. die Journalempfänger aus dem Vor-Release benutzt. Das initiale Einrichten dieser Methode ist aber gegebenenfalls etwas aufwendiger. (Die Methode steht derzeit auch nur für einen Release-Wechsel innerhalb von Open zur Verfügung, aber nicht für eine Migration aus der oxaion Business Solution.)

Um diese Methode nutzen zu können, ist es zwingend erforderlich, dass die Datei, auf die sich dieser Eintrag bezieht, im Vor-Release journalisiert wird. (Ein Archivieren ist nicht unbedingt notwendig.) Das Verwaltungsprogramm prüft, ob für diese Datei das Kennzeichen im Datei-Explorer im Vor-Release auf 'Journalisieren' oder 'Archivieren' steht. Es sollte zusätzlich geprüft werden, ob tatsächlich ein Journalempfänger vorhanden ist und das Journalisieren tatsächlich stattfindet.

Um diese Methode optimal zu nutzen, sollten zwei Jobs eingeplant werden, die in regelmäßigen Abständen laufen. Dazu müssen die folgenden Registry-Einträge korrekt gepflegt sein (über das Verwaltungsprogramm US00060, in der Gruppe ADMIN/MERGE):

Der erste Job, der eingeplant werden sollte, ist ein Aufruf der Methode fetchRecordsFromJournal. Dieser Job sollte in regelmäßigen Abständen laufen, mindestens wöchentlich, bei sehr großen Datenbeständen auch häufiger, und zwar zu einem Zeitpunkt, zu dem im Vor-Release möglichst wenig passiert. Dieser Job wertet das Archiv und die Journalempfänger für die jeweilige Datei im Vor-Release aus und überträgt die Daten in die Datei RJRSNP. (Diese wird beim ersten Lauf im Vor-Release automatisch angelegt.) Die Auswertung beginnt mit dem in den Steuerparameter angegebenen Abgrenzungsdatum, das nach dem Programmlauf entsprechend hochgesetzt wird (sodass der nächste Lauf zu einem späteren Zeitpunkt aufsetzt).

Für insert-Anweisungen wird nur die jeweilige RRN des Datensatzes gespeichert. Bei der Delta-Übernahme wird dann zusätzlich auf diese RRN selektiert. Für delete-Anweisungen wird eine SQL-DELETE-Anweisung für den jeweiligen Datensatz generiert. Für update-Anweisungen werden beide Einträge erzeugt.

Dieser Job muss unbedingt noch einmal vor der finalen Datenübernahme ausgeführt werden, und zwar zu einem Zeitpunkt, zu dem im Vor-Release bereits nichts mehr läuft. Nur dann ist sichergestellt, dass alle geänderten Daten in der RJRSNP enthalten sind.

Der zweite einzuplanende Job ist ein Aufruf der Methode deleteRecordsWhichAreMarkedAsDeletedInArchive. Dieser Job kann vorab immer mal wieder laufen, insbesondere dann, wenn bereits viele Löschanweisungen in der RJRSNP gespeichert sind. Diese Löschanweisungen werden einzeln ausgeführt, was relativ viel Zeit benötigt. Wenn sie vorab ausgeführt werden, reduziert das den Zeitbedarf für die finale Datenübernahme.

Dieser Job muss nicht mehr unmittelbar vor der finalen Datenübernahme laufen, da dort diese Methode noch einmal explizit aufgerufen wird.