Replication

Dieser Dienst repliziert Daten aus einem RDBMS nach OpenSearch.

Auswirkung auf die System-Performance

Die Replikation hat direkten Einfluss auf die System-Performance. Dabei spielen insbesondere die Anzahl der Threads (Replication → Einstellungen → Replication_Threads) und der Intervall (replicationInterval) ein Rolle. Je mehr Jobs in kurzer Zeit laufen, desto höher ist die CPU Auslastung. Das gilt insbesondere, wenn viele Daten repliziert werden.

Die replicationBlockSize wirkt sich zwar positiv auf die Replikationsdauer aus, hat aber auch direkten Einfluss auf den Speicherbedarf von Apache Karaf.

Vorbereitung zur Datensatzaktualität

Vor der Einrichtung der Replikationen sollten ein paar Voraussetzungen geschaffen werden. Die Replikation benötigt für jede Tabelle (Log wie auch Childlog) eine Spalte mit ausschließlich anwachsenden Timestamps, da dieser Timestamp verwendet wird, um anschließend neuere/aktualisierte Datensätze zu finden. Loggen unterschiedliche Prozesse, Server, … also parallel in die DB und somit eventuell (auch nur um Millisekunden) zeitversetzt, kann es passieren, dass einzelne Datensätze nicht im BPC angezeigt werden, da diese mit einem Timestamp älter als dem neuesten replizierten committet werden.

Es empfiehlt sich daher:

nicht die Serverzeit des loggenden, sondern die des DB-Servers zu loggen, da unterschiedliche Prozess-Server eventuell leicht abweichende Uhrzeiten haben
sicherzustellen, dass wirklich bei jedem insert oder update diese Spalte neu geschrieben wird

Beides kann einfach über eine zusätzliche (versteckte) Spalte mit Default-Value und zugehörigem Trigger erfolgen. Das hat den Vorteil, dass sich für den Loggingprozess überhaupt nichts ändert)

Hinzufügen einer technischen TIMESTAMP Spalte für Replikation

Oracle

Für PM-Log und Childlog (ohne Prefix) unter Oracle sieht das Vorgehen zum Anlegen dann beispielsweise so aus:

--LOG:
--Spalte (mit 6Nachkommastellen Präzission) ergänzen, Defaultvalue für Inserts auf die aktuelle Uhrzeit in UTC setzen (damit ist keine Anpassung im Loggingprozess nötig)
ALTER TABLE LOG ADD (DB_UPDATE_TS TIMESTAMP DEFAULT SYSTIMESTAMP AT TIME ZONE 'UTC' NOT NULL);

--Bestehende Logeinsträge wieder "verteilen", sonst kommt die Replikation nicht gut klar:
--Entweder alle in einem Block (!besser nicht mit Tabellen > 1mio Einträge!):
UPDATE LOG SET DB_UPDATE_TS = TIMESTAMP;
Commit;

  --oder bei großen Datenmengen und Livesystemen, die auch noch was mit den Tabellen machen wollen, als anonymer PL/SQL-Block mit wenig Undo-Tablespacebedarf:
  --hierfür sollte zusätzlich ein Index auf der Timestamp-Spalte liegen um FullTableScans zu vermeiden!
    declare begin
      FOR counter IN 0 .. 3650 LOOP
        --dbms_output.put_line(to_char(to_date('2010-01-01', 'YYYY-MM-DD') + counter, 'YYYY-MM-DD') || ' - ' || to_char(to_date('2010-01-01', 'YYYY-MM-DD') + 1 + counter, 'YYYY-MM-DD'));
        --LOG:
        update log set DB_UPDATE_TS = TIMESTAMP where TIMESTAMP between to_date('2010-01-01', 'YYYY-MM-DD') + counter and to_date('2010-01-01', 'YYYY-MM-DD') + 1 + counter;
        commit;
        --CHILDLOG:
        update childlog set DB_UPDATE_TS = TIMESTAMP where TIMESTAMP between to_date('2010-01-01', 'YYYY-MM-DD') + counter and to_date('2010-01-01', 'YYYY-MM-DD') + 1 + counter;
        commit;
      END LOOP;
    end;

--Einen Trigger anlegen, der die Spalte bei jedem Update neu setzt (damit ist keine Anpassung im Loggingprozess nötig)
CREATE OR REPLACE
TRIGGER LOG_DB_UPDATE_TS
BEFORE UPDATE ON LOG
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
DECLARE
BEGIN
:NEW.DB_UPDATE_TS := SYSTIMESTAMP AT TIME ZONE 'UTC';
END;
/

--Index erstellen:
CREATE INDEX IDX_LOG_DBLU ON LOG(DB_UPDATE_TS) COMPUTE STATISTICS;


--Das ganze Geraffel noch mal für Childlog:
ALTER TABLE CHILDLOG ADD (DB_UPDATE_TS TIMESTAMP DEFAULT SYSTIMESTAMP AT TIME ZONE 'UTC' NOT NULL);

--Siehe ggf. PLSQL-Block oben!
UPDATE CHILDLOG SET DB_UPDATE_TS = TIMESTAMP;
commit;

CREATE OR REPLACE
TRIGGER CHILDLOG_DB_UPDATE_TS
BEFORE UPDATE ON CHILDLOG
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
DECLARE
BEGIN
:NEW.DB_UPDATE_TS := SYSTIMESTAMP AT TIME ZONE 'UTC';
END;
/

CREATE INDEX IDX_CHILDLOG_DBLU ON CHILDLOG(DB_UPDATE_TS) COMPUTE STATISTICS;
--Fertig

MSSQL

TIMESTAMP sollte in UTC gezogen werden, da sonst bei der Winterzeitumstellung ein blinder Fleck zwischen 2 und 3 Uhr entsteht! Der Code berücksichtigt dies noch nicht - evtl. verwenden Sie SYSUTCDATETIME statt SYSDATETIME - prüfen Sie jedoch das Verhalten im BPC.

Der Trigger für Childlog fehlt. Normalerweise wird dieser aber nicht benötigt, da die Einträge immer nur hinzugefügt und nicht aktualisiert werden.

/* Spalten hinzufügen. DATETIME2 für bessere Auflösung als DATETIME. Offensichtlich ist MSSQL nicht millisekundengenau, daher statt current_timestamp die Funktion SYSDATETIME() verwenden, diese ist nanosekundengenau. */
ALTER TABLE [LOG] ADD DB_UPDATE_TS DATETIME2 DEFAULT SYSDATETIME() NOT NULL;
GO

ALTER TABLE [CHILDLOG] ADD DB_UPDATE_TS DATETIME2 DEFAULT SYSDATETIME() NOT NULL;
GO

/* Spalten initial füllen */
BEGIN
    UPDATE [LOG] SET DB_UPDATE_TS = [timestamp];
END
GO

BEGIN
    UPDATE [CHILDLOG] SET DB_UPDATE_TS = [timestamp];
END
GO

/* Trigger */
CREATE TRIGGER LOG_DB_UPDATE_TS
  ON [LOG]
  AFTER UPDATE
  AS
BEGIN
    IF NOT UPDATE(DB_UPDATE_TS)
    BEGIN
        UPDATE t
            SET t.DB_UPDATE_TS = SYSDATETIME()
            FROM [LOG] AS t
            INNER JOIN inserted AS i
            ON t.PROCESSID = i.PROCESSID;
    END
END
GO

/* Indizes */
CREATE INDEX IDX_LOG_DBLU ON LOG (DB_UPDATE_TS);
CREATE INDEX IDX_CHILDLOG_DBLU ON CHILDLOG (DB_UPDATE_TS);

MySQL

und für MySQL ganz einfach:

# Fügt der Tabelle einen von der DB verwalteten ausreichend genauen Timestamp hinzu
ALTER TABLE LOG ADD DB_UPDATE_TS TIMESTAMP(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6)
ALTER TABLE CHILDLOG ADD DB_UPDATE_TS TIMESTAMP(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6)

PostgreSQL

und für PostgreSQL auch über Trigger:

ALTER TABLE log ADD db_update_ts timestamp NOT null DEFAULT (timezone('UTC', now()));
ALTER TABLE childlog ADD db_update_ts timestamp NOT null DEFAULT (timezone('UTC', now()));

CREATE OR REPLACE FUNCTION update_db_update_ts_column()
RETURNS TRIGGER AS $$
BEGIN
    NEW.db_update_ts = timezone('UTC', now());
    RETURN NEW;
END;
$$ language 'plpgsql';

CREATE TRIGGER update_log_db_update_ts BEFORE INSERT OR UPDATE ON log FOR EACH ROW EXECUTE PROCEDURE update_db_update_ts_column();
CREATE TRIGGER update_childlog_db_update_ts BEFORE INSERT OR UPDATE ON childlog FOR EACH ROW EXECUTE PROCEDURE update_db_update_ts_column();

CREATE INDEX idx_log_dblu ON log (db_update_ts);
CREATE INDEX idx_childlog_dblu ON childlog (db_update_ts);

Konfiguration

Datenquellen

Datenquellen sind Verbindungen zu einzelnen Datenbanken. Die einzelnen Replikationsjobs verwenden/referenzieren diese dann. Diese werden unter Backend Connections vom Typ "data_source" eingerichtet und anhand der Komponenten ID referenziert.

Oberfläche

Für das Einrichten der einzelnen Replikation-Jobs steht eine eigene Oberfläche unter Einstellungen → Replication → Komponenten → Editor bereit. Über die Oberfläche können Einträge erzeugt, gelöscht, dupliziert und auch einzeln aktiviert/deaktiviert werden.

Konfigurationsparameter des Replication Moduls

Folgend werden die verschiedenen Parameter und damit verknüpften Funktionen beschrieben. Diese sind unter BPC Administration → Replication → Allgemein zu finden.

Modul

Allgemeine Moduleinstellungen

Name (ID) Beschreibung

Name (`ID`)	Beschreibung
Icon (`module_iconCls`)	Individuell auswählbares Icon, das vor dem Titel angezeigt wird. Falls kein Symbol angezeigt werden soll, kann z.B. "none" eingetragen werden. Bei leerem Feld wird ein Standard-Icon gewählt.

Icon
(module_iconCls)

Individuell auswählbares Icon, das vor dem Titel angezeigt wird.
Falls kein Symbol angezeigt werden soll, kann z.B. "none" eingetragen werden. Bei leerem Feld wird ein Standard-Icon gewählt.

Quelle

Einstellungen zum Quellsystem

Name (ID) Beschreibung

Name (`ID`)	Beschreibung
Datenbankverbindung (`rdmsDataSourceName`)	Datenbankverbindung für den Zugriff auf die Daten. Diese muss zuvor über Backend Connection vom Typ Data Source angelegt worden sein.
SELECT (CTE) (`sourceCommonTableExpressionQuery`)	Wenn dieser Wert gesetzt ist, wird diese Abfrage anstelle des Tabellennamens als Quelle verwendet. Darf nur den SELECT Statement einer Common Table Expression (CTE) enthalten. Das WITH $sourceTable$ AS ( $sourceCommonTableExpressionQuery$ ) $bpcQuery$; wird generiert, so dass es mit den darauf abgesetzten Abfragen vom BPC passt. Wenn diese Möglichkeit verwendet wird, dann wird 'Source_Table' (sourceTable) als Namen der CTE verwendet. Dieser kann übrigens mit dem Namen einer existierenden Datenbanktabelle übereinstimmen.
Tabelle (`sourceTable`)	Name der Tabelle oder View in der Quelldatenbank. Wenn ein SELECT (CTE) angegeben ist, wird dies als Name im CTE verwendet. Darf nicht leer sein!
Zeitzone (`sourceTimeZone`)	Wenn die Datumsspalten keine Zeitzoneninformationen beinhalten, dann werden diese mit der angegebenen Zeitzone interpretiert. Betrifft nicht die Zeitspalte. Für diese gibt es eine separate Zeitzoneneinstellung.
Primärschlüssel (`idColumns`)	Spalten für die Bildung eines eindeutigen Schlüssels im OpenSearch. Eine falsche Konfiguration führt dazu, dass Datensätze überschrieben werden.
Zeitspalte (`lastUpdateColumn`)	Die Spalte muss den Zeitpunkt der letzten Änderung des Datensatzes enthalten. Für die Funktion der Replikation ist es entscheidend, dass bei jeder Änderung des Datensatzes hier der korrekte Zeitpunkt eingetragen wird. Es empfiehlt sich diesen per DB-Trigger setzen zu lassen. Für die Performance der Replikation und der Entlastung der Quelldatenbank sollte auf dieser Spalte unbedingt ein sortierter Index vorhanden sein.
Zeitzone der Zeitspalte (`lastUpdateColumnTimeZone`)	Wenn die Zeitspalte keine Zeitzoneninformationen beinhalten, dann wird diese mit der angegebenen Zeitzone interpretiert. Betrifft keine anderen Datumsspalten. Für diese gibt es eine separate Zeitzonenkonfiguration.
Timeout (`sourceQueryTimeoutInSeconds`)	Legt fest, wie lange der JDBC-Treiber auf eine Rückantwort der DB wartet. Angabe in Sekunden.

Datenbankverbindung
(rdmsDataSourceName)

Datenbankverbindung für den Zugriff auf die Daten. Diese muss zuvor über Backend Connection vom Typ Data Source angelegt worden sein.

SELECT (CTE)
(sourceCommonTableExpressionQuery)

Wenn dieser Wert gesetzt ist, wird diese Abfrage anstelle des Tabellennamens als Quelle verwendet. Darf nur den SELECT Statement einer Common Table Expression (CTE) enthalten. Das WITH $sourceTable$ AS ( $sourceCommonTableExpressionQuery$ ) $bpcQuery$; wird generiert, so dass es mit den darauf abgesetzten Abfragen vom BPC passt. Wenn diese Möglichkeit verwendet wird, dann wird 'Source_Table' (sourceTable) als Namen der CTE verwendet. Dieser kann übrigens mit dem Namen einer existierenden Datenbanktabelle übereinstimmen.

Tabelle
(sourceTable)

Name der Tabelle oder View in der Quelldatenbank. Wenn ein SELECT (CTE) angegeben ist, wird dies als Name im CTE verwendet.
Darf nicht leer sein!

Zeitzone
(sourceTimeZone)

Wenn die Datumsspalten keine Zeitzoneninformationen beinhalten, dann werden diese mit der angegebenen Zeitzone interpretiert.
Betrifft nicht die Zeitspalte. Für diese gibt es eine separate Zeitzoneneinstellung.

Primärschlüssel
(idColumns)

Spalten für die Bildung eines eindeutigen Schlüssels im OpenSearch. Eine falsche Konfiguration führt dazu, dass Datensätze überschrieben werden.

Zeitspalte
(lastUpdateColumn)

Die Spalte muss den Zeitpunkt der letzten Änderung des Datensatzes enthalten.
Für die Funktion der Replikation ist es entscheidend, dass bei jeder Änderung des Datensatzes hier der korrekte Zeitpunkt eingetragen wird. Es empfiehlt sich diesen per DB-Trigger setzen zu lassen.
Für die Performance der Replikation und der Entlastung der Quelldatenbank sollte auf dieser Spalte unbedingt ein sortierter Index vorhanden sein.

Zeitzone der Zeitspalte
(lastUpdateColumnTimeZone)

Wenn die Zeitspalte keine Zeitzoneninformationen beinhalten, dann wird diese mit der angegebenen Zeitzone interpretiert.
Betrifft keine anderen Datumsspalten. Für diese gibt es eine separate Zeitzonenkonfiguration.

Timeout
(sourceQueryTimeoutInSeconds)

Legt fest, wie lange der JDBC-Treiber auf eine Rückantwort der DB wartet. Angabe in Sekunden.

Ziel

Einstellungen zum Zielsystems

Name (ID) Beschreibung

Name (`ID`)	Beschreibung
Index (`targetIndex`)	Name des Index in den die Daten abgelegt werden sollen. Dieser wird bei Bedarf automatisch angelegt.
Index-Erstellungseinstellungen (`targetIndexCreationSettings`)	Vom Standard abweichende Einstellungen. Der Wert wird beim Anlegen/Erzeugen eines OpenSearch-Indexes als dessen "settings"-Wert gesetzt. Wird auch bei der Reindizierung anwendet, da diese einen neuen Index anlegt. Ist dieses Feld leer, dann werden wie die Index-Erstellungseinstellungen der Core Services verwendet. Wenn es gesetzt ist, dann werden nur diese verwendet. Es müssen dann also die Index-Erstellungseinstellungen von Core Service per Copy&Paste als Grundlage verwendet werden.
Feldeinstellungen (`targetIndexMappings`)	Optionale Einstellung für die einzelnen Felder (auch Mapping genannt). Darüber kann z.B. gezielt der Datentyp des Feldes festgelegt werden.
Dynamische Feldvorlagen (`targetIndexDynamicTemplates`)	Vom Standard abweichende Einstellungen. Der Wert wird beim Anlegen/Erzeugen eines OpenSearch-Indexes in Felder-Mappings ("mappings") als "dynamic_templates" gesetzt. Wird auch bei der Reindizierung anwendet, da diese einen neuen Index anlegt. Ist dieses Feld leer, dann werden wie die Dynamische Feldvorlagen der Core Services verwendet.
Feldnamen anpassen (`targetIndexCaseSensitivityOfFields`)	Die Groß-/Kleinschreibung der Felder die in OpenSearch angelegt werden kann hier verändert werden. Die Feldnamen werden aus den Spaltennamen der Datenbank gebildet.

Index
(targetIndex)

Name des Index in den die Daten abgelegt werden sollen. Dieser wird bei Bedarf automatisch angelegt.

Index-Erstellungseinstellungen
(targetIndexCreationSettings)

Vom Standard abweichende Einstellungen. Der Wert wird beim Anlegen/Erzeugen eines OpenSearch-Indexes als dessen "settings"-Wert gesetzt. Wird auch bei der Reindizierung anwendet, da diese einen neuen Index anlegt.
Ist dieses Feld leer, dann werden wie die Index-Erstellungseinstellungen der Core Services verwendet.
Wenn es gesetzt ist, dann werden nur diese verwendet. Es müssen dann also die Index-Erstellungseinstellungen von Core Service per Copy&Paste als Grundlage verwendet werden.

Feldeinstellungen
(targetIndexMappings)

Optionale Einstellung für die einzelnen Felder (auch Mapping genannt). Darüber kann z.B. gezielt der Datentyp des Feldes festgelegt werden.

Dynamische Feldvorlagen
(targetIndexDynamicTemplates)

Vom Standard abweichende Einstellungen. Der Wert wird beim Anlegen/Erzeugen eines OpenSearch-Indexes in Felder-Mappings ("mappings") als "dynamic_templates" gesetzt. Wird auch bei der Reindizierung anwendet, da diese einen neuen Index anlegt.
Ist dieses Feld leer, dann werden wie die Dynamische Feldvorlagen der Core Services verwendet.

Feldnamen anpassen
(targetIndexCaseSensitivityOfFields)

Die Groß-/Kleinschreibung der Felder die in OpenSearch angelegt werden kann hier verändert werden. Die Feldnamen werden aus den Spaltennamen der Datenbank gebildet.

Erweiterte Einstellungen

Name (ID) Beschreibung

Name (`ID`)	Beschreibung
Aktiv (`replicationEnabled`)	Aktiviert die Ausführung dieses Replikationsjobs.
Verzögerter Start (`replicationDelay`)	Verzögerung dieser Replikation (in Sekunden) nach dem initialen Start der Replikationsausführung. Kann genutzt werden, um den Start des BPC zu beschleunigen oder andere Replikations-Jobs initial zu bevorzugen.
Intervall (`replicationInterval`)	Intervall in Sekunden in dem dieser Replikationsjob ausgeführt werden soll. Dieses Intervall ist nicht garantiert, wenn nicht genügend Threads zur Verfügung stehen und zu viele Replikationsjobs (evtl. auch zu lange) laufen.
Startdatum (`replicationStartDate`)	Es werden nur Daten repliziert, die neuer sind als dieser Zeitpunkt. Datumsformat "yyyy-MM-dd' 'HH:mm:ss.SSS".
Tagesbereich pro Durchlauf (`replicationBlockDayRange`)	Werden Daten aus der Vergangenheit repliziert, so steuert dies die Anzahl der Tage, die bei jedem Job-Durchlauf abgearbeitet werden sollen. Ein hoher Wert kann dazu führen, dass die Quelldatenbank, aber auch OpenSearch stark belastet werden. Außerdem werden dadurch evtl. andere Replikations-Jobs blockiert.
Max. Anzahl von Datesätzen (`replicationBlockSize`)	Maximale Anzahl von Datensätzen die auf einmal von der Quelldatenbank geladen und nach OpenSearch geschrieben werden. Dieser Wert beeinflusst direkt den Verbraucht von Arbeitsspeicher im Karaf, da der Speicher reserviert wird, der nötig ist um alle Datensätze in der maximalen Größe im Speicher vorzuhalten. Jedoch wirkt sich ein großer Wert positiv auf die Geschwindigkeit der Replikation aus.
Binärdaten replizieren (`replicationSyncFiles`)	Repliziert auch Spalten vom Typ BLOB. Achtung! Dies kann den Speicherbedarf und die Performance von OpenSearch signifikant beeinflussen.
Binärdaten dekomprimieren (`replicationUnzipSyncedFiles`)	Wenn Binärdaten repliziert werden und die Option aktiviert ist, dann wird geprüft ob die Daten mit GZip komprimiert wurden und dekomprimiert diese vor dem Speichern.
An letzter Positon fortsetzen (`restartReplicationWhereLeftOff`)	Wenn diese Option aktiv ist, wird der Replikatonsjob bei einem Neustart oder Reaktivierung an dem Zeitpunkt in den Daten fortgesetzt, wo er zuletzt aufgehört hat. Ansonsten beginnt die Replikation beim konfigurierten Startzeitpunkt.
Anpassung Zeitgrenze (`adjustUpperDateLimitInSeconds`)	Anpassung der oben Zeitgrenze (in Sekunden). Beeinflusst die obere Datums-Grenze bei der Selektion von Daten in dem dieser Wert zu dem aktuellen Zeitpunkt addiert wird. Eine Änderung des Wertes kann dazu führen, dass Datensätze unnötig mehrfach repliziert werden oder Änderungen erst mit einer gewissen Verzögerung repliziert werden.
Data Management Organisations-ID (`vamOrganizationId`)	Wenn gesetzt, werden Besonderheiten für die Replikation von Data-Management-Daten eingesetzt. Speziell werden nur die Daten der eingetragenen organizationId (wie in Data-Management-Konfiguration) repliziert
Aktiv (`replicationLoggingEnabled`)	Aktiviert das Logging für diesen Replikationsjob. Zusätzlich muss das Logging allgemein am Replikationsmodul aktiv sein.

Aktiv
(replicationEnabled)

Aktiviert die Ausführung dieses Replikationsjobs.

Verzögerter Start
(replicationDelay)

Verzögerung dieser Replikation (in Sekunden) nach dem initialen Start der Replikationsausführung. Kann genutzt werden, um den Start des BPC zu beschleunigen oder andere Replikations-Jobs initial zu bevorzugen.

Intervall
(replicationInterval)

Intervall in Sekunden in dem dieser Replikationsjob ausgeführt werden soll. Dieses Intervall ist nicht garantiert, wenn nicht genügend Threads zur Verfügung stehen und zu viele Replikationsjobs (evtl. auch zu lange) laufen.

Startdatum
(replicationStartDate)

Es werden nur Daten repliziert, die neuer sind als dieser Zeitpunkt.
Datumsformat "yyyy-MM-dd' 'HH:mm:ss.SSS".

Tagesbereich pro Durchlauf
(replicationBlockDayRange)

Werden Daten aus der Vergangenheit repliziert, so steuert dies die Anzahl der Tage, die bei jedem Job-Durchlauf abgearbeitet werden sollen. Ein hoher Wert kann dazu führen, dass die Quelldatenbank, aber auch OpenSearch stark belastet werden. Außerdem werden dadurch evtl. andere Replikations-Jobs blockiert.

Max. Anzahl von Datesätzen
(replicationBlockSize)

Maximale Anzahl von Datensätzen die auf einmal von der Quelldatenbank geladen und nach OpenSearch geschrieben werden. Dieser Wert beeinflusst direkt den Verbraucht von Arbeitsspeicher im Karaf, da der Speicher reserviert wird, der nötig ist um alle Datensätze in der maximalen Größe im Speicher vorzuhalten. Jedoch wirkt sich ein großer Wert positiv auf die Geschwindigkeit der Replikation aus.

Binärdaten replizieren
(replicationSyncFiles)

Repliziert auch Spalten vom Typ BLOB.
Achtung! Dies kann den Speicherbedarf und die Performance von OpenSearch signifikant beeinflussen.

Binärdaten dekomprimieren
(replicationUnzipSyncedFiles)

Wenn Binärdaten repliziert werden und die Option aktiviert ist, dann wird geprüft ob die Daten mit GZip komprimiert wurden und dekomprimiert diese vor dem Speichern.

An letzter Positon fortsetzen
(restartReplicationWhereLeftOff)

Wenn diese Option aktiv ist, wird der Replikatonsjob bei einem Neustart oder Reaktivierung an dem Zeitpunkt in den Daten fortgesetzt, wo er zuletzt aufgehört hat. Ansonsten beginnt die Replikation beim konfigurierten Startzeitpunkt.

Anpassung Zeitgrenze
(adjustUpperDateLimitInSeconds)

Anpassung der oben Zeitgrenze (in Sekunden). Beeinflusst die obere Datums-Grenze bei der Selektion von Daten in dem dieser Wert zu dem aktuellen Zeitpunkt addiert wird. Eine Änderung des Wertes kann dazu führen, dass Datensätze unnötig mehrfach repliziert werden oder Änderungen erst mit einer gewissen Verzögerung repliziert werden.

Data Management Organisations-ID
(vamOrganizationId)

Wenn gesetzt, werden Besonderheiten für die Replikation von Data-Management-Daten eingesetzt. Speziell werden nur die Daten der eingetragenen organizationId (wie in Data-Management-Konfiguration) repliziert

Aktiv
(replicationLoggingEnabled)

Aktiviert das Logging für diesen Replikationsjob.
Zusätzlich muss das Logging allgemein am Replikationsmodul aktiv sein.

Schattenkopie

Bei einer Schattenkopie werden zu dem festgelegten Zeitpunkt alle Dokumente (die nach dem festgelegten 'replicationStartDate' liegen) des OpenSearch-Index (siehe 'targetIndex') in einen neuen Index kopiert. Am Ende wird der Alias auf den neuen Index umgebogen und der bisherige Index gelöscht.

Name (ID) Beschreibung

Name (`ID`)	Beschreibung
Aktiv (`replicationShadowCopyEnabled`)	Erstellung von Schattenkopien aktivieren.
Zeitplan (Cron-Muster) (`replicationShadowCopyCronPattern`)	Cron-ähnliches Pattern (nach Quartz-Scheduler-Syntax) zur Festlegung des Zeitpunktes, wann die Schattenkopien erstellt werden sollen. (Siehe <a target="_blank" href="https://www.quartz-scheduler.org/documentation/quartz-2.3.0/tutorials/crontrigger.html">Quartz CronTrigger-Dokumentation</a>)
Anzahl der Kopien (`replicationShadowCopyKeepCopiesCount`)	Anzahl der Schattenkopien die vorgehalten werden sollen.

Aktiv
(replicationShadowCopyEnabled)

Erstellung von Schattenkopien aktivieren.

Zeitplan (Cron-Muster)
(replicationShadowCopyCronPattern)

Cron-ähnliches Pattern (nach Quartz-Scheduler-Syntax) zur Festlegung des Zeitpunktes, wann die Schattenkopien erstellt werden sollen. (Siehe <a target="_blank" href="https://www.quartz-scheduler.org/documentation/quartz-2.3.0/tutorials/crontrigger.html">Quartz CronTrigger-Dokumentation</a>)

Anzahl der Kopien
(replicationShadowCopyKeepCopiesCount)

Anzahl der Schattenkopien die vorgehalten werden sollen.

Tail Sync

Name (ID) Beschreibung

Name (`ID`)	Beschreibung
Aktiv (`replicationTailSyncEnabled`)	Aktiviert die Tail Sync Funktion. Diese löscht alte Datensätze oder synchronisiert nachträglich Datensätze zwischen Quelle und Ziel. Dies ist nötig, wenn in der Quelle Datensätze gelöscht werden. Neue oder geänderte Datensätze sollten bei korrekter Einstellung über die reguläre Replikation erkannt werden. Falls der Tail-Sync nicht aktiviert ist, kann dieser trotzdem manuell gestartet werden. Dabei werden die anderen Tail Sync Einstellungen berücksichtigt.
Zeitplan (Cron-Muster) (`replicationTailSyncCronPattern`)	Cron-ähnliches Pattern (nach Quartz-Scheduler-Syntax) zur Festlegung des Zeitpunktes, wann der Tail Sync gestartet werden soll. (Siehe <a target="_blank" href="https://www.quartz-scheduler.org/documentation/quartz-2.3.0/tutorials/crontrigger.html">Quartz CronTrigger-Dokumentation</a>)
Max. Anzahl von Datesätzen (`replicationTailSyncBlockSize`)	Maximale Anzahl von Datensätzen die auf einmal von der Quelldatenbank geladen und nach OpenSearch geschrieben werden. Dieser Wert beeinflusst direkt den Verbraucht von Arbeitsspeicher im Karaf, da der Speicher reserviert wird, der nötig ist um alle Datensätze in der maximalen Größe im Speicher vorzuhalten. Jedoch wirkt sich ein großer Wert positiv auf die Geschwindigkeit der Replikation aus.
Startdatum (`replicationTailSyncRelativeStartDate`)	Das relativ angegebene Startdatum. Ab diesem Zeitpunkt wird synchronisiert. Daten, die vor dem Startdatum der Replikation liegen, werden auch weiterhin gelöscht. Dieses Datum wird nur verwendet, wenn es nach dem regulären Startdatum und vor dem Enddatum liegt. Nur in Spezialfällen verwenden!
Enddatum (`replicationTailSyncRelativeEndDate`)	Das relativ angegebene Enddatum. Bis zu diesem Zeitpunkt wird synchronisiert. Das Ende sollte sich nicht mit der regulären Replikation überschneiden (Intervall + Puffer). Syntax: <code>n seconds\|minutes\|hours\|days\|weeks\|months\|years ago</code>
Tagesbereich pro Durchlauf (`replicationTailSyncBlockDayRange`)	Steuert dies die Anzahl der Tage, die bei jedem Durchlauf abgearbeitet werden sollen. Ein hoher Wert kann dazu führen, dass die Quelldatenbank, aber auch OpenSearch stark belastet werden.
Alte Daten löschen (`replicationTailSyncRelativeDeleteOlderThanDate`)	Das relativ anzugebende Löschdatum. Alle Dokumente, die älter sind, werden gelöscht. Wird diese Option nicht gesetzt, dann wird sie auch nicht ausgeführt. Syntax: <code>n seconds\|minutes\|hours\|days\|weeks\|months\|years ago</code>
Tail Sync Logging aktivieren (`replicationTailSyncLoggingEnabled`)	Bei aktiviertem Tail Sync Logging werden Tail Sync Durchläufe im Index `bpc-tailsync-log` protokolliert.

Aktiv
(replicationTailSyncEnabled)

Aktiviert die Tail Sync Funktion. Diese löscht alte Datensätze oder synchronisiert nachträglich Datensätze zwischen Quelle und Ziel. Dies ist nötig, wenn in der Quelle Datensätze gelöscht werden. Neue oder geänderte Datensätze sollten bei korrekter Einstellung über die reguläre Replikation erkannt werden. Falls der Tail-Sync nicht aktiviert ist, kann dieser trotzdem manuell gestartet werden. Dabei werden die anderen Tail Sync Einstellungen berücksichtigt.

Zeitplan (Cron-Muster)
(replicationTailSyncCronPattern)

Cron-ähnliches Pattern (nach Quartz-Scheduler-Syntax) zur Festlegung des Zeitpunktes, wann der Tail Sync gestartet werden soll. (Siehe <a target="_blank" href="https://www.quartz-scheduler.org/documentation/quartz-2.3.0/tutorials/crontrigger.html">Quartz CronTrigger-Dokumentation</a>)

Max. Anzahl von Datesätzen
(replicationTailSyncBlockSize)

Startdatum
(replicationTailSyncRelativeStartDate)

Das relativ angegebene Startdatum. Ab diesem Zeitpunkt wird synchronisiert. Daten, die vor dem Startdatum der Replikation liegen, werden auch weiterhin gelöscht. Dieses Datum wird nur verwendet, wenn es nach dem regulären Startdatum und vor dem Enddatum liegt.
Nur in Spezialfällen verwenden!

Enddatum
(replicationTailSyncRelativeEndDate)

Tagesbereich pro Durchlauf
(replicationTailSyncBlockDayRange)

Steuert dies die Anzahl der Tage, die bei jedem Durchlauf abgearbeitet werden sollen. Ein hoher Wert kann dazu führen, dass die Quelldatenbank, aber auch OpenSearch stark belastet werden.

Alte Daten löschen
(replicationTailSyncRelativeDeleteOlderThanDate)

Tail Sync Logging aktivieren
(replicationTailSyncLoggingEnabled)

Bei aktiviertem Tail Sync Logging werden Tail Sync Durchläufe im Index `bpc-tailsync-log` protokolliert.

Konsistenzprüfung

Nach den Replikationsläufen wird ein einfacher Konsistenzcheck durchgeführt. Dabei werden die Anzahl Dokumente, welche sich in der Quelle und dem Ziel befinden verglichen.

Name (ID) Beschreibung

Name (`ID`)	Beschreibung
Häufigkeit der Konsistenzprüfung (`replicationConsistencyCheckFrequency`)	Die Frequenz, mit welcher der Konsistenzcheck durchgeführt wird. Dabei wird die Anzahl der Datensätze in der Quelldatenbank mit der in OpenSearch verglichen. Die Prüfung kann die Performance der Replikation stark beeinträchtigen und sollte abgeschaltet werden, wenn historische Daten replziziert werden. 0 = keine Prüfung; 3 = Prüfung bei jeder 3. Replikation

Häufigkeit der Konsistenzprüfung
(replicationConsistencyCheckFrequency)

Die Frequenz, mit welcher der Konsistenzcheck durchgeführt wird. Dabei wird die Anzahl der Datensätze in der Quelldatenbank mit der in OpenSearch verglichen. Die Prüfung kann die Performance der Replikation stark beeinträchtigen und sollte abgeschaltet werden, wenn historische Daten replziziert werden.
0 = keine Prüfung; 3 = Prüfung bei jeder 3. Replikation

Lookup Joins

Diese können verwendet werden, um zu replizierende Dokumente mit zusätzlichen Daten anzureichern. Wenn z.B. in den zu replizierenden Daten nur eine Partner-ID steht und noch der Name des Partners etc. im Monitor benötigt wird.

Name (ID) Beschreibung

Name (`ID`)	Beschreibung
Lookup Joins (`join`)	Können verwendet werden, um die loggenden Dokumente automatisch mit zusätzlichen Daten anzureichern, wenn z.B. in den zu loggenden Daten nur eine ID steht und weitere zugehörige Daten über einen bestehenden Index geladen werden können.

Lookup Joins
(join)

Können verwendet werden, um die loggenden Dokumente automatisch mit zusätzlichen Daten anzureichern, wenn z.B. in den zu loggenden Daten nur eine ID steht und weitere zugehörige Daten über einen bestehenden Index geladen werden können.

Konfigurationsparameter eines Replication Jobs

Folgend werden die verschiedenen Parameter und damit verknüpften Funktionen beschrieben. Diese sind unter BPC Administration → Replication → Komponenten zu finden. Es wird empfohlen, die spezialisierte Oberfläche zu verwenden: BPC Administration → Replication → Editor

Modul

Allgemeine Moduleinstellungen

Name (ID) Beschreibung

Name (`ID`)	Beschreibung
Icon (`module_iconCls`)	Individuell auswählbares Icon, das vor dem Titel angezeigt wird. Falls kein Symbol angezeigt werden soll, kann z.B. "none" eingetragen werden. Bei leerem Feld wird ein Standard-Icon gewählt.

Icon
(module_iconCls)

Individuell auswählbares Icon, das vor dem Titel angezeigt wird.
Falls kein Symbol angezeigt werden soll, kann z.B. "none" eingetragen werden. Bei leerem Feld wird ein Standard-Icon gewählt.

Quelle

Einstellungen zum Quellsystem

Name (ID) Beschreibung

Name (`ID`)	Beschreibung
Datenbankverbindung (`rdmsDataSourceName`)	Datenbankverbindung für den Zugriff auf die Daten. Diese muss zuvor über Backend Connection vom Typ Data Source angelegt worden sein.
SELECT (CTE) (`sourceCommonTableExpressionQuery`)	Wenn dieser Wert gesetzt ist, wird diese Abfrage anstelle des Tabellennamens als Quelle verwendet. Darf nur den SELECT Statement einer Common Table Expression (CTE) enthalten. Das WITH $sourceTable$ AS ( $sourceCommonTableExpressionQuery$ ) $bpcQuery$; wird generiert, so dass es mit den darauf abgesetzten Abfragen vom BPC passt. Wenn diese Möglichkeit verwendet wird, dann wird 'Source_Table' (sourceTable) als Namen der CTE verwendet. Dieser kann übrigens mit dem Namen einer existierenden Datenbanktabelle übereinstimmen.
Tabelle (`sourceTable`)	Name der Tabelle oder View in der Quelldatenbank. Wenn ein SELECT (CTE) angegeben ist, wird dies als Name im CTE verwendet. Darf nicht leer sein!
Zeitzone (`sourceTimeZone`)	Wenn die Datumsspalten keine Zeitzoneninformationen beinhalten, dann werden diese mit der angegebenen Zeitzone interpretiert. Betrifft nicht die Zeitspalte. Für diese gibt es eine separate Zeitzoneneinstellung.
Primärschlüssel (`idColumns`)	Spalten für die Bildung eines eindeutigen Schlüssels im OpenSearch. Eine falsche Konfiguration führt dazu, dass Datensätze überschrieben werden.
Zeitspalte (`lastUpdateColumn`)	Die Spalte muss den Zeitpunkt der letzten Änderung des Datensatzes enthalten. Für die Funktion der Replikation ist es entscheidend, dass bei jeder Änderung des Datensatzes hier der korrekte Zeitpunkt eingetragen wird. Es empfiehlt sich diesen per DB-Trigger setzen zu lassen. Für die Performance der Replikation und der Entlastung der Quelldatenbank sollte auf dieser Spalte unbedingt ein sortierter Index vorhanden sein.
Zeitzone der Zeitspalte (`lastUpdateColumnTimeZone`)	Wenn die Zeitspalte keine Zeitzoneninformationen beinhalten, dann wird diese mit der angegebenen Zeitzone interpretiert. Betrifft keine anderen Datumsspalten. Für diese gibt es eine separate Zeitzonenkonfiguration.
Timeout (`sourceQueryTimeoutInSeconds`)	Legt fest, wie lange der JDBC-Treiber auf eine Rückantwort der DB wartet. Angabe in Sekunden.

Datenbankverbindung
(rdmsDataSourceName)

Datenbankverbindung für den Zugriff auf die Daten. Diese muss zuvor über Backend Connection vom Typ Data Source angelegt worden sein.

SELECT (CTE)
(sourceCommonTableExpressionQuery)

Tabelle
(sourceTable)

Name der Tabelle oder View in der Quelldatenbank. Wenn ein SELECT (CTE) angegeben ist, wird dies als Name im CTE verwendet.
Darf nicht leer sein!

Zeitzone
(sourceTimeZone)

Primärschlüssel
(idColumns)

Spalten für die Bildung eines eindeutigen Schlüssels im OpenSearch. Eine falsche Konfiguration führt dazu, dass Datensätze überschrieben werden.

Zeitspalte
(lastUpdateColumn)

Zeitzone der Zeitspalte
(lastUpdateColumnTimeZone)

Timeout
(sourceQueryTimeoutInSeconds)

Legt fest, wie lange der JDBC-Treiber auf eine Rückantwort der DB wartet. Angabe in Sekunden.

Ziel

Einstellungen zum Zielsystems

Name (ID) Beschreibung

Name (`ID`)	Beschreibung
Index (`targetIndex`)	Name des Index in den die Daten abgelegt werden sollen. Dieser wird bei Bedarf automatisch angelegt.
Index-Erstellungseinstellungen (`targetIndexCreationSettings`)	Vom Standard abweichende Einstellungen. Der Wert wird beim Anlegen/Erzeugen eines OpenSearch-Indexes als dessen "settings"-Wert gesetzt. Wird auch bei der Reindizierung anwendet, da diese einen neuen Index anlegt. Ist dieses Feld leer, dann werden wie die Index-Erstellungseinstellungen der Core Services verwendet. Wenn es gesetzt ist, dann werden nur diese verwendet. Es müssen dann also die Index-Erstellungseinstellungen von Core Service per Copy&Paste als Grundlage verwendet werden.
Feldeinstellungen (`targetIndexMappings`)	Optionale Einstellung für die einzelnen Felder (auch Mapping genannt). Darüber kann z.B. gezielt der Datentyp des Feldes festgelegt werden.
Dynamische Feldvorlagen (`targetIndexDynamicTemplates`)	Vom Standard abweichende Einstellungen. Der Wert wird beim Anlegen/Erzeugen eines OpenSearch-Indexes in Felder-Mappings ("mappings") als "dynamic_templates" gesetzt. Wird auch bei der Reindizierung anwendet, da diese einen neuen Index anlegt. Ist dieses Feld leer, dann werden wie die Dynamische Feldvorlagen der Core Services verwendet.
Feldnamen anpassen (`targetIndexCaseSensitivityOfFields`)	Die Groß-/Kleinschreibung der Felder die in OpenSearch angelegt werden kann hier verändert werden. Die Feldnamen werden aus den Spaltennamen der Datenbank gebildet.

Index
(targetIndex)

Name des Index in den die Daten abgelegt werden sollen. Dieser wird bei Bedarf automatisch angelegt.

Index-Erstellungseinstellungen
(targetIndexCreationSettings)

Feldeinstellungen
(targetIndexMappings)

Optionale Einstellung für die einzelnen Felder (auch Mapping genannt). Darüber kann z.B. gezielt der Datentyp des Feldes festgelegt werden.

Dynamische Feldvorlagen
(targetIndexDynamicTemplates)

Feldnamen anpassen
(targetIndexCaseSensitivityOfFields)

Die Groß-/Kleinschreibung der Felder die in OpenSearch angelegt werden kann hier verändert werden. Die Feldnamen werden aus den Spaltennamen der Datenbank gebildet.

Erweiterte Einstellungen

Name (ID) Beschreibung

Name (`ID`)	Beschreibung
Aktiv (`replicationEnabled`)	Aktiviert die Ausführung dieses Replikationsjobs.
Verzögerter Start (`replicationDelay`)	Verzögerung dieser Replikation (in Sekunden) nach dem initialen Start der Replikationsausführung. Kann genutzt werden, um den Start des BPC zu beschleunigen oder andere Replikations-Jobs initial zu bevorzugen.
Intervall (`replicationInterval`)	Intervall in Sekunden in dem dieser Replikationsjob ausgeführt werden soll. Dieses Intervall ist nicht garantiert, wenn nicht genügend Threads zur Verfügung stehen und zu viele Replikationsjobs (evtl. auch zu lange) laufen.
Startdatum (`replicationStartDate`)	Es werden nur Daten repliziert, die neuer sind als dieser Zeitpunkt. Datumsformat "yyyy-MM-dd' 'HH:mm:ss.SSS".
Tagesbereich pro Durchlauf (`replicationBlockDayRange`)	Werden Daten aus der Vergangenheit repliziert, so steuert dies die Anzahl der Tage, die bei jedem Job-Durchlauf abgearbeitet werden sollen. Ein hoher Wert kann dazu führen, dass die Quelldatenbank, aber auch OpenSearch stark belastet werden. Außerdem werden dadurch evtl. andere Replikations-Jobs blockiert.
Max. Anzahl von Datesätzen (`replicationBlockSize`)	Maximale Anzahl von Datensätzen die auf einmal von der Quelldatenbank geladen und nach OpenSearch geschrieben werden. Dieser Wert beeinflusst direkt den Verbraucht von Arbeitsspeicher im Karaf, da der Speicher reserviert wird, der nötig ist um alle Datensätze in der maximalen Größe im Speicher vorzuhalten. Jedoch wirkt sich ein großer Wert positiv auf die Geschwindigkeit der Replikation aus.
Binärdaten replizieren (`replicationSyncFiles`)	Repliziert auch Spalten vom Typ BLOB. Achtung! Dies kann den Speicherbedarf und die Performance von OpenSearch signifikant beeinflussen.
Binärdaten dekomprimieren (`replicationUnzipSyncedFiles`)	Wenn Binärdaten repliziert werden und die Option aktiviert ist, dann wird geprüft ob die Daten mit GZip komprimiert wurden und dekomprimiert diese vor dem Speichern.
An letzter Positon fortsetzen (`restartReplicationWhereLeftOff`)	Wenn diese Option aktiv ist, wird der Replikatonsjob bei einem Neustart oder Reaktivierung an dem Zeitpunkt in den Daten fortgesetzt, wo er zuletzt aufgehört hat. Ansonsten beginnt die Replikation beim konfigurierten Startzeitpunkt.
Anpassung Zeitgrenze (`adjustUpperDateLimitInSeconds`)	Anpassung der oben Zeitgrenze (in Sekunden). Beeinflusst die obere Datums-Grenze bei der Selektion von Daten in dem dieser Wert zu dem aktuellen Zeitpunkt addiert wird. Eine Änderung des Wertes kann dazu führen, dass Datensätze unnötig mehrfach repliziert werden oder Änderungen erst mit einer gewissen Verzögerung repliziert werden.
Data Management Organisations-ID (`vamOrganizationId`)	Wenn gesetzt, werden Besonderheiten für die Replikation von Data-Management-Daten eingesetzt. Speziell werden nur die Daten der eingetragenen organizationId (wie in Data-Management-Konfiguration) repliziert
Aktiv (`replicationLoggingEnabled`)	Aktiviert das Logging für diesen Replikationsjob. Zusätzlich muss das Logging allgemein am Replikationsmodul aktiv sein.

Aktiv
(replicationEnabled)

Aktiviert die Ausführung dieses Replikationsjobs.

Verzögerter Start
(replicationDelay)

Intervall
(replicationInterval)

Startdatum
(replicationStartDate)

Es werden nur Daten repliziert, die neuer sind als dieser Zeitpunkt.
Datumsformat "yyyy-MM-dd' 'HH:mm:ss.SSS".

Tagesbereich pro Durchlauf
(replicationBlockDayRange)

Max. Anzahl von Datesätzen
(replicationBlockSize)

Binärdaten replizieren
(replicationSyncFiles)

Repliziert auch Spalten vom Typ BLOB.
Achtung! Dies kann den Speicherbedarf und die Performance von OpenSearch signifikant beeinflussen.

Binärdaten dekomprimieren
(replicationUnzipSyncedFiles)

Wenn Binärdaten repliziert werden und die Option aktiviert ist, dann wird geprüft ob die Daten mit GZip komprimiert wurden und dekomprimiert diese vor dem Speichern.

An letzter Positon fortsetzen
(restartReplicationWhereLeftOff)

Anpassung Zeitgrenze
(adjustUpperDateLimitInSeconds)

Data Management Organisations-ID
(vamOrganizationId)

Aktiv
(replicationLoggingEnabled)

Aktiviert das Logging für diesen Replikationsjob.
Zusätzlich muss das Logging allgemein am Replikationsmodul aktiv sein.

Schattenkopie

Name (ID) Beschreibung

Name (`ID`)	Beschreibung
Aktiv (`replicationShadowCopyEnabled`)	Erstellung von Schattenkopien aktivieren.
Zeitplan (Cron-Muster) (`replicationShadowCopyCronPattern`)	Cron-ähnliches Pattern (nach Quartz-Scheduler-Syntax) zur Festlegung des Zeitpunktes, wann die Schattenkopien erstellt werden sollen. (Siehe <a target="_blank" href="https://www.quartz-scheduler.org/documentation/quartz-2.3.0/tutorials/crontrigger.html">Quartz CronTrigger-Dokumentation</a>)
Anzahl der Kopien (`replicationShadowCopyKeepCopiesCount`)	Anzahl der Schattenkopien die vorgehalten werden sollen.

Aktiv
(replicationShadowCopyEnabled)

Erstellung von Schattenkopien aktivieren.

Zeitplan (Cron-Muster)
(replicationShadowCopyCronPattern)

Anzahl der Kopien
(replicationShadowCopyKeepCopiesCount)

Anzahl der Schattenkopien die vorgehalten werden sollen.

Tail Sync

Name (ID) Beschreibung

Name (`ID`)	Beschreibung
Aktiv (`replicationTailSyncEnabled`)	Aktiviert die Tail Sync Funktion. Diese löscht alte Datensätze oder synchronisiert nachträglich Datensätze zwischen Quelle und Ziel. Dies ist nötig, wenn in der Quelle Datensätze gelöscht werden. Neue oder geänderte Datensätze sollten bei korrekter Einstellung über die reguläre Replikation erkannt werden. Falls der Tail-Sync nicht aktiviert ist, kann dieser trotzdem manuell gestartet werden. Dabei werden die anderen Tail Sync Einstellungen berücksichtigt.
Zeitplan (Cron-Muster) (`replicationTailSyncCronPattern`)	Cron-ähnliches Pattern (nach Quartz-Scheduler-Syntax) zur Festlegung des Zeitpunktes, wann der Tail Sync gestartet werden soll. (Siehe <a target="_blank" href="https://www.quartz-scheduler.org/documentation/quartz-2.3.0/tutorials/crontrigger.html">Quartz CronTrigger-Dokumentation</a>)
Max. Anzahl von Datesätzen (`replicationTailSyncBlockSize`)	Maximale Anzahl von Datensätzen die auf einmal von der Quelldatenbank geladen und nach OpenSearch geschrieben werden. Dieser Wert beeinflusst direkt den Verbraucht von Arbeitsspeicher im Karaf, da der Speicher reserviert wird, der nötig ist um alle Datensätze in der maximalen Größe im Speicher vorzuhalten. Jedoch wirkt sich ein großer Wert positiv auf die Geschwindigkeit der Replikation aus.
Startdatum (`replicationTailSyncRelativeStartDate`)	Das relativ angegebene Startdatum. Ab diesem Zeitpunkt wird synchronisiert. Daten, die vor dem Startdatum der Replikation liegen, werden auch weiterhin gelöscht. Dieses Datum wird nur verwendet, wenn es nach dem regulären Startdatum und vor dem Enddatum liegt. Nur in Spezialfällen verwenden!
Enddatum (`replicationTailSyncRelativeEndDate`)	Das relativ angegebene Enddatum. Bis zu diesem Zeitpunkt wird synchronisiert. Das Ende sollte sich nicht mit der regulären Replikation überschneiden (Intervall + Puffer). Syntax: <code>n seconds\|minutes\|hours\|days\|weeks\|months\|years ago</code>
Tagesbereich pro Durchlauf (`replicationTailSyncBlockDayRange`)	Steuert dies die Anzahl der Tage, die bei jedem Durchlauf abgearbeitet werden sollen. Ein hoher Wert kann dazu führen, dass die Quelldatenbank, aber auch OpenSearch stark belastet werden.
Alte Daten löschen (`replicationTailSyncRelativeDeleteOlderThanDate`)	Das relativ anzugebende Löschdatum. Alle Dokumente, die älter sind, werden gelöscht. Wird diese Option nicht gesetzt, dann wird sie auch nicht ausgeführt. Syntax: <code>n seconds\|minutes\|hours\|days\|weeks\|months\|years ago</code>
Tail Sync Logging aktivieren (`replicationTailSyncLoggingEnabled`)	Bei aktiviertem Tail Sync Logging werden Tail Sync Durchläufe im Index `bpc-tailsync-log` protokolliert.

Aktiv
(replicationTailSyncEnabled)

Zeitplan (Cron-Muster)
(replicationTailSyncCronPattern)

Max. Anzahl von Datesätzen
(replicationTailSyncBlockSize)

Startdatum
(replicationTailSyncRelativeStartDate)

Enddatum
(replicationTailSyncRelativeEndDate)

Tagesbereich pro Durchlauf
(replicationTailSyncBlockDayRange)

Steuert dies die Anzahl der Tage, die bei jedem Durchlauf abgearbeitet werden sollen. Ein hoher Wert kann dazu führen, dass die Quelldatenbank, aber auch OpenSearch stark belastet werden.

Alte Daten löschen
(replicationTailSyncRelativeDeleteOlderThanDate)

Tail Sync Logging aktivieren
(replicationTailSyncLoggingEnabled)

Bei aktiviertem Tail Sync Logging werden Tail Sync Durchläufe im Index `bpc-tailsync-log` protokolliert.

Konsistenzprüfung

Nach den Replikationsläufen wird ein einfacher Konsistenzcheck durchgeführt. Dabei werden die Anzahl Dokumente, welche sich in der Quelle und dem Ziel befinden verglichen.

Name (ID) Beschreibung

Name (`ID`)	Beschreibung
Häufigkeit der Konsistenzprüfung (`replicationConsistencyCheckFrequency`)	Die Frequenz, mit welcher der Konsistenzcheck durchgeführt wird. Dabei wird die Anzahl der Datensätze in der Quelldatenbank mit der in OpenSearch verglichen. Die Prüfung kann die Performance der Replikation stark beeinträchtigen und sollte abgeschaltet werden, wenn historische Daten replziziert werden. 0 = keine Prüfung; 3 = Prüfung bei jeder 3. Replikation

Häufigkeit der Konsistenzprüfung
(replicationConsistencyCheckFrequency)

Lookup Joins

Name (ID) Beschreibung

Name (`ID`)	Beschreibung
Lookup Joins (`join`)	Können verwendet werden, um die loggenden Dokumente automatisch mit zusätzlichen Daten anzureichern, wenn z.B. in den zu loggenden Daten nur eine ID steht und weitere zugehörige Daten über einen bestehenden Index geladen werden können.

Lookup Joins
(join)

Grundeinstellungen

Setting (Key) Datentyp Beschreibung

Setting (Key)	Datentyp	Beschreibung
Replication_Enabled (`replicationEnabled`)	boolean	Den Replikationsjob aktivieren/deaktivieren
Replication_StartDate (`replicationStartDate`)	String	Replikation von Datensätzen die neuer sind als dieser Zeitpunkt. Datumsformat "yyyy-MM-dd' 'HH:mm:ss.SSS" oder als relativer Wert im Format: `1 second\|minute\|hour\|day\|week\|month\|year ago n seconds\|minutes\|hours\|days\|weeks\|months\|years ago` Beispiele `1970-01-01 00:00:00.000 1 week ago 6 months ago 42 days ago`

Replication_Enabled
(replicationEnabled)

boolean

Den Replikationsjob aktivieren/deaktivieren

Replication_StartDate
(replicationStartDate)

String

Replikation von Datensätzen die neuer sind als dieser Zeitpunkt.
Datumsformat "yyyy-MM-dd' 'HH:mm:ss.SSS"

oder

als relativer Wert im Format:

1 second|minute|hour|day|week|month|year ago
n seconds|minutes|hours|days|weeks|months|years ago

Beispiele

1970-01-01 00:00:00.000
1 week ago
6 months ago
42 days ago

Quelle / Source

Setting (Key) Datentyp Beschreibung

Source_DataSource
(rdmsDataSourceName)

String

Zu verwendende Datenquelle (ID der Backend Connections vom Typ data_source)

Source_Table
(sourceTable)

String

Tabellenname der Quelle bzw. Name der CTE, wenn die optionale 'Source_CommonTableExpressionQuery' verwendet wird.

Source_Timezone
(sourceTimeZone)

String

Zeitzone der in der Quell-Datenbanktabelle verwendeten Datum-Felder (verwendet intern TimeZone.getTimeZone). Wird nur auf die eigentlichen Daten angewandt und nicht auf die der 'lastUpdateColumn'-Spalte.

Beispiele

UTC
GMT+1
GMT-8
America/Los_Angeles
Europe/Berlin
Etc/GMT
CET

Source_IdColumns
(idColumns)

String

Spalten für die Bildung eines eindeutigen Schlüssels im OpenSearch. Zum Beispiel: "PROCESSID,CHILDID"

Source_LastUpdateColumn
(lastUpdateColumn)

String

Diese Spalte wird für die Ermittlung des Alters des Datensatzes herangezogen

Es wird dringend empfohlen, in der Quelldatenbank auf diese Spalten einen Index anzulegen.

Source_LastUpdateColumnTimezone
(lastUpdateColumnTimeZone)

String

Zeitzone, welche in der Quell-Datenbanktabelle für die Daten in der lastUpdateColumn-Spalte verwendet wird.

Das Setting kommt nur im Zusammenspiel mit [adjustUpperDateLimitInSeconds] zur Anwendung.

Beispiele

UTC
GMT+1
GMT-8
America/Los_Angeles
Europe/Berlin
Etc/GMT
CET

Source_QueryTimeoutInSeconds
(sourceQueryTimeoutInSeconds)

Integer

Legt fest, wie lange der JDBC-Treiber auf eine Rückantwort der DB wartet. Siehe auch JDBC java.sql.Statement.setQueryTimeout()

Source_CommonTableExpressionQuery
(sourceCommonTableExpressionQuery)

String

Kann anstatt Datenbank-Views verwendet werden. Darf nur den SELECT Statement einer Common Table Expression (CTE) enthalten. Das WITH $sourceTable$ AS ( $sourceCommonTableExpressionQuery$ ) $bpcQuery$; wird generiert, so dass es mit den darauf abgesetzten Abfragen vom BPC passt. Wenn diese Möglichkeit verwendet wird, dann wird 'Source_Table' (sourceTable) als Namen der CTE verwendet. Dieser kann übrigens mit dem Namen einer existierenden Datenbanktabelle übereinstimmen.

Ziel / Target

Setting (Key) Datentyp Beschreibung

Setting (Key)	Datentyp	Beschreibung
Target_Index (`targetIndex`)	String	Ziel-Index im OpenSearch. Falls noch nicht vorhanden, wird der Index automatisch erstellt.
Target_CaseSensitivityOfFields (`targetIndexCaseSensitivityOfFields`)	String	Legt fest, wie die Felder in OpenSearch angelegt werden sollen (Groß-/Kleinschreibung). `asSource` = werden genauso angelegt wie sie von der Datenbank zurückgeliefert werden `lowerCase` = Spaltennamen werden in Kleinschreibung umgewandelt `upperCase` = Spaltennamen werden in Großschreibung umgewandelt
Target_IndexCreationSettings (`targetIndexCreationSettings`)	JSON	Dem Ziel-Index bei Erstellung abweichende Settings vergeben. Ist dieses Feld leer, dann werden wie gewohnt die Core Services Einstellung → Core_IndexCreationSettings verwendet. Wenn es gesetzt ist, dann werden nur diese verwendet. Es müssen dann also die Einstellungen von Core_IndexCreationSettings per Copy&Paste als Grundlage verwendet werden. Beispiel mit hinzugefügtem "Index Sorting" `{ "number_of_shards": "5", "number_of_replicas": "1", "index": { "sort.field": "LASTUPDATE", "sort.order": "desc" }, "analysis": { "normalizer": { "lowercaseNormalizer": { "filter": [ "lowercase" ], "char_filter": [], "type": "custom" } } } }` Soll das "Index Sorting" verwendet werden, dann müssen für die angegebenen Sortierungsfelder (LASTUPDATE in dem Beispiel) auch gleich OpenSearch-Mappings angelegt werden (siehe Target_IndexMappings).
Target_IndexMappings (`targetIndexMappings`)	JSON	Dem Ziel-Index bei Erstellung ein Mapping vergeben. Sollte nur in bestimmten Fällen notwendig sein. Das Mapping für das "Index Sorting" Beispiel von oben. `{ "properties": { "LASTUPDATE": { "type": "date" } } }`
Target_IndexDynamicTemplates (`targetIndexDynamicTemplates`)	JSON	Dem Ziel-Index ein maßgeschneidertes Mapping zuweisen. Ist dies gesetzt, dann wird das Globale (siehe Core Einstellung → Core_IndexDynamicTemplates) nicht verwendet. In der Elasticsearch Dokumentation (Verweis bis die OpenSearch Dokumentation ebenbürtig ist) gibt es mehr Infos zu den Möglichkeiten der Dynamic Templates. Bei dem folgenden Beispiel werden alle Felder die OpenSearch als Textfelder (Strings) erkennt mit einem Mapping versehen ("alle_textfelder") bei dem der Inhalt nicht analysiert wird (spart Speicherplatz und die Daten können trotzdem noch angezeigt werden). Plus einer Ausnahme ("spezialfall"): Für alle Textfelder welche den Namenspostfix 'name' haben wird unser Standard Mapping verwendet. Beispiel `[ { "spezialfall": { "match_mapping_type": "string", "match": "name", "mapping": { "type": "text", "fields": { "lowercase": { "normalizer": "lowercaseNormalizer", "type": "keyword" }, "raw": { "type": "keyword" } } } } }, { "alle_textfelder": { "match_mapping_type": "string", "match": "", "mapping": { "type": "keyword", "analyzer": false } } } ]` Um den OpenSearch-Typ für ein Datenbankfeld vorzugeben. Es kann ab und zu vorkommen, dass sich OpenSearch mit dem Mapping vertut und einen unpassenden Typ verwendet. Konkretes Beispiel: Die Oracle Spalte mit dem Namen ‘ZAHL’ vom Datentyp ‘NUMBER(10,2)’ wird im OpenSearch Mapping als Typ ‘long’ anstatt ‘float’ angelegt. Mit dem untenstehenden Beispiel kann dies korrigiert werden. Beispiel `[ { "ZAHL_long_als_float": { "match_mapping_type": "long", "match": "ZAHL", "mapping": { "type": "float" } } } ]`

Target_Index
(targetIndex)

String

Ziel-Index im OpenSearch.
Falls noch nicht vorhanden, wird der Index automatisch erstellt.

Target_CaseSensitivityOfFields
(targetIndexCaseSensitivityOfFields)

String

Legt fest, wie die Felder in OpenSearch angelegt werden sollen (Groß-/Kleinschreibung).

asSource = werden genauso angelegt wie sie von der Datenbank zurückgeliefert werden
lowerCase = Spaltennamen werden in Kleinschreibung umgewandelt
upperCase = Spaltennamen werden in Großschreibung umgewandelt

Target_IndexCreationSettings
(targetIndexCreationSettings)

JSON

Dem Ziel-Index bei Erstellung abweichende Settings vergeben.

Ist dieses Feld leer, dann werden wie gewohnt die Core Services Einstellung → Core_IndexCreationSettings verwendet.
Wenn es gesetzt ist, dann werden nur diese verwendet. Es müssen dann also die Einstellungen von Core_IndexCreationSettings per Copy&Paste als Grundlage verwendet werden.

Beispiel mit hinzugefügtem "Index Sorting"

{
   "number_of_shards": "5",
   "number_of_replicas": "1",
   "index": {
      "sort.field": "LASTUPDATE",
      "sort.order": "desc"
   },
   "analysis": {
      "normalizer": {
         "lowercaseNormalizer": {
            "filter": [
               "lowercase"
            ],
            "char_filter": [],
            "type": "custom"
         }
      }
   }
}

Soll das "Index Sorting" verwendet werden, dann müssen für die angegebenen Sortierungsfelder (LASTUPDATE in dem Beispiel) auch gleich OpenSearch-Mappings angelegt werden (siehe Target_IndexMappings).

Target_IndexMappings
(targetIndexMappings)

JSON

Dem Ziel-Index bei Erstellung ein Mapping vergeben. Sollte nur in bestimmten Fällen notwendig sein.

Das Mapping für das "Index Sorting" Beispiel von oben.

{
   "properties": {
      "LASTUPDATE": {
         "type": "date"
      }
   }
}

Target_IndexDynamicTemplates
(targetIndexDynamicTemplates)

JSON

Dem Ziel-Index ein maßgeschneidertes Mapping zuweisen. Ist dies gesetzt, dann wird das Globale (siehe Core Einstellung → Core_IndexDynamicTemplates) nicht verwendet.

In der Elasticsearch Dokumentation (Verweis bis die OpenSearch Dokumentation ebenbürtig ist) gibt es mehr Infos zu den Möglichkeiten der Dynamic Templates.

Bei dem folgenden Beispiel werden alle Felder die OpenSearch als Textfelder (Strings) erkennt mit einem Mapping versehen ("alle_textfelder") bei dem der Inhalt nicht analysiert wird (spart Speicherplatz und die Daten können trotzdem noch angezeigt werden). Plus einer Ausnahme ("spezialfall"): Für alle Textfelder welche den Namenspostfix 'name' haben wird unser Standard Mapping verwendet.

Beispiel

[
  {
    "spezialfall": {
      "match_mapping_type": "string",
      "match": "*name",
      "mapping": {
        "type": "text",
        "fields": {
          "lowercase": {
            "normalizer": "lowercaseNormalizer",
            "type": "keyword"
          },
          "raw": {
            "type": "keyword"
          }
        }
      }
    }
  },
  {
    "alle_textfelder": {
      "match_mapping_type": "string",
      "match": "*",
      "mapping": {
        "type": "keyword",
        "analyzer": false
      }
    }
  }
]

Um den OpenSearch-Typ für ein Datenbankfeld vorzugeben. Es kann ab und zu vorkommen, dass sich OpenSearch mit dem Mapping vertut und einen unpassenden Typ verwendet. Konkretes Beispiel: Die Oracle Spalte mit dem Namen ‘ZAHL’ vom Datentyp ‘NUMBER(10,2)’ wird im OpenSearch Mapping als Typ ‘long’ anstatt ‘float’ angelegt. Mit dem untenstehenden Beispiel kann dies korrigiert werden.

Beispiel

[
  {
    "ZAHL_long_als_float": {
      "match_mapping_type": "long",
      "match": "ZAHL",
      "mapping": {
        "type": "float"
      }
    }
  }
]

Erweiterte Einstellungen / Advanced

Setting (Key) Datentyp Beschreibung

Replication_RestartWhereLeftOff
(restartReplicationWhereLeftOff)

boolean

Beim Start des Servers oder bei Änderung eines Jobs werden die Replikationsjobs neu gestartet und fangen wieder von vorne an zu replizieren (siehe replicationStartDate). Wenn diese Einstellung auf 'true' gesetzt ist, dann setzt die Replikation beim Datum des jüngsten Datensatzes der repliziert wurde wieder auf. Diese Zeitstempel werden als Metadaten im OpenSearch Index abgelegt.

Replication_Delay
(replicationDelay)

Integer

Verzögerung in Sekunden nach dem die Replikation gestartet wird

Replication_Interval
(replicationInterval)

Integer

Interval in Sekunden für die Replikation

Replication_BlockDayRange
(replicationBlockDayRange)

Integer

Anzahl der Tage (Block), die bei jedem Job-Durchlauf abgearbeitet werden sollen. Diesen Wert nicht zu hoch ansetzen, da dies dann bei der Quell-Datenbank eine erhöhte Last verursacht und auch OpenSearch/Lucene zu keiner Verschnaufpause kommt.

Beispiel 10 Tage: Der Job ist gerade beim 10.03.2015 angekommen, dann werden die Datensätze vom 10.03.2015 bis zum 20.03.2015 repliziert und beim folgenden Durchlauf vom 20.03.2015 bis zum 30.03.2015.

Replication_BlockSize
(replicationBlockSize)

Integer

Blockgröße für die Übertragung von DB nach OpenSearch. Anzahl der Datenbank-Sätze, die der JDBC-Treiber als Block einliest und im Speicher hält.

Es zeichnet sich aktuell ab, dass eine größere Blocksize besser ist. Siehe auch: Replikationsdauer. Aber bitte nicht übertreiben, da es andernfalls zu OutOfMemory Exceptions kommt. Eine Blockgröße von 2500 ist bei manchen Datenbanktabellen bereits zu hoch angesetzt.

Replication_SyncFiles
(replicationSyncFiles)

boolean

Synchronisation von BLOBs

Achtung eine nachträgliche Aktivierung ist aktuell nicht möglich.

Replication_UnzipSyncedFiles
(replicationUnzipSyncedFiles)

boolean

Entpackt synchronisierte Dateiinhalte automatisch.

Kommt nur zur Anwendung, wenn replicationSyncFiles aktiv ist.

Replication_AdjustUpperDateLimitInSeconds
(adjustUpperDateLimitInSeconds)

Integer

Umgehung eines Datenbankproblems, bei dem Satzaktualisierungen - welche durch einen Datenbank-Trigger initiiert werden - zu spät geschrieben und dadurch beim Replikationslauf nicht beachtet werden können (wir reden hier von 1-3 Sekunden).

Mit dieser Option werden die Sätze mit einem Aktualisierungstimestamp minus des festgelegten Wertes selektiert. In der Voreinstellung von 0, ist diese Möglichkeit deaktiviert und es wird wie bisher mit einem Timestamp in der Zukunft selektiert (replicationBlockDayRange). Da wir hierbei die Timestamp-Funktion der Datenbank verwenden, wird diese Möglichkeit momentan nur bei Oracle, MS SQL und MySQL angewendet.

Beispiel 3 Sekunden: Es werden die Sätze ab dem Timestamp des zuletzt replizierten Satzes bis zum aktuellen Timestamp der Datenbank minus 3 Sekunden selektiert. Klar sind dann nicht immer die aktuellsten Daten im BPC vorhanden, aber hoffentlich sind diese dann in einem konsistenten Zustand mit der Datenbank.

Replication_VamOrganizationId
(vamOrganizationId)

String

experimentell

Wenn nicht leer, dann werden Besonderheiten für die Replikation von Data-Management-Daten eingesetzt. Speziell werden nur die Daten der eingetragenen organizationId (wie in Data-Management-Konfiguration) repliziert

Replication_LoggingEnabled
(replicationLoggingEnabled)

boolean

Hier kann das Logging der Replikationsdurchläufe pro Replication Job aktiviert und deaktiviert werden.

Schattenkopien

Zusatzhinweis: Die in OpenSearch als gelöscht markierten Dokumente (entweder selbst manuell gelöscht oder durch den Tail Sync) werden natürlich auch nicht mit in den neuen Index übernommen. Achtung: Der zugehörige Replikationslauf wird solange ausgesetzt, bis die Schattenkopie erstellt wurde.

Setting (Key) Datentyp Beschreibung

Setting (Key)	Datentyp	Beschreibung
ShadowCopy_Enabled (`replicationShadowCopyEnabled`)	boolean	Erstellung von Schattenkopien aktivieren (shadow copy).
ShadowCopy_CronPattern (`replicationShadowCopyCronPattern`)	String	Cron-ähnliches Pattern (nach Quartz-Scheduler-Syntax) zur Festlegung des Zeitpunktes, wann die Schattenkopien erstellt werden sollen. Beispiele `0 15 16 ? * SUN = Jeden Sonntag um 16:15 Uhr 0 /30 * * ? = Alle 30 Minuten 30 59 11 ? * 1,2,3,4,5 = Am Montag, Dienstag, Mittwoch, Donnerstag und Freitag um 11:59:30 Uhr` Weitere Beispiele und die Dokumentation sind auf der Quartz-Scheduler Webseite zu finden.
ShadowCopy_KeepCopiesCount (`replicationShadowCopyKeepCopiesCount`)	Integer	Anzahl der Schattenkopien die vorgehalten werden sollen. `0` = keine Schattenkopie wird vorgehalten `3` = Es werden 3 Schattenkopien vorgehalten (diese befinden sich im 'Close'-Status, um Ressourcen zu sparen)

ShadowCopy_Enabled
(replicationShadowCopyEnabled)

boolean

Erstellung von Schattenkopien aktivieren (shadow copy).

ShadowCopy_CronPattern
(replicationShadowCopyCronPattern)

String

Cron-ähnliches Pattern (nach Quartz-Scheduler-Syntax) zur Festlegung des Zeitpunktes, wann die Schattenkopien erstellt werden sollen.

Beispiele

0 15 16 ? * SUN = Jeden Sonntag um 16:15 Uhr
0 */30 * * * ? = Alle 30 Minuten
30 59 11 ? * 1,2,3,4,5 = Am Montag, Dienstag, Mittwoch, Donnerstag und Freitag um 11:59:30 Uhr

Weitere Beispiele und die Dokumentation sind auf der Quartz-Scheduler Webseite zu finden.

ShadowCopy_KeepCopiesCount
(replicationShadowCopyKeepCopiesCount)

Integer

Anzahl der Schattenkopien die vorgehalten werden sollen.

0 = keine Schattenkopie wird vorgehalten

3 = Es werden 3 Schattenkopien vorgehalten (diese befinden sich im 'Close'-Status, um Ressourcen zu sparen)

Tail Sync

Der 'Tail Sync' arbeitet auf dem aktuellen Index (siehe 'targetIndex') und synchronisiert älterer Daten (neue/geänderte/gelöschte Datenbanksätze) mit OpenSearch, sodass diese wieder mit der Datenbank übereinstimmen. Dies kann z.B. jede Nacht einmal durchgeführt werden. Dokumente, die älter als das Startdatum der Replikation sind (siehe 'replicationStartDate'), werden erst einmal aus dem OpenSearch-Index gelöscht. Danach geht er Blockweise (Default 10 Tages-Schritte) die Datenbank durch und gleicht diese mit OpenSearch ab. Dabei werden neue/geänderte Datenbanksätze in den OpenSearch Index übernommen und Dokumente, die nicht mehr in der Datenbank existieren, werden in OpenSearch gelöscht. Der Tail Sync arbeitet nur mit den festgelegten 'idColumns' und 'lastUpdateColumn' Feldern (Hint: passender DB-Index hilft Wunder!). Die kompletten Daten werden nur bei neuen/geänderten Datenbanksätzen ausgelesen.

Alternativ bzw. zusätzlich zu einem zeitgesteuerten Tail Sync kann dieser auch manuell gestartet werden. Dazu gibt es unter Replication → Jobs für jeden Replikationsjob einen Button, der einen Tail Sync startet. Für das manuelle Starten haben die Einstellung replicationTailSyncEnabled und replicationTailSyncCronPattern keine Auswirkungen, alle anderen Einstellungen werden berücksichtigt.

Der Sync läuft nicht bis zum aktuellen Datum (siehe [replicationTailSyncRelativeEndDate]), da diese Sätze auch weiterhin von unserer normalen Replikation abgearbeitet werden.

Setting (Key) Datentyp Beschreibung

TailSync_Enabled
(replicationTailSyncEnabled)

boolean

Den 'Tail Sync' aktivieren

TailSync_CronPattern
(replicationTailSyncCronPattern)

String

Cron-ähnliches Pattern (nach Quartz-Scheduler-Syntax) zur Festlegung des Zeitpunktes, wann der Tail Sync gestartet werden soll.

Beispiele

0 5 2 * * ? = Jede Nacht um 2:05 Uhr
0 35 21 ? * Sun = Jeden Sonntag um 21:35 Uhr
30 5 3 ? * 1,2,3,4,5 = Am Montag, Dienstag, Mittwoch, Donnerstag und Freitag um 3:05:30 Uhr

Weitere Beispiele und die Dokumentation sind auf der Quartz-Scheduler Webseite zu finden.

TailSync_BlockSize
(replicationTailSyncBlockSize)

Integer

Blockgröße des Datenbanktreibers. Beachte den Hinweis zu der Option replicationBlockSize.

TailSync_RelativeStartDate
(replicationTailSyncRelativeStartDate)

String

Das relativ angegebene Startdatum. Ab diesem Zeitpunkt soll dann synchronisiert werden. Daten, die vor dem Startdatum der Replikation liegen, werden auch weiterhin gelöscht. Dieses Datum wird nur verwendet, wenn es nach dem regulären Startdatum und vor dem Enddatum liegt.

1 second|minute|hour|day|week|month|year ago
n seconds|minutes|hours|days|weeks|months|years ago

Diese Option sollte nur in speziellen Fällen verwendet werden. Es kann zu Inkonsistenzen kommen, wenn in der Datenbank Sätze gelöscht werden, welche vor diesem relativen Startdatum liegen. Diese bleiben dann im OpenSearch-Index enthalten, obwohl sie nicht mehr in der Datenbank vorhanden sind.

TailSync_RelativeEndDate
(replicationTailSyncRelativeEndDate)

String

Das relativ angegebene Enddatum. Bis zu diesem Zeitpunkt soll dann synchronisiert werden und nicht weiter.

1 second|minute|hour|day|week|month|year ago
n seconds|minutes|hours|days|weeks|months|years ago

TailSync_BlockDayRange
(replicationTailSyncBlockDayRange)

Integer

Anzahl der Tage (Block) in denen die Daten abgearbeitet werden sollen. Siehe auch replicationBlockDayRange.

TailSync_RelativeDeleteOlderThanDate
(replicationTailSyncRelativeDeleteOlderThanDate)

String

Das relativ anzugebende Löschdatum. Alle Dokumente, die älter sind, werden gelöscht.

Wird diese Option nicht gesetzt, dann werden alle Dokumente gelöscht, die älter als das Startdatum der Replikation sind (siehe replicationStartDate).

TailSync_LoggingEnabled
(replicationTailSyncLoggingEnabled)

boolean

Das relativ anzugebende Löschdatum. Gibt an, ob für diesen Replikationsjob die Tail Sync Durchläufe im bpc-tailsync-log-Index protokolliert werden sollen.

Zusätzlich muss die globale Einstellung replicationJobsTailsyncLogEnabled aktiviert sein.

Consistency Check

Nach den Replikationsläufen wird ein einfacher Konsistenzcheck durchgeführt. Dabei werden die Anzahl Dokumente welche sich in der Quelle und dem Ziel befinden verglichen. Und zwar in dem Zeitraum 'replicationStartDate' und dem letzten Datum welches sich im Ziel (OpenSearch) befindet.

Bei vielen Daten (zig Millionen von Sätzen) kann es zu erhöhter Last auf dem System kommen und eine initiale Replikation extrem verlangsamt werden. Aktivieren Sie den Consistency Check nur, wenn Sie sicher sind, dass die Daten vollständig repliziert werden.

Setting (Key) Datentyp Beschreibung

Setting (Key)	Datentyp	Beschreibung
ConsistencyCheck_Frequency (`replicationConsistencyCheckFrequency`)	Integer	Die Frequenz, mit welcher der Konsistenzcheck durchgeführt wird. Beispiele: `0` = wird nie durchgeführt `1` = wird nach jedem Replikationslauf durchgeführt `10` = wird nach jedem 10ten Replikationslauf durchgeführt

ConsistencyCheck_Frequency
(replicationConsistencyCheckFrequency)

Integer

Die Frequenz, mit welcher der Konsistenzcheck durchgeführt wird.

Beispiele:

0 = wird nie durchgeführt
1 = wird nach jedem Replikationslauf durchgeführt
10 = wird nach jedem 10ten Replikationslauf durchgeführt

Lookup Joins

Können verwendet werden, um zu replizierende Dokumente mit zusätzlichen Daten anzureichern. Wenn z.B. in den zu replizierenden Daten nur eine Partner-ID steht und noch der Name des Partners etc. im Monitor benötigt wird.

Man verwendet unter OpenSearch eine Denormalisierung, das heißt, diese Daten werden mit in das Dokument übernommen und stehen wie alle anderen Daten zur Verfügung (performante Suche; Aggregation, …). Voraussetzung: Die Lookup-"Tabellen" müssen als eigenständige Indexe zur Verfügung stehen und können z.B. über eine zusätzliche Replikation von einer DB-Tabelle übernommen werden.

Die Lookup-Daten können manuell ( BPC-Einstellungen → Übersicht → Status → Replikation → Jobs → Job → Lookup Joins synchronisieren ) sowie automatisch mithilfe unseres OpenSearch BPC Plugin (os-bpc-plugin) aktualisiert werden.

Es können mehrere Lookup-Tabellen referenziert werden, unten werden die möglichen Werte eines EINTRAGs beschrieben. Aufbau: "join": [ { EINTRAG }, { EINTRAG }, … ]

Damit der Wertevergleich funktioniert, müssen die Spaltentypen in den Datenbanktabellen identisch sein. Wenn es sich um String-Felder handelt, sollte "*.raw" als lookupKeyField verwendet werden, bei Zahlfeldern hingegen ohne das ".raw"

Lookup Joins Konfigurationsbeispiel

[
    {
        "keyField": "PARTNER",
        "lookupIndex": "lookup-partner",
        "lookupKeyField": "ID.raw",
        "resultFieldsPrefix": "partner_",
        "resultFieldsExcluded": [ "ID", "LASTUPDATE" ]
    },
    {
        "keyField": "MESSAGETYPE",
        "lookupIndex": "lookup-messagetype",
        "lookupKeyField": "ID.raw",
        "resultFieldsPrefix": "messagetype_",
        "resultFieldsExcluded": [ "ID", "LASTUPDATE" ]
    }
]

Feld	Datentyp	Beschreibung
keyField	String	Das Schlüsselfeld in der zu replizierenden Tabelle. Über den Wert des Feldes werden die Daten aus dem Lookup-Index übernommen. Beispiel: PARTNER_ID Hier steckt die ID des Partners und in dem angegebenen Lookup-Index die eigentlichen Daten des Partners, die übernommen werden sollen. (Hint: DB Foreign Key)
keyFieldValuesSeparator	String	Falls sich in dem keyField mehrere Werte befinden, die durch ein Trennzeichen separiert sind, kann dieses Trennzeichen hier angegeben werden. Der Lookup Join wird dann auf die Einzelwerte durchgeführt. Beispiel: Im 'lookupIndex' sind folgende Daten enthalten: ID = 20, LONGNAME = Gramm ID = 30, LONGNAME = Kilogramm ID = 42, LONGNAME = Zentimeter Wenn der keyFieldValuesSeparator '%%', der resultFieldsPrefix 'MENGENEINHEIT_' und der übergebene keyValue Wert '42%%20%%30' ist, dann wird folgendes Feld erstellt: MENGENENHEIT_LONGNAME = Zentimeter%%Gramm%%Kilogramm
lookupIndex	String	Der OpenSearch Index mit den Lookup-Daten. Beispiel: lookup-partner In dem Beispiel die Detaildaten des Partners.
lookupKeyField	String	Beispiel: ID.raw In diesem Feld wird nach dem Wert des 'keyField' (siehe oben) gesucht. (Hint: DB Primary Key)
resultFieldsPrefix	String	Die zu übernehmenden Felder aus dem Lookup-Index müssen mit einem eindeutigen Prefix versehen werden, sodass es zu keinem Konflikt mit existierenden Feldern kommt. Beispiel: partner_
resultFieldsIncluded	String Array	Sollen nicht alle Felder aus dem Lookup-Index übernommen werden, können die zu übernehmenden Felder hier festgelegt werden. Beispiel: [ "FIRST_NAME", "LAST_NAME" ]
resultFieldsExcluded	String Array	Sollen fast alle Felder übernommen werden, dann können hier die auszuschließenden festgelegt werden. Beispiel: [ "ID", "UPDATED" ]

Feld

Datentyp

Beschreibung

keyField

String

Das Schlüsselfeld in der zu replizierenden Tabelle. Über den Wert des Feldes werden die Daten aus dem Lookup-Index übernommen.

Beispiel: PARTNER_ID
Hier steckt die ID des Partners und in dem angegebenen Lookup-Index die eigentlichen Daten des Partners, die übernommen werden sollen. (Hint: DB Foreign Key)

keyFieldValuesSeparator

String

Falls sich in dem keyField mehrere Werte befinden, die durch ein Trennzeichen separiert sind, kann dieses Trennzeichen hier angegeben werden. Der Lookup Join wird dann auf die Einzelwerte durchgeführt.

Beispiel:

Im 'lookupIndex' sind folgende Daten enthalten:

ID = 20, LONGNAME = Gramm
ID = 30, LONGNAME = Kilogramm
ID = 42, LONGNAME = Zentimeter

Wenn der keyFieldValuesSeparator '%%', der resultFieldsPrefix 'MENGENEINHEIT_' und der übergebene keyValue Wert '42%%20%%30' ist, dann wird folgendes Feld erstellt:

MENGENENHEIT_LONGNAME = Zentimeter%%Gramm%%Kilogramm

lookupIndex

String

Der OpenSearch Index mit den Lookup-Daten.

Beispiel: lookup-partner
In dem Beispiel die Detaildaten des Partners.

lookupKeyField

String

Beispiel: ID.raw
In diesem Feld wird nach dem Wert des 'keyField' (siehe oben) gesucht. (Hint: DB Primary Key)

resultFieldsPrefix

String

Die zu übernehmenden Felder aus dem Lookup-Index müssen mit einem eindeutigen Prefix versehen werden, sodass es zu keinem Konflikt mit existierenden Feldern kommt.

Beispiel: partner_

resultFieldsIncluded

String Array

Sollen nicht alle Felder aus dem Lookup-Index übernommen werden, können die zu übernehmenden Felder hier festgelegt werden.

Beispiel: [ "FIRST_NAME", "LAST_NAME" ]

resultFieldsExcluded

String Array

Sollen fast alle Felder übernommen werden, dann können hier die auszuschließenden festgelegt werden.

Beispiel: [ "ID", "UPDATED" ]

Logging von Replikationen

Die Durchläufe der Replikationsjobs können geloggt und zum Beispiel über den automatisch angelegten Monitor “Replication Jobs Monitor” angezeigt werden. Analog können auch Durchläufe des Tail Syncs protokolliert und im Monitor “Tail Sync Logs Monitor” angesehen werden. Diese Monitore werden beim Start angelegt, wenn sie nicht vorhanden sein sollten. Sie können nicht permanent gelöscht werden. Ebenso werden die verwendeten Indizes bpc-replicationjobs-log und bpc-tailsync-log automatisch angelegt, wenn ein Durchlauf geloggt werden muss.

Das Logging kann global sowie je Replikationsjob an- und ausgeschalten werden (siehe entsprechende Einstellungen oben). Im Auslieferungszustand ist das Logging global sowohl für Replikationen als auch Tail Syncs aktiviert, aber in den einzelnen Replikationsjobs deaktiviert. Daher wird standardmäßig nicht geloggt.

Die Log-Einträge für Replikationsdurchläufe werden im Bulk nach einiger Zeit in den erwähnten Index geschrieben. Das hat wenig Einfluss auf die Gesamtperformance des Systems. Allerdings können sehr viel Einträge in kürzester Zeit erzeugt werden (Millionen in ein paar Stunden), deshalb den Cleanup vielleicht nicht zu selten ausführen und ein Auge auf die Anzahl der darin enthaltenen Dokumente behalten: Einstellungen → Core Services → Indizes

Da Tail Syncs deutlich seltener stattfinden, sollte beim Tail Sync Logging der bpc-tailsync-log-Index nicht so schnell wachsen, trotzdem wird dieser regelmäßig von alten Einträgen bereinigt (siehe Konfiguration oben).

Keywords: