Autorenfeld per Server-Agent setzen

[Blackraven]

Hallo zusammen,

ich möchte per Server-Agenten das Autorenfeld für ein Dokument setzen lassen.
D.h. genauer: im Queryclose eines Dokumentes startet der Benutzer (selbst zu diesem Zeitpunkt im Autorenfeld eingetragen) einen Agenten "SetAuthor" per "runonServer", das zu änderne Dokument wird per Dok-ID mitgegeben
Der Agent hat im "Run behalf of"-Feld den entsprechenden Signer der Domäne stehen.
Der Agent ändert dann das Autorenfeld und trägt einen anderen Benutzer dort ein.

Funktionieren tut das, aber ich hab trotzdem ein paar Fragen/Unsicherheiten im "Gepäck".

Nun meine Fragen dazu:
a) Was passiert wenn mehrere Benutzer mehrere Dokumente mittels des "einen" Agenten ändern wollen. Kann der Agent in mehreren Instanzen laufen? Arbeitet der AMGR das entsprechend ab?
b) Ich hab die Beobachtung gemacht, dass der AMGR gar keine Meldung über den Start des Agenten in die LOG.nsf macht, ist das korrekt?
c) ich habe eine "Print" in den Agenten eingetragen, aber auch das wird nicht in der LOG.nsf des Servers protokolliert. Ist das korrekt, bzw. wie kann ich überprüfen ob der Agent gelaufen ist?

d) generell: hab ich nen Denkfehler bei meiner Vorgehensweise?

Vielen Dank schon mal im Voraus

Blacky

[m3]

Du willst Dir noch das Thema Document Locking ansehen (Clustering, ....).

[koehlerbv]

Warum machst Du das überhaupt in einem Agenten, wenn der ausführende User doch Autor ist?

Bernhard

[WildVirus]

N'Abend,

Print bzw. MsgBox bei Agenten ist was für einen lokalen (!) Testserver (man sieht es auf der Console), aber nicht für Produktion.

Kennst Du schon Noteslog ? Das nehme ich für alle Agenten, egal ob periodisch oder Frontend.

CU,
Axel

[Blackraven]

Danke schon mal für eure Hinweise.

@m3: Document logging ist ausgeschaltet, hab auch keinen Clusterpartner

@koehlerbv: ist so ne Art Workflow, ich möchte den derzeitigen Autor aus dem Autorenfeld löschen, und dafür im neuen Schritt nen anderen Benutzer ins Autor-Feld einfügen

@Wildvirus: prinzipiell brauch ich den "Print"-Befehl im Agenten nicht, ich hab mich nur gewundert, dass auch in der normalen "log.nsf" des Servers, wo sonst der Start "aller" Agenten über den AMGR mit Eintrag stehen, bei "meinem" Agenten dort nichts zu finden ist.

[Peter Klett]

@koehlerbv: ist so ne Art Workflow, ich möchte den derzeitigen Autor aus dem Autorenfeld löschen, und dafür im neuen Schritt nen anderen Benutzer ins Autor-Feld einfügen

Das ist keine Begründung, weshalb Du nicht beim Speichern (oder auch später im Queryclose) die Aktion nicht von dem aktiven Benutzer ausführen lassen kannst.

Vergiss das mit dem Agenten!

Der aktuelle Benutzer, der das Dokument im Workflow weitergibt, hat Autorenrechte auf das Dokument, also kann er es bearbeiten. Wenn dieser Benutzer das Autorenfeld ändert, kann er das Dokument trotzdem einmal speichern, da er derzeit der Autor ist. Nachdem das Dokument gespeichert wurde, kann er es nicht mehr, weil er dann nicht mehr Autor auf dem (gespeicherten) Dokument ist.

Wenn Du das Dokument im Queryclose speicherst, achte darauf, dass Du nicht ein SaveOption = "0" speicherst, weil Du das evtl. vorher gesetzt hast, um das Dokument nach einem Workflow-Button zwingend zu schließen (eine Falle, in die ich schon mal gelaufen bin).

Bau das so, das funktioniert 100 %ig, mit dem Agenten wirst Du niemals froh!

[Blackraven]

@Peter: Danke, ich habs jetzt so gemacht wie du vorgeschlagen hast, und vorher ein Saveoptions="1" sicherheitshalber einfügt ;-)
Funzt 

[koehlerbv]

Du hast SaveOptions = "1" gesetzt und dann im Backend gespeichert?? Das wäre jetzt aber überhaupt gar keine gute Idee! Bist Du Dir im Klaren, was das bedeutet?

Bernhard

[Peter Klett]

Call doc.RemoveItem ("SaveOptions")

halte ich für die bessere Lösung, falls Du nicht generell mit dem Feld ein Verhalten steuern willst

[koehlerbv]

Peter, ich halte das für überflüssig, da SaveOptions ja eh nur im Frontend wirkt. Warum sollte man das also dann im Backend wieder entfernen müssen? Sowas setzt man doch nur, wenn das Dokument eigentlich nicht (SaveOptions = "0") im Frontend gespeichert werden soll.

Bernhard

[Peter Klett]

Wenn Du im Queryclose das Dokument im Backend speicherst, und Du vorher im Prozess ein SaveOptions = "0" eingetragen hast, um das Dokument ohne irgendwelche Zwischenrufe sauber schließen zu können, hast Du das SaveOptions mitgespeichert. Dann (und nur dann) sollte man das SaveOptions vor dem Speichern löschen.

Warum speichern im Backend? Wenn Du einen Workflow hast (mit COSMOS hatten wir solche netten Spielchen), gibst Du das Dokument mittels Schaltfläche in die nächste Stufe. Es berechnen sich alle möglichen Dinge, wie Leser, Verteiler, nächster Bearbeiter, nächste Stufe und und und. Das Dokument hat dann einen Zustand, in dem es evtl. nicht mehr im Frontend gespeichert werden kann (weil z.B. in der nächsten Stufe zwingend eine Eingabe in ein Feld erwartet wird). Trotzdem will man ja die geänderten Einstellungen speichern. Also erfolgt das im Backend. Ablauf grob skizziert:

Button drücken
Speichern im Frontend
-> erfolglos? -> Valdierung negativ, Ende des Prozesses
-> erfolgreich? Validierung positiv
Dokument für die nächste Stufe vorbereiten
Dokument im Backend speichern
SaveOptions = "0"
Dokument schließen

Und dann kommt noch irgendeine "Sauerei" hinterher, die im Queryclose das Dokument nochmal speichern muss (wir hatten das bei Dateianhängen, die wir nicht einfach über Richtextitems bearbeitbar hatten (das gab es so unter R4 noch nicht), sondern die wurden über separate Schaltflächen gelöst, gestartet und mussten natürlich wieder an das Dokument ran). Da das SaveOptions = "0" mitgespeichert, war das Dokument nicht mehr änderbar.

Also Speichern im Queryclose so

Prüfen auf SaveOptions, wenn vorhanden, merken, Feld löschen, Dokument speichern, Feld wieder reinsetzen (falls danach noch eine andere Teilmaske ähnliches treibt).

Das nur mal ein kleiner Einblick in sechs Jahre hochinteressante Entwicklung. War schon ein geiles Teil (und ist es immer noch ... )