Wie man Löschkonflikte erzeugt...

[joan]

Hallo zusammen,

Ich hatte gerade ein seltsames Problem und wollte mal meine Erfahrungen dazu mitteilen, weil ich denke, daß das nicht alltäglich ist. Die Situation ist folgende:

Wir betreiben ein CRM System mit Kundendaten und haben diesem System eine weitere Applikation zur Seite gestellt, die wesentlich schlanker und auf den Betrieb in einem Customer Service Center ausgelegt ist. Nun müssen natürlich Änderungen im CRM System an die neue Applikation übertragen werden, was ein nächtlicher Agent übernimmt.

Dieser Agent geht alle Dokumente durch und prüft per Hash-Value, ob es Änderungen gegeben hat. Die Kundendokumente der Zieldatenbank werden bei Änderungen auf Basis einer konfigurierten Feldliste aktualisiert, weil im ZIelsystem nur ein Bruchteil der Informationen benötigt wird.

Bei Antwortdokumenten, die am Kunden hängen, habe ich mir den Aufwand gespart und prüfe nur das Änderungsdatum. Ist das unterschiedlich, wird das Dokument in der Zieldatenbank einfach gelöscht und das geänderte hineinkopiert.

Das funktionierte auch prima. Bis jemand auf die Idee kam, daß man vom Zielsystem ja eine Replik auf einem anderen Server anlegen könnte. Ab diesem Moment warf die Applikation mit Replizierkonflikten nur so um sich, obwohl in der Zieldatenbank nie Dokumente geändert oder gespeichert wurden - weder von Anwenderseite, noch von Agenten oder anderen Applikationen. Das konnte also weder der klassiche Replizier- noch ein Speicherkonflikt sein.

Ein Vergleich der Erstellt/Hinzugefügt Daten brachte überhaupt kein einheitliches Bild - kein einziges der Dokumente schien in einer der beiden Datenbanken erzeugt worden zu sein. Mal schien der Konflikt in der Zieldatenbank mal in deren Replik entstanden zu sein. Nach einigen manuellen Debug Versuchen stellte sich aber heraus, daß die Konflikte erst in der Replik entstehen.

Das Problem lag letztendlich im Löschen und Neuanlegen der Antwortdokumente. Wenn das Dokument gelöscht wird, erzeugt Notes dafür einen Deletion Stub. Der enthält die UNID des gelöschten Dokuments und der Replizierpartner weiß dadurch, welches Dokument gelöscht werden muß. Dummerweise wurde das zu löschende Dokument aber mit der exakt gleichen UNID als geändertes Dokument wieder in die Datenbank hineinkopiert. Solange sich das auf einem Server abspielt, passiert da gar nichts. Durch die Replikation aber bekam der Zielserver die Aufgabe das Dokument mit der UNID XXX zu löschen und gleichzeitig neu anzulegen und das führte dann zu den "Löschkonflikten".

Nur falls einer den gleichen Fehler nochmal machen will...

[m3]

Und noch ein Nachtrag zum Thema "Löschen & neu anlegen":
Best Practice Makes Perfect: Processing Lots of Documents - Must You?

[Peter Klett]

Löschen und neu Anlegen ist eine der Todsünden, die man in Notes machen kann. Wenn Du Dir die Abgleichroutine sparen willst, welche Felder geändert, gelöscht oder hinzugefügt wurden, kannst Du auch von dem Dokument alle Items löschen und dann neu reinschreiben. Mit einer Schleife über AllItems ist das aber i.d.R. kein großer Akt.

Aber niemals ein Dokument löschen um es neu anzulegen!

[joan]

Vielen Dank für die Hinweise, man lernt halt nie aus... Den Best Practice Artikel werde ich mir unters Kopfkissen legen.

Mittlerweile ist das umgebaut und zwar so wie Peter das beschrieben hat. Ich mußte nur ein wenig Zusatzaufwand treiben, weil bestimmte Dokumenttypen Querverlinkungen enthalten (Serienbriefe, die ein gemeinsames Template über die UNID referenzieren).