Domino-Replikation ohne gemeinsame Replica-ID

Nicht jede Synchronisation ist klassische Replikation

Domino-Replikation basiert auf dem Konzept, dass Datenbanken echte Repliken voneinander sind. Genau das macht sie so leistungsfähig — begrenzt aber auch ihren Einsatz, wenn Datenbanken bewusst unabhängig voneinander bleiben sollen.

Typische Beispiele sind Migrationsdatenbanken, Archivdatenbanken, Reporting-Datenbanken, kundenspezifische Zielanwendungen oder neu entwickelte Domino-Anwendungen, die weiterhin ausgewählte Daten aus einer älteren NSF erhalten sollen.

• unterschiedliche Replica-IDs
• unterschiedliche Datenbankdesigns
• unterschiedliche Feldstrukturen
• unterschiedliche fachliche Zwecke
• selektive Übertragung statt vollständiger Datenbankreplikation
• wiederholbare Synchronisation statt einmaliger Kopierläufe

Wo Synchronisation ohne gemeinsame Replica-ID relevant wird

Eine solche kontrollierte Synchronisation ist besonders dann sinnvoll, wenn Domino-Datenbanken Daten austauschen müssen, aber nicht zu klassischen Repliken voneinander werden sollen.

Wo Copy-Agents und Export-/Import-Routinen schwierig werden

Natürlich gibt es auch andere Wege, Daten zu bewegen: LotusScript-Agents, Java-Agents, Export-/Import-Prozesse, Kopierroutinen oder kundenspezifische Migrationsskripte. Diese Ansätze können funktionieren, werden aber häufig schwierig, sobald die Anforderungen über eine einfache einmalige Kopie hinausgehen.

Kontrollierte Synchronisation mit der Domino API-Engine

Die Domino API-Engine kann Dokumente zwischen Domino-Datenbanken synchronisieren, auch wenn diese Datenbanken keine klassischen Repliken voneinander sind. Die Synchronisation kann über Notes-kompatible Auswahlformeln, Rechte und Verarbeitungsflags gesteuert werden.

Ziel ist nicht, die klassische Domino-Replikation dort zu ersetzen, wo sie das richtige Werkzeug ist. Ziel ist es, diejenigen Fälle abzudecken, in denen Domino-Datenbanken Daten austauschen müssen, aber keine Repliken sind — und der Prozess selektiv, transparent und kontrollierbar bleiben muss.

• Migration von einer alten NSF-Struktur in eine neue Domino-Anwendung
• selektive Synchronisation in Archiv- oder Reporting-Datenbanken
• Übertragung nur bestimmter Masken, Kategorien oder fachlicher Zustände
• Synchronisation von Domino-Datenbanken mit unterschiedlichen Replica-IDs
• kontrollierte Datenverteilung zwischen verwandten, aber unabhängigen Anwendungen
• eine Master-Datenbank und mehrere unabhängige Satellitendatenbanken
• Nachvollziehbarkeit durch Ergebnis- und Fehlerstatistiken

Selektive Synchronisation zwischen unabhängigen NSF-Datenbanken

Das folgende vereinfachte Beispiel zeigt das Grundprinzip. Das konkrete Skript hängt von den Datenbankpfaden, der Auswahlformel, den Rechten und den benötigten Verarbeitungsflags ab. Abhängig von den konfigurierten Rechten je Datenbank kann die Synchronisation Erstellungen, Aktualisierungen und Löschungen in beide Richtungen umfassen.

SrcDBh := @OpenDB("apps\\source.nsf");
DstDBh := @OpenDB("apps\\target.nsf");

SelectionFormula := "Form = \"Customer\" & Status = \"Active\"";

/* Beispiel: Replikationsrechte definieren */
Rights := @BitVektor(1:2:3:4):@BitVektor(1:2:3:4);

/* Selektive Synchronisation zwischen unabhängigen Domino-Datenbanken */
Result := @ReplicateWithFormula(
    SrcDBh;
    DstDBh;
    SelectionFormula;
    Rights
);

@LogReport(Result);

SrcDBh := @CloseDB(SrcDBh);
DstDBh := @CloseDB(DstDBh);

Dies ist kein Ersatz für ein vollständiges Projektskript. In realen Szenarien würde das Skript normalerweise Logging, Fehlerbehandlung, Konfigurationsdokumente, Formeln je Richtung, Ergebnisstatistiken und projektspezifische Verarbeitungsregeln enthalten.

Komplexere Replikationsszenarien

Das obige Beispiel zeigt ein vergleichsweise einfaches Synchronisationsszenario. In realen Domino-Projekten sind die Anforderungen an Replikation und Synchronisation häufig deutlich komplexer.

Manche Datenbanken müssen Dokumente synchronisieren, ohne dass bestimmte lokale Felder überschrieben werden. Andere Szenarien erfordern formelbasierte Auswahl in Kombination mit Feldschutz oder eine kontrollierte Ersetzungslogik für Dokumente, die gezielt in eine andere Struktur übertragen werden sollen.

• @ReplicateWithFieldProtection für Synchronisationen, bei denen ausgewählte Felder in einer Datenbank lokal bleiben müssen
• @ReplicateWithFormulaWithFieldProtection für formelgesteuerte Synchronisation mit geschützten Feldgruppen
• @PushAndReplace für kontrollierte Push-and-Replace-Szenarien
• projektspezifische Replikationslogik als individueller Engine-Task oder Custom-@Function

Enthaltenes Evaluierungsbeispiel

Start des enthaltenen Replikationsbeispiels

Das Evaluation-Paket enthält ein Beispielskript und passende Domino-Testdatenbanken für dieses Replikationsszenario. Laden Sie zum Ausführen des Beispiels das Evaluation-Paket herunter und installieren Sie die Engine wie im enthaltenen README-File beschrieben.

• Laden Sie das Domino API-Engine Evaluation-Paket herunter und entpacken Sie es.
• Installieren und konfigurieren Sie die Engine wie im README-File beschrieben.
• Legen Sie die enthaltenen Beispiel-Datenbanken im Verzeichnis TEST unterhalb des Domino-Server-Data-Roots ab.
• Werden die Datenbanken an einem anderen Ort abgelegt, muss das Beispielskript entsprechend angepasst werden.
• Prüfen und passen Sie bei Bedarf die ACLs der Datenbanken an.
• Öffnen Sie die Engine-Control-Datenbank.
• Wählen Sie in der Ansicht 4. Scripts\by Category das Event-Dokument für das Script REPLICATE_WITH_FORMULA aus.
• Klicken Sie anschließend auf den Action-Button Start again.

Dadurch wird das Beispiel-Replizier-Skript einmalig gestartet. Das Beispiel ist für eine kontrollierte Evaluierungs- oder Testumgebung vorgesehen und sollte nicht gegen produktive Datenbanken ausgeführt werden.