Aktualisieren einer Ansicht im Backend

[MadMetzger]

Hallo,

ich brüte gerade über einer Problematik in meiner Datenbank für Geldbestellungen, zu der ich hier schonmal ein paar Fragen hatte. Die sind ja auch alle zu meiner Zufriedenheit gelöst worden, nur stehe ich vor einem neuen Problem:

Die Überprüfung, ob jetzt alle bestellt haben, lasse ich zur Zeit im QueryClose des Doks per Serveragent ausführen (Filialen sehen nur eigene Bestellungen) durchführen. Dabei ist es so, dass bei der letzten Bestellung beim ersten Schließen des Dokuments die Vollständigkeit noch nicht erkannt wird. Sollte aber auch kein Wunder sein, da das Dokument direkt danach auch noch nicht in der betroffenen Ansicht erscheint (von hier aus erstellt man die Bestellung). Nach einem Ansichtswechsel hin und wieder zurück und erneutem Öffnen wird alles richtig verarbeitet. Dies habe ich versucht zu umgehen, indem ich nach dem Speichern im PostSave des Doks ein Notesview.Refresh auf die Ansicht gebe, was aber leider keinen Erfolg bringt.

Wie kann ich das Problem lösen, bzw. was für Alternativen gibt es zu meiner Vorgehensweise?

[koehlerbv]

So, wie ich das sehe (kenne Deinen Code ja nicht), müsste das NotesView.Refresh zu Beginn des Agent-Codes stehen und nicht im Code, der noch vom Client ausgeführt wird.

Bernhard

[MadMetzger]

Also, wenn ich dich jetzt richtig verstanden habe, muss die View im Code des Agenten refreshed werden, richtig? Also ist das aktualisieren im Dokument vollkommen überflüssig?

Kann es nur jetzt gerade nicht testen, werde ich aber gleich morgen machen.

[koehlerbv]

Jo, die Sachen laufen ja asynchron, entscheidend ist aber der Agent, in dem er auf eine "wiedererfrischte" Ansicht angewiesen ist.
Auf jeden Fall sollten wir uns auf den Agent konzentrieren.

Ich hoffe, dass das morgen gleich bei Dir funktioniert.

Bernhard

[MadMetzger]

Ist ja eigentlich auch logisch, das Aktualisieren muss ja noch nicht abgeschlossen sein, wenn der Agent anfängt zu laufen... hoffe auch mal, dass es auf Anhieb klappt! Aber schonmal Danke für den Tipp!

[koehlerbv]

Gern geschehen, Markus (alter Pyromane  ).

Auf jeden Fall ist die Erledigung des ViewRefreshs die saubere Lösung. Ich bin schon gespannt, was Du morgen zu vermelden hast (sonst müssen wir an ganz anderer Stelle suchen - aber weiterhin im Agent).

Bernhard

[flaite]

Jo, die Sachen laufen ja asynchron,

Sorry for nitpicking, aber das läuft imho von der Sicht des Entwicklers gerade nicht asynchron sondern synchron ab.
Sobald Notes auf view.refresh trifft, wartet die Runtime erstmal bis die gesamte View refreshed ist bevor die nächste Zeile verarbeitet wird.
Asynchron wäre, wenn er nicht warten würde.
Asynchron = 2 unabhängige Prozesse/Treads, die möglicherweise miteinander kommunizieren können.
Synchron = Eins nach dem anderen.

Asynchron bietet eine Menge von Möglichkeiten, aber auch bonus-Komplexiät für den Entwickler.

Axel

[koehlerbv]

Axel, es sind zwei Maschinen, die da werkeln. Und jede cached (logischerweise).

Warten wir mal morgen ab - ich könnte mir vorstellen, dass da noch ganz andere Effekte eine Rolle spielen.

Bernhard

[MadMetzger]

Leider hat das nichts geholfen... mir kam gestern abend noch eine Idee, woran es liegen könnte: Ich habe die Überprüfung in eine Klasse ausgelagert, die auch alles andere im Zusammenhang mit den offenen Bestellungen steuert, und greife dort auf eine eigene Instanz der gleichen Ansicht zu. Könnte es vielleicht helfen, wenn ich der Klasse beibringe, ihre Instanz der Ansicht zu aktualisieren? Oder habt ihr noch weitere Ideen, bzw. was für Infos bräuchtet ihr noch!

[MadMetzger]

Auch das Aktualisieren der Ansicht aus der Instanz der Kontrollklasse heraus hat noch nicht den erwünschten Effekt gebracht... 

Wenn jemand noch Vorschläge oder Alternativen hat, nur raus damit... 

[flaite]

Kann es sein, dass in Maskenevents das update der View erst nach dme Queryclose stattfindet?
Wenn du von aussen (etwa in einem Agenten) auf Ansichten und docs zugrefst ist view.refresh sehr zuverlässig und v.a. synchron. D.h. das Skript ist solange blockiert, bis der Anischtenindex neu aufgebaut ist.
 

[MadMetzger]

Das Aktualisieren der Ansichten wird im QueryClose von einem Agenten gestartet, der per Agent.runOnServer angeschubst wird. 

Oder sollte ich den Agenten vielleicht mal von einem View Event aus losrennen lassen? 

[MadMetzger]

Auch das Starten des Agenten aus dem ViewEvent heraus hat es nicht gebracht.

Wo kann ich noch schauen, bzw. wo liegen Fehlerquellen? Oder braucht ihr mehr Details? 

[koehlerbv]

Ich kann das leider nicht nachvollziehen: Wenn ich eine saubere Ansicht (im BackEnd) brauche, tut NotesView.Refresh genau das, was es soll.

Vielleicht kannst Du einen Workaround für Deine spezifische Umgebung (wer weiss, welcher Nebeneffekt da hineinspielt ...) bauen und in ein spezielles Dokument die bisherigen Bestellungen schreiben ? Du kannst ja dafür in dem Dokument (Replizierkonflikte mischen !) jeweils eigene Items verwenden, die nur von den jeweiligen Filialen beschrieben werden.

Aber - irgendwo muss der Hase ja im Pfeffer liegen. Fragen kann ich leider keine stellen wegen mehr Details: Mir fehlt der komplette Zusammenhang.

Bernhard

[MadMetzger]

Kann es irgendwie mit Leserfeldern zusammenhängen? Muss der Agent irgendwie besonders signiert sein? Das muss doch irgendwie klappen...

[koehlerbv]

Mit Leserfeldern kann es selbstverständlich zusammenhängen. Der Agent, der die Collection prüfen will und vorher die View refreshed, muss natürlich so signiert sein, dass er alle Rechte hat, um von Leserfeldern unbeeindruckt zu sein (d.h., er muss in allen Dokumenten auch in den Leserfeldern stehen).

Bernhard

[MadMetzger]

Also ich habe den Agenten mit der Server-ID signiert, der Server ist mit einer Rolle Admin in den Dokumenten als Leser eingetragen. Bin ich mit der Rolle in der DB unterwegs und triggere den Agent, dann funkt es auch... Werde morgen aber nochmal die Leserfelder und ACL-Einstellungen checken. Irgendwo muss es ja haken...

[koehlerbv]

Kannst Du nicht auch auf dem Server einen Agent laufen lassen, der bei neuen / modifizierten Dokumenten anspringt ? Dann wärest Du doch den ganzen Trödel mit RunOnServer los. Der ausführende User muss doch nicht wissen, ob er nun der letzte ist, oder ?

Bernhard

[MadMetzger]

*Ping* Da hast du natürlich vollkommen recht... es kommt da nicht drauf an, ob es der letzte User auslöst, nur dass es danach dann relativ zeitnah ausgelöst wird, damit der Hauptkassierer, der die Bestellungen bearbeitet, dieses dann schon frühzeitig kann... das probiere ich dann morgen nochmal! Danke für den guten Tipp, Bernhard...

[koehlerbv]

Sehr gern geschehen. "Relativ" zeitnah passiert das auf jeden Fall (sowie es auf dem ausführenden Server ankommt, aber das ist ja auch sowieso das Problem, wenn man x Servers hat) - sowie die Server-Task Prozessorzeit für den Amgr abzweigt, rammelt der Agent los. Insofern: Wie bei RunOnServer.

Ich bin gespannt, wie das nun bei Dir ausgeht. Sag' an, wenn Du Hilfe brauchst.

Bernhard