Agent Interaktiv starten von LotusScript aus

[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...

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.

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...

[koehlerbv]

Mir ging es auch um den Ansatz: Muss es denn überhaupt ein Agent sein?

Bernhard

[Tode]

Lass uns das am Freitag mal diskutieren... Wie ich bereits sagte: Es geht mir um die "sanfte" Migration von Umgebungen, die schon heute Agenten einsetzen, ohne dass man bei allen die Agenten neu schreiben oder die Konfig anpassen muss...

[pram]

Vor dem selben Problem standen wir auch mal.
Wir gingen auch den Weg über eine Maske. Die Maske wurde dabei über ein Konfigurationsdokument geöffnet. Im Dokument steht der Agentname und eine kurze Beschreibung, was der Agent macht. (Die Maske selber enthält eine zentrierte Tabelle mit dem Text "Aktion wird ausgeführt: ...." und wird im Hintergrund solange angezeigt, solange der Agent läuft.... Dann flackert auch nichts )

Der Agent selber wird im QueryClose ausgeführt mittels

Code

@Command([ToolsRunMacro];AgentName);

Die Maske wird mit

Code

tmpDoc.agentName="MeinAgent"
tmpDoc.Beschreibung="Blabla"
ws.Editdocument(False,tmpDoc).close(true)

geöffnet und sofort wieder geschlossen.

Gruß
Roland

[Tode]

Da der Agent bei mir im Kontext des aktuellen uidocs ausgeführt wird, muss ich das ins Queryopen packen, weil sonst habe ich den falschen Kontext für den Agenten. Aber ich werde es jetzt auch so umsetzen.

[koehlerbv]

Mag sein, dass das die Lösung ist, aber warte doch bitte noch bis Freitag 

Bernhard

[Tode]

Kleines Update für alle interessierten: Ich bin beim untersuchen einer anderen Frage gerade über folgende Tatsache gestolpert:

Wenn man einen Agent über NotesAgent.Run in einer LOKALEN Datenbank startet, dann ist -entgegen jeder Dokumentation- Interaktion mit dem Agenten möglich.
Der Agent reagiert dann genau, als wäre er mit @Command( [RunAgent] ; "Agent" ) gestartet, kann also auch ws.Prompt und ähnliches.

Startet man den selben Agent in einer Server- Replik der selben Datenbank, bekommt man den Fehler Error #217, Error creating product object

Das hilft nicht wirklich bei der Beantwortung meiner Frage, denn ich kann ja nicht jedesmal, wenn ich einen Agenten aufrufen will, eine lokale Replik / Kopie erstellen, aber interessant ist es allemal. Das ganze funktioniert zurück bis R7 (weiter zurück haben Bernhard und ich nicht getestet)