Domino 9 und frühere Versionen > ND9: Entwicklung

Agent Interaktiv starten von LotusScript aus

(1/3) > >>

Tode:
Ich weiss, dass das, was ich will, nicht geht... Will es aber trotzdem hinbekommen.

Wer nicht viel lesen will, einfach nach dem Zitat weiterlesen...


--- Zitat ---Folgender Hintergrund: Ich habe aktuell einen -sehr umfangreichen- Formelagenten, der zu einer Workflow- Engine gehört. Diesem Formelagenten kann man -per config- sagen, er soll einen anderen Agenten ausführen, bevor er selbst losläuft. Wenn der andere Agent einen "Fehler" wirft (im Moment durch einfache notes.ini- Variable gelöst), dann bricht der Erste ab.

Über @Command( [RunAgent] ; "AndererAgent" ) ist das ja gar kein Problem.

Nun sind umfangreiche Formelagenten leider weder gut zu warten, noch sonderlich gut zu dokumentieren, und webtauglich sind solche Konstrukte schon gleich gar nicht. Deshalb ersetze ich gerade Stück für Stück den Agenten durch eine Script- Library.

Um die bestehende Basis nicht zu gefährden, muss ich auch im Script diese Möglichkeit einbauen. Der gerufene Agent kann aber leider Frontendaktionen (Dialogboxen, Messageboxen, whatever) enthalten. Deshalb komme ich mit einem "NotesAgent.Run" nicht weiter.
--- Ende Zitat ---

Deshalb die Frage: Wie würdet Ihr in LotusScript einen anderen Agenten aufrufen, so dass dieser tatsächlich "Frontend"- Aktionen durchführen kann:

NotesAgent.run scheidet aus, genauso wie Evaluate (keine @Commands in Evaluate)...

Mein Ansatz wäre folgender: Ich mache eine Maske. Diese Maske hat in irgendeinem Event den Formel- Aufruf des Agenten, und geht sofort wieder zu...

Irgendeine Idee (zu meinem Ansatz oder zu einem besseren)?

EDIT: So sieht meine Lösung aktuell aus:

1. Maske mit QueryOpen- Event @Command([RunAgent] ; "Test-Formel" )
2. In der Maske eine Teilmaske mit QueryOpen- Event: Continue = False

Warum eine Teilmaske?

In Formel kann ich kein Continue = False setzen, und wenn ich im PostOpen ein Source.Close reinsetze, dann flackert die Maske ganz kurz auf...

Peter Klett:
Wenn der aufgerufene Agent nicht verändert werden darf, fällt mir auch nicht viel mehr dazu ein. Ob das funktioniert, weiß ich aber nicht.

Ansonsten würde ich das Script des aufgerufenen Agenten auch in die Bibliothek aufnehmen und abhängig von der config mit ausführen. Oder innerhalb der config Scripte definieren, die per Execute ausgeführt werden. Hängt davon ab, wie groß der Eingriff sein darf.

Tode:
Nun: Die Agenten, die aufgerufen werden, sind im Normalfall immer meine eigenen. Insofern kann man das natürlich schon anpassen, dafür habe ich mir auch schon Mechanismen überlegt.
Und in der nächsten Ausbaustufe wird die Config so verändert, dass man keinen Agenten angibt, sondern eben eine Sub / Function in einer Script- Library, die dann per Execute ausgeführt wird (und über eine globale Container- Variable kommuniziert).

Ich versuche meine neuen Versionen der WF- Engine aber immer so zu bauen, dass man einfach das Template aktualisieren kann... Und dazu muss ich quasi eine "Rückwärtskompatible" Möglichkeit einbauen, das zu tun, damit alte Workflow- Configs nach dem Update weiterlaufen, ohne dass man was anpassen muss.
Im zweiten Schritt kann man dann die Agenten / den Code und die Config anpassen, so dass man die "Rückwärtskompatibilität" nicht lange mitzuschleppen braucht...

koehlerbv:
Ich verwende auch Agents, die sowohl scheduled, per RunOnServer oder auch interaktiv laufen können müssen. Die kritischen (UI-)Teile werden per LS Execute ausgeführt, wenn es aus der mitgegebenen (UI-)Bedingung hervorgeht. Der Backend-Agent "sieht" diesen Part daher gar nicht.

Bernhard

Tode:
@Bernhard: Das ist ja nicht die Frage... Es geht darum, diesen "Frontend"- Agenten per LotusScript zu starten... und dafür gibt es ja von IBM keine Möglichkeit...

Navigation

[0] Themen-Index

[#] Nächste Seite