ich wiederhol mal zur Sicherheit, was ich verstanden habe:
ihr habt eine zentrale DB, in der Docs erstellt werden und
je nach UB entweder
in
DB A, DB B oder DB C
oder
in alle drei gemeinsam
etc.
verteilt werden sollen.
Dabei ist es vorgesehen, daß die verteilten Docs in den jeweiligen Unter-DBs auch editiert werden können.
Eine ähnliche Anforderung hatte ich einmal und hier ein kurze Beschreibung des Lösungswegs:
1. Zentrale stellt in einer zentralen Info-DB Dokumente ein
2. es gibt ca. 8 Bereiche, auf die die Docs in jeweils eigene DBs repliziert werden sollen
3. dabei steuert der zentrale Ersteller, welche Bereiche welche Docs bekommen, indem er im erstellten Doc eingibt: "Bereich1, Bereich4, Bereich5"
4. die Bereichs DBs abeiten auf Basis der selektiven Replikationsformel, die nicht anders lautet als "SELECT @contains(Feld_Bereich;"Bereichxyz")" -
somit bekommt die Bereichs DB des Bereich 1 alle Docs, in denen in einem bestimmten Feld "Bereich1" vorkommt. Alle anderen Docs bleiben außen vor.
5. die einzelnen Bereiche können "ihre" Docs selbständig editieren, indem Sie eine Version des Ursprungsdocs erstellen
6. die Views sind so gesteuert, daß sie entweder das Original anzeigen, oder wenn eine Version erstellt worden ist, nur die Version bzw. das angepasste Doc anzeigen
7. Hierzu habe ich in der Maske des Docs eingestellt "merge replication conflicts"...denn der Editor eines Bereichs, der ein Ursprungsdoc versioniert, muß das Ursprungsdoc so markieren, daß es nicht mehr in den Views angezeigt wird, sondern eben die Version.
Das "markieren" des Urspungsdocs würde aber zu einem Replikationskonflikt führen, wenn der zentrale Ersteller in seiner zentralen DB das Urpsungsdoc erneut anpasst und bei einer folgenden Replikation Top-Down (nur Top-Down, ganz wichtig !!!!) würde die Bereichs DB einen Replikationskonflikt anzeigen, da ein und dasselbe Urpsungsdoc in zwei unterschiedlichen Repliken angefasst worden ist. Die Einstellung "merge replication conflicts" verhindert dies, indem feldweise verglichen wird, wo und wann Änderungen gemacht worden sind. In dem Falle ändert der zentrale Editor das "ich bin versioniert worden" Feld nie, nur der dezentrale Editor. So kann Notes den potenziellem Replikationskonflikt auflösen und eine parallele Bearbeitung eines Docs in mehreren Repliken ist damit machbar. Nun, "merge replication conflicts" ist ja ein allgemeines Konzept dazu und nicht mein eigenes, um das zu betonen. Mehr dazu in der Notes Help.
8. Fasst der zentrale Editor ein Doc an, wird dem Originaldoc eine interne, neue "Nummer" verpasst. Hierbei switche ich immer zwischen dem Wert 0 und 1. Wozu das Ganze? Die dezentralen Editoren benötigen einen Automatismus, der ihnen deutlich macht, welche Originaldocs zentralseitig angepasst wurden, damit evtl. bestehene dezentrale Versionsdocs entsprechend verändert werden müssen (das Originaldoc wird ja wie gesagt nicht mehr in den Views der dezentralen DBs angezeigt und irgendwie müssen ja die dezentralen Leser an die neuen Inhalte seitens der Zentrale drankommen -> ergo muß man das Versionsdocs dezentral anpassen).
Wie wirkt nun dieser "Automatismus"?
In einer internen Adminview der dezentralen DB werden alle Docs in einer hierarchischen Response View aufsteigend nach Änderungsdatum angezeigt. Zuerst kommt das Originaldoc und eingerückt "darunter" das Versionsdoc. Wird ein Originaldoc zentralseitig verändert, rutscht es in dieser View schon mal nach ganz oben, damit der dezentrale Admin leichter den Überblick behält, was dezentral in den einzelnen Versionen anzupassen ist. Der eigentliche Trick aber ist folgender: die Maske der zentralen Form hat nur ein Nummernfeld (Wert 0 oder 1). Die dezentrale Form weicht davon etwas ab: sie hat zwei weitere Felder. Das zweite Feld wird beim dezentralen Versionieren gesetzt und speichert den Wert des ersten Feldes. Somit sind die Felder NUmmer 1 (zentral gesetzt) und Nummer 2 (dezentral gesetzt) zu Beginn gleich = beide zeigen 0 an.
Ändert der zentrale Editor das Doc zentral ab, wird das Feld NUmmer1 auf 1 gesetzt, es wird dann nach unten repliziert und in der Admin-View sieht der dezentrale Editor sofort die Abweichung innerhalb des Originaldocs, daß Nummer1=1 und Nummer2=0 ist. Wird in einer berechneten Spalte angezeigf. Somit weiß er, daß das Originaldoc verändert worden ist und kann nunmehr das dazugehörige Versionsdoc in Agriff nehmen. Beim erneuten Speichern des Versionsdocs wird im Originaldoc das Feld NUmmer2 auf 1 gesetzt. Würde der zentrale Editor das Orginaldoc erneut ändern, bekommt das Feld Nummer1 den Wert 0 wieder und im dezentralen Doc erscheint wieder die Abweichung=> Nummer1= 0 un Nummer2 = 1. Zu beachten ist hierbei, daß keinerlei Replikationskonflikte entstehen, denn Nummer1 wird nur vom zentralen Editor geändert und das Feld Nummer2 immer nur vom dezentralen Editor.
Joooo, puh, ich hoffe, ich habe es einigermaßen deutlich gemacht, wie man es machen könnte. So erreicht man, daß eine zentrale Verteilstelle Docs gezielt in verschiedenen Bereiche in Umlauf geben kann und die Bereiche ihre eigenen "Kommentare" dazu einstellen können, ohne das Replikationskonflikte én masse entstehen.
Also zusammengefasst:
- Verteilung von Infos in dedizierte Repliken über selektive Replikationsformeln
- Merge Replication Conflicts, wenn Docs dezentral geändert werden können sollen UND nur das Versionsdoc nicht aber das Original mehr angezeigt werden soll
- unterschiedliche Masken, eine zentrale und eine dezentrale, um den dezentralen Admins das Leben im Versionschaos zu erleichern
