Schreib den Agenten so, daß er diese vom Agenten geänderten Dokumente ignoriert
oder setze beim ersten Lauf einfach ein Feld, dass Du immer abprüfst. Wenn es nicht vorhanden ist, soll er das Dokument verarbeiten ansonsten soll er es überspringen.
Nun, dieses "Feld" (Du meinst sicherlich ein Item, denn was nützt hier ein Frontelement in einer Maske?) halte ich *so* für keine gute Idee. Was passiert, wenn das Dokument erneut im Frontend geändert wurde und eine neue Verarbeitung ansteht (hierzu hat sich allerdings "Darth Domino" noch gar nicht ausgelassen ...)?
Eigentlich vorgesehen ist hierfür ja die Kombination von NotesDatabase.UnprocessedDocuments und NotesSession.UpdateProcessedDoc. Unter Umständen verhindert dies sogar, dass der Agent, der auf "new / modified documents" anspringt, dies eben nicht tut. Leider muss es aber eben heissen: "Unter Umständen"... Eine Chance geben würde ich dem aber (ohne Kenntnisse der genauen Umstände kann man da auch nicht mehr empfehlen).
Ansonsten bleibt die "harte Methode": Es wird verzeichnet, wer wann zuletzt an dem Dokument war. Der Agent merkt sich zudem seine letzte Laufzeit (als cutoff date). Darüber kann man dann bestimmen, ob ein geändertes Dokument erneut angefasst werden muss - oder ob es zuletzt vom Agent bearbeitet wurde.
HTH,
Bernhard
Du hast mein Posting nicht richtig gelesen ...
Sach ma, wie wäre es wenn du simpel und einfach in der "Document Selection" ein Kriterium angibst, das neue Dokumente nicht haben? Ich mein, wo bitte ist denn jetzt dein Problem?? :-?
Un ach ja: ein simpler Blick in die KB hätte Artikel 1084411 zu Tage gefördert. Damit ist dein Problem gelöst. :roll:
Das sollte aber kein Problem sein. Per default ist der "UpdateTasks" in den Mailboxen auch aktiv und der AMgr trampelt nachts durch sämtliche DBs. Der OOA teils -je nach Umgebung- sogar wesentlich häufig auf der selben Anzahl an DBs oder sogar noch um Größenordnungen mehr. Da in deinem Fall der AMgr auch ratz-fatz wieder fertig ist, macht das nichts. Oder sollte nichts machen. Wenn doch, wäre eine größere Büchse sinnvoll.
Dein Problem ist schon klar. Aber die Folgerungen, die du daraus ziehst ... da machst du dir unnütze Gedanken...
Und wenn du nun eine Umgebung hast, die das nicht verkraftet und keine größere Büchse bekommst, dann takte den Agenten halt anders, Problem gelöst!
ZitatDein Problem ist schon klar.
Puh... ich dachte schon mich versteht keiner... *seufz* 
ZitatAber die Folgerungen, die du daraus ziehst ... da machst du dir unnütze Gedanken...
Ja, gut... dann müssen wir damit leben und die Sache weiter beobachten.
Mir fehlt immer noch eine Aussage, ob in Deiner Konstellation NotesSession.UpdateProcessedDoc den AMgr zügelt ...
Bernhard
Zitat
koehlerbv schrieb:
Mir fehlt immer noch eine Aussage, ob in Deiner Konstellation NotesSession.UpdateProcessedDoc den AMgr zügelt ...
Bernhard
Du, das kann nicht klappen. Die Hilfe [url=http://www-12.lotus.com/ldd/doc/domino_notes/7.0/help7_designer.nsf/855dc7fcfd5fec9a85256b870069c0ab/b1da6754d2f1a0468525704a0040a426?OpenDocument&Highlight=0,unprocesseddocuments]sagt unzweideutig[/url], dass der Trigger zwangsläufig all die Dokumente beinhaltet, die er selbst anlegt oder modifiziert.
Fällt mir gerade auf: damit kann man doch wunderbar Endlosschleifen bauen und den gesamten Server plätten. Etwas unglücklich ist das aber schon :-?
Ergo: in der Konstellation kann man ausschließlich mit der Document Selection den Agenten im Zaume halten.
Womit wir wieder gaaaanz am Anfang bei taurecs, spätestens aber muertes Vorschlag wären. Welch vergeudete Zeit...
Wo Du das unzweideutig siehst, musst Du mir aber mal aufmalen, RockWilder:
ZitatAll new & modified documents - Not been processed by this agent with UpdateProcessedDoc
und
ZitatFor agents that run on new and modified documents, newly received mail documents, pasted documents, or newly modified documents, you must use the UpdateProcessedDoc method in NotesSession to mark each document as "processed," which ensures that a document gets processed by the agent only once (unless it's modified, mailed, or pasted again).
Da man aber ab und an - wenn auch nur selten - Pferde kotzen sieht, und das dann sogar vor der Apotheke: Ich habe es schon erlebt, dass UpdateProcessedDoc nicht (immer) das getan hat, was es sollte. Und man kann sicher sein, dass ich das sauber überprüft habe.
Wie auch immer: Der AMgr bekommt auf jeden Fall mitgeteilt, dass - wie auch immer - ein Dokument als "neu / modifiziert" in den internen Tables registriert wurde und wird also mehr oder weniger zucken. Dieses Zucken wird sich aber im Bereich von Millisekunden bewegen - dafür werden die notwendigen Informationen ja auch in internen, meist gecachten Tables gehalten. Und Collection.Count = 0 ist da schnellstens festgestellt.
Bernhard
Zitat
koehlerbv schrieb:
Wo Du das unzweideutig siehst, musst Du mir aber mal aufmalen, RockWilder:
Zitat
unless it's modified, mailed, or pasted [size=xx-large]again[/size]
Und das "again" ist der ausschlaggebende Punkt. Wir haben einen Agenten, der Dokumente erzeugt. Wird dieses nicht sofort, also noch vor dem Save als "Processed" markiert (geht das überhaupt?), läuft der Agent los.
Nehmen wir an, wir erzeugen Dokumente (unterstellen wir mal, das mit dem markieren vor dem speichern würde klappen) und ein anderer Agent setzt ein Feld um: Reminder, Status, was weiß ich (erwähnter "UpdateTasks"-Agent), ist dieses Dokument wieder unverarbeitet. Und hier kommt das von oben zum Tragen: kann ich ein Dokument ändern und vor dem Speichern als verarbeitet markieren?
Hab grad kein Notes zur Hand, um das zu testen. Aber der Logik nach würde ich sagen: kann man nicht, da ein Dokument erst dann ein "fertiges" Dokument ist, wenn es gespeichert wurde. Denn bis dahin liegt ja höchstens ein alter Stand im Backend vor. Wird ein komplett neues Dokument erzeugt, ist ja vor dem Speichern gar keines da, was markiert werden kann.
Ergo: dieser Trigger ist ausschließlich dann zu gebrauchen, wenn sichergestellt ist, dass Dokumente nur einmal angefasst werden. Nachteil: des nächtens läuft der Fixup los, findet korrupte Inhalte vor und versucht zu reparieren. Schon trampelt wieder der Agent los. Keine Theorie, hatten wir schon. Die User waren arg verwundert, warum sie Jahre alte Dokumente neu absegnen durften. Wohlgemerkt in einer Umgebung, wo der Kunde explizit kein TL wünschte! Ob ein -J allerdings geholfen hätte, könnte ich nur raten...
Darth Domino (schade, dass Du keinen "richtigen" Namen nennst): Nein, da hilft Dir auch die API nicht weiter.
RockWilder: Ich habe in etlichen Applikationen (vorsichtig ausgedrückt) derartige Agenten am Rennen. Es kommt auf den Kontext an, ob man diese verwenden kann. Darunter sind etliche, wo mir die Admins den Hintern bis zum Stehkragen aufreissen würden, wenn dieser Agenttyp zu messbaren Performanceeinbussen führen würde. Und ich habe Anwendungsfälle, wo dieser Agenttyp nicht einsetzbar ist.
Ein UpdateProcessedDoc mit anschliessendem Save lässt in der Regel dem AgentManager gar keine Zeit, anzuspringen. Wenn doch, läuft er ins Leere (kommt aber auch auf den Kontext an).
Was die Abfolge / Laufzeit / Performance angeht, wird es mit immer mehr Datenbanken sogar immer "besser" - es verstreicht mehr Zeit, bis er für die entsprechende DB überhaupt anspringen kann.
Bernhard
