Kürzlich hat einer unserer Kunden die Notes-Version von 7.x auf 8.5.3 FP3 aktualisiert, was an sich eine gute Idee ist .
In Folge dessen sind zwei unserer Anwendungen auf die Nase gefallen, da es offenbar mit Notes-Versionen > 8.5.x einen Fehler im PostSave-Event gibt. Da wir in unseren Anwendungen recht selten auf das PostSave-Event überhaupt zurück greifen, ist das auch nicht vorher schon bei anderen Kunden oder Anwendungen aufgefallen.

Das Problem betrifft offenbar NotesDocument-LotusScript-Objekte von Dokumenten, die gerade erst neu angelegt wurden und vor dem PostSave das erste Mal gespeichert wurden. Offenbar ist dieses Objekt zum Zeitpunkt, in dem das PostSave ausgelöst wird, noch nicht vollständig initialisiert, so dass einige Properties oder Funktionen fehlerhafte Werte zurück geben oder gleich Fehler werfen.

Die Reihenfolge ist also folgendermaßen:

1. Das Dokument wird neu erzeugt. Bei der Erzeugung wird im QueryOpen gemäß "unserem" Model-View-Controller-Konzept das Model mitsamt dem Document-Object erzeugt
2. Nach einigen Eingaben wird die Speicherung ausgelöst
3. Im QuerySave wird das Dokument validiert
4. Das Dokument wird (nach erfolgreicher Validierung) gespeichert
5. Im PostSave greifen wird auf Eigenschaften und Funktionen des Document-Objects zu, das wir im QueryOpen erzeugt haben. Dabei passieren die besagten Fehler.

Die folgenden zwei Fehler sind dabei konkret (in jeweils einer anderen Anwendung) aufgetreten, aber es mag natürlich noch mehr geben:

NotesDocument.NoteID gibt den Wert "0"

Wir rufen in einer Anwendung einen Agenten aus dem PostSave heraus auf, weil dieser den Out-of-Office-Agenten (oder Service) aktivieren soll. Beim Aufruf wird die NoteID als Kontext übergeben:

agent.runOnServer(source.document.noteID)
Die NoteID wird dann im Agenten selbst wieder aus dem Kontext ausgelesen:

session.currentAgent.ParameterDocNoteID
Aber - oh weh - die NoteID ist "0", so dass der Agent natürlich mit Fehlermeldung aussteigt. Das hat in früheren Notes-Versionen noch funktioniert, aber war auch mit Notes 9 noch reproduzierbar. Dass es sich hier um nicht beabsichtigtes Verhalten handeln muss, zeigt sich auch daran, dass es einen leicht krummen aber einfachen Workaround gibt. Wir holen uns die NoteID einfach mit Formelsprache:

noteID = Evaluate(|@Right(@NoteID;"NT")|, source.document)
und übergeben diese einfach an den Agenten:

agent.runOnServer(noteID(0))


Nun mag man kein Freund davon sein, Formelsprache mit Evaluate in LotusScript auszuführen, aber zumindest funktioniert es.

Fehler mit NotesDocument.CopyToDatabase

In einer anderen Anwendung werden Dokumente im PostSave (auf Nachfrage hin) in eine Archivdatenbank kopiert. Dazu nutzen wir die Funktion:

NotesDocument.copyToDatabase(NotesDatabase)
Diese Funktion wirft allerdings den Fehler "Invalid or nonexistent document". Wenn man nach dieser Fehlermeldung im Kontext mit copyToDatabase bei Gugl sucht, findet man auch. Allerdings funktioniert der vorgeschlagene Lösungsweg, den Code in das PostSave zu verschieben, eben nicht - oder nicht ohne Weiteres.

Und die Lösung dafür ist ähnlich Facepalm-tauglich, wie die Obige.

Man hole sich die UniqueID des aktuellen Dokumentes und erzeuge sich davon ein neues Notesdocument Objekt, um darauf die Operation auszuführen. Das könnte ungefähr so aussehen:

unid = source.Document.Universalid
Set newDocumentObject = notesDatabase.getDocumentByUNID(unid)
Set archiveDoc = newDocumentObject.CopyToDatabase(archiveDB)


Ich bin nicht begeistert, aber es läuft . Dieses zweite Problem war übrigens mit Notes 9 nicht mehr reproduzierbar.


Ergänzungen zu weiteren Fehlern ähnlicher Natur oder Anregungen zu Lösungsstrategien sind immer herzlichst willkommen .