Profildokumente können mit ihrem Caching-Mechanismus tatsächlich ein Problem darstellen. Vermutlich lässt sich das aber in diesem Falle umgehen, weiter unten darüber.
Nachschauen in einem View ist tatsächlich unzweckmässig, da bei der nichthierarchischen Netzwerkstruktur, die Domino schlussendlich bildet, nicht sichergestellt ist, dass alle Dokumente auch tatsächlich immer vorliegen.
Damit es zuverlässig läuft, muss der Prozess - notesuntypisch - an einen bestimmten Server gebunden werden.
Damit gibt es immer noch 2 unterschiedliche Ansätze:
A
Die Nummern werden nur vom Server über einen Agenten vergeben (egal ob periodisch oder angestossen durch neue/geänderte Dokumente). Dadurch ergibt sich zwar eine Verzögerung in der Nummernvergabe, aber es ist relativ einfach sicherzustellen, dass die Nummern sequenziell vergeben werden. In diesem Szenario ist es ziemlich unwesentlich, ob der Zähler in einem normalen Dokument, in einem Profil-Dokument oder direkt aus einer Ansicht ausgelesen werden.
B
Die Nummern werden von Clients vergeben. Dabei dürfen diese nur vergeben werden, wenn der Client direkt auf dem designierten Nummerierungsserver arbeitet. In diesem Fall sollte der Zähler in einem dedizierten normalen Dokument abgelegt werden, hier wirkt sich das Caching-Problem der Profildokumente sonst aus. Hier haben wir dann auch die Situation, dass mehrere Prozesse gleichzeitig Nummern anfordern bzw. vergeben können. Damit ist a) sicherzustellen, dass Nummern nicht doppelt und b) keine Löcher im Käse entstehen. Für beides gibt es Strategien: Wird ein neues Dokument erstellt, wird entweder bis zum Speichern keine Nummer oder nur eine provisorische Nummer vergeben. Nach dem Speichern wird ein Abbrechen/Löschen verboten. Oder, man vergibt die Nummer grundsätzlich erst beim Speichern.
So long
Jens
