Domino 9 und frühere Versionen > ND8: Entwicklung

ExcelExport als Background Thread / Agent

<< < (3/3)

booltrue:

Wie gesagt, mit RunOnServer kann ich den Agent ja nicht starten, da kommt eine Fehlermeldung.
Starten des Agent geht nur mit Run.

Der Button, der den Agent ausführt, ruft diesen nur auf
Set agent = db.GetAgent("test")
Call agent.RunOnServer

Der Rest passiert im Agent selber.
Habe wie gesagt nur die Exportfunktion,
die vorher der Button ausgeführt hat, in den Agent kopiert.

Es wird der ganze View exportiert, aktuell ~5000 Zeilen.
Die Routine ist schon ziemlich schnell, jedoch blockiert der Client für ~5 bis 10s

Beim Exportieren von selektierten Dokumenten hatte ich Probleme,
da im View Multivalues angezeigt werden, aber nicht in einem Feld,
sondern verteilt auf mehrere Zeilen.

eknori (retired):
Das da „eine Fehlermeldung „ kommt, ist doch logisch, oder? Wenn auf dem Server kein Excel installiert ist, dann rennt der Code gegen die Wand, wenn Excel angesprochen wird.
Mitdem Java Code brauchst du aber kein Excel mehr. Kannst es sogar auf Linux laufen lassen.

PromITheus:
Ich fasse mal die 3 Ansätze zusammen. Du könntest...

1. Das Ganze über Java laufen lassen

2. Es über Excel auf dem Server laufen lassen
Dafür muss Excel auf dem Server installiert sein. Außerdem musst du sicherstellen, dass der Server die markierten Dokumente(oder View) übermittelt bekommt.
Der Server muss den Pfad für die Ablage der Datei kennen und auch Zugriff darauf haben.

3. Du lässt es weiter beim Benutzer laufen (da 5-10 Sekunden zumutbar sind)
Beim Benutzer "verschönern" z.B.:
- Excel beim Benutzer ausblenden mit "objxl.visible = False"
- Über die Statuszeile den aktuellen Stand des Exports ausgeben, per "Print Starte Excel , Print Exportiere Dokument 1..."
- Meldungsfenster vorschalten."Export starten? Kann 10 Sekunden dauern..."

Peter Klett:
Zu 1. (falls das auf dem Server laufen soll) und 2.:

Die Wartezeit bleibt erhalten, da das Script auf die Beendigung des Agenten auf dem Server wartet - hatte ich weiter oben schon mal erwähnt (vielleicht gibt es bei Java eine Möglichkeit, das parallel laufen zu lassen, weiß ich aber nicht, nicht mein Gebiet).

Bei 5-10 Sekunden ist die Frage, wieviel schneller das auf dem Server läuft. Vielleicht gehst Du dann runter auf 4-8 Sekunden. Wow, da lohnt sich der Aufwand ...

Tode:
Also mich wundert, dass bisher niemand die offensichtliche Lösung genannt hat: ich löse sowas immer mit üblicherweise 3 Agenten.

Der erste Agent hat nur 2 Zeilen Formelsprache:


--- Code: ---@Command([RunAgent] ; "Agent2" );
@Command([RunAgent] ; "LongRunningBackgroundAgent" );
--- Ende Code ---

Im Agent2 werden die ganzen Vorbereitungen gemacht (reagieren auf Selektionen, User- Abfragen, z.B. Dateiname festlegen, etc). Die Informationen schreibt der Agent dann in ein "JobDokument".
LongRunningBackgroundAgent hat die Eigenschaft "im Client Hintergrundthread laufen" aktiviert und öffnet das JobDokument und arbeitet die ab. Der User muss nicht auf den Agenten warten, weil der aufrufende Agent 1 sofort terminiert, nachdem er die zweite Zeile Code abgearbeitet hat. Die Laufzeit des Hintergundagenten sieht man dann am Laufband unten Rechts im Client...

Die übergabe des JobDokuments kann man entweder über einen Notes.ini- Eintrag mit dessen UNID machen oder indem man ein Dokument pro User / Aktion erstellt, das dann in einer Ansicht gesucht werden kann...

Natürlich kann man hierbei dann nicht auf das Ende des Agenten reagieren, aber das könnte man mit einem LotusScript- Timer in einer offenen Maske machen, der z.B. prüft, ob die Ausgabedatei fertig ist.

Etwas komplizierter das Ganze, aber funktioniert zuverlässig.


ABER: Wenn das generieren einer Excel- Datei aus Notes- Daten so lange dauert, dass es dem User zu lange geht, dann ist was mit dem Code falsch. Ich habe hier Excel- Export- Code, der 20.000 Dokumente innerhalb weniger Sekunden verarbeitet...

Navigation

[0] Themen-Index

[*] Vorherige Sete