Das mit dem Code ist nicht so einfach, da dieser ziemlich umfangreich ist und ich habe es noch nicht geschafft, das Problem auf einen einfachten Testfall runter zu brechen.
Der Algorithmus ist jedenfalls wie Folgt:
Es gibt 2 Ansichten, eine Lookup-Ansicht und eine zur Anzeige.
- Die Lookup-Ansicht enthält alle Dokumente mit Form="Memo" und Status="" (bei denen kein Fehler aufgetreten sind, s.u)
- Für jedes doc rufe ich die Methode "process(doc)" auf.
- Liefert "process" einen Fehlercode so wird ein Flag im Dokument gesetzt (Status="Fehler"), damit es aus der Lookup-Ansicht heraus fällt.
Die Anzeige-Ansicht hingegen zeigt alle Memos an, also auch fehlerhafte
Die Methode "process" macht im Wesentlichen folgendes:
- es werden mehrere Definitionsdokumente gesucht, auf denen die Mail "passt". Wenn eines gefunden wird, dann wird die Mail ein Antwortdokument zu dem Definitionsdokument.
-es wird die Form geändert. (das darf man doch normalerweise ) - Dok wird gespeichert (*1)
Das Problem ist nun, dass in der Anzeige-Ansicht vereinzelt noch Dokumente angezeigt werden, die eigentlich nicht mehr da sein sollten weil sie eine Form <> "Memo" haben. In der Property box sehe ich auch diese Form. Leider ist das Verhalten ziemlich nichtdeterministisch.
- Ich habe mir einen Testagenten geschrieben, der mir ein vernünftiges setup erzeugt, damit ich immer die gleichen Ausgangsbedingungen habe. (Es werden ~30 identische Mail-In Dokumente erzeugt.)
- in der Anzeigeansicht werden diese 30 Dokumente angezeigt
- Anschließend läuft der Mailin-Import Agent (Algoritmus von oben)
- Nach dem Lauf sollte die Ansicht leer sein, ist sie aber meist nicht
- Der Effekt tritt scheinbar auch nur dann auf, wenn die Ansicht im Client offen ist, während am Server der Agent läuft
- Die Anzahl der "Geisterdokumente" variiert sogar von Lauf zu Lauf
*1) - Baue ich eine simple "Delay" schleife (for x = 1 to 10000) vor dem Speichern des Doks ein, erhöht sich die Wahrscheinlichkeit, das Dokumente "hängen" bleiben.
Meine Vermutung ist, dass die Anzeige-View es nicht mit bekommt, dass sich von dem Dokument die Form geändert hat und deshalb ein partielles Update des Indexes erforderlich wäre.
Schuld ist vielleicht "Optimize document table map":
This feature has not changed for the past few releases of Lotus Notes/Domino. This feature is designed to speed up view indexing for applications with structures that resemble the Domino Directory. (In other words, they contain many documents that use one form and a small number of documents using a different form. Think of Person documents versus Server documents in the Domino Directory.)
The idea is that, instead of checking every document note to see whether or not it should be included in a view index, we make two passes. The first pass merely checks to see if the correct form name is associated with that document. The second pass, if needed, checks for the various other conditions that must be met to include this document note in the view index.
Scheinbar rechnet Notes nicht damit, dass sich von einem Dokument die Form ändert.
Ich hab noch ein paar Workaround-Ideen für morgen in diese Richtung...
Gruß
Roland