Kann ein Agent ein grade bearbeitetes Dokument erkennen?

[Daniel S.]

Hallo!

Vielleicht hat einer von Euch eine Idee, wie ich folgendes Problem lösen kann:

Ich habe einen Agenten, der in Dokumenten regelmäßig Einträge vornimmt. Wenn nun aber jemand grade ein Dokument bearbeitet, sollte der Agent dieses überspringen, damit keine Konflikte entstehen.

Ich habe bereits versucht, document locking zu aktivieren, damit bekomme ich aber beim Erstellen neuer Dokumente immer Konflikte (ich speichere und öffne das Dokument zwischendurch, um RT-Felder zu aktualisieren, vermutlich macht das Probleme).

Meine nächste Idee war, im QueryOpen ein Feld zu schreiben und das Dokument zu speichern, und dann im QueryClose auch wieder, und dieses durch den Agenten auszuwerten. Allerdings erhalte ich dann auch wieder einen Konflikt.

Kann ich in meinem Agent irgendwie erkennen, ob ein Dokument grade bearbeitet wird?

[koehlerbv]

Was verstehst Du denn unter "grade bearbeiten"? Was ist dann "krumm bearbeiten"? 

Aber Spass beiseite: Ich gehe davon aus, dass Dein Agent im Backend läuft. Da wirst Du dann keine Chance haben, um zu ermitteln, ob jemand ein Dok gerade im FrontEnd bearbeitet. Das Locking ist eine FrontEnd-Aktion, NotesDocument.IsUIDocOpen gilt nur für den Client, und wenn Du ein Flag durch den Agent setzt und speicherst, machst Du alles u.U. noch viel schlimmer (und alle Docs gelten anschliessend als neu - da freuen sich diejenigen, die lokale Repliken haben).
Und wenn Du dann noch mehrere Server hast ...

Ich würde hier als allererstes das Konzept der Applikation auf den Prüfstand stellen: Ist es wirklich erforderlich, dass ein Agent tagsüber in der DB herumfuhrwerkt? Es könnte durchaus sein, dass ein anderes Konzept Dein Problem eher löst.

By the way: Wenn Dein Client beim Öffnen ein Flag setzt und beim Speichern wieder entfernt, darf es eigentlich nur in sehr seltenen Fällen Konflikte geben - zumindest nicht durch den Agent auf dem Server.

Bernhard

[Daniel S.]

Bei der Applikation geht es um die Erfassung von Meeting-Protokollen, aus denen anschließend TODOs erstellt werden. Der Status dieser TODOs soll später wiederum ins Protokoll übertragen werden. Da das Ganze möglichst zeitnah, also kann der Agent nicht nur einmal nachts laufen.

Mein ursprüngliches Konzept sah vor, ein Protokoll in einzelne Punkte aufzuteilen, jeweils als ein eigenes Dokument, aber trotz der Vorteile, die das meiner Meinung nach mit sich bringt, war den Usern (bzw. dem User, der das entscheidet, auch wenn ich bezweifle, dass er seine Protokolle selbst schreibt  ) zu aufwendig, jedesmal einmal mehr zu klicken. Das hätte zumindest die Chance gesenkt, das User und Agent gleichzeitig ein Dokument bearbeiten.

Ich könnte vielleicht noch die Zuordnung, welcher Protokollpunkt sich in welchem TODO niedergeschlagen hat, in eigene Dokumente legen, aber um erledigte TODOs auf's Protokoll zu übertragen müsste ich trotzdem noch durch den Agenten schreiben.

Ich hatte zunächst das Problem, dass ich zwar im QueryOpen bzw. QueryModeChange ein Flag setzen und im Backend-Dokument speichern konnte, aber wenn ich versucht habe, im QueryClose das Flag wieder zu entfernen und dort zu speichern, hat allein das schon einen Konflikt produziert.

Ich habe es jetzt erstmal so gebaut, dass ich ein Flag setze, wenn das Dokument bearbeitet werden soll, und der User kann das Dokument nur schließen, wenn er auch speichert, damit das Flag wieder korrekt entfernt wird (in der Aktion).

Was ich vielleicht hätte versuchen können ist, beim Öffnen des Dokuments ein anderes Dokument zu erstellen, in dem ich den Status festhalte und im Agenten nur Protokolle zu bearbeiten, zu denen kein entsprechendes Status-Dokument vorhanden ist. Das könnte vielleicht funktionieren, oder?

[gossifu]

Hallo,

wenn Du das Dokument hast, dann frag mit
_{doc.IsUIDocOpen}
ab.
Zummindest gibt es Auskunft, ob es im Frontendzugriff ist.

mfg

Kjeld

[koehlerbv]

Das funktioniert aber nicht für einen Agent, der auf dem Server läuft, Kjeld.

Bernhard

[gossifu]

Tja, überlesen hab ichs nicht, steht nicht in der Hilfe. Aber danke für den Tipp.

mfg

Kjeld

[koehlerbv]

Naja, woher sollte der Server auch wissen, was ein entfernter Client mit den Daten macht, die der Server geliefert hat?

Bernhard