(geheim)Agenten

[StanPete]

Hallo,

mal wieder das leidige Thema Agenten.
Ich habe mir einen kleinen Agenten geschrieben der nach Eingang neuer Mail ein externes Programm via "shell" ausführen soll. (soll im Hintergrund ausgeführt werden)
Der Agent funktionert einwandfrei wenn ich ihn von Hand starte. Aber wenn neue Mails reinkommen reagiert er nicht.

Wenn ich den gleichen Agenten dann als periodisch alle 5 minuten ausführen lassen will , so sagt mir das Agenten Protokoll nach 20 minuten das der Agent noch nie gelaufen ist.

Wo liegt hier das Problem ?
Lassen sich mit Agenten die auf neue Mail reagieren keine externen Programme aufrufen ?

Danke für eure hilfe.


gruß
StanPete

[Axel]

Hi,

der getriggerte Agent läuft auf dem Server und somit versucht die Shell-Funktion das Programm auf dem Server zu starten. Vielleicht hakts da.

Ich bin mir nicht sicher, ob die Shell-Funktion in getriggerten Agenten verwendet werden darf oder nicht. In der Hilfe habe ich nichts gefunden.

Versuch mal an den relevanten Stellen des Agenten Print - Statments, zum Beispiel Print "Hier tut der Agent das und das", einzufügen. Die Meldungen findest du dann in der log.nsf unter "Verschiedene Ergeignisse". So kannst du sehen was der Agent so treibt.

Gibt ihm auch mal ein bisschen länger Zeit. Es kann schon eine Weile dauern bis der Agent reagiert. Das ist auch abhängig wie viel der Server zu tun hat.


Axel

[koehlerbv]

Shell ist eine UI-Statement ...

[Semeaphoros]

Bernhard: Ich glaub Dir das gerne, aber wo hast Du das gefunden? Es würde ja eigentlich Sinn machen. Die Hilfe im Designer gibt eigentlich keinen Hinweis und Shell ist ja nicht eine OO-Methode, sondern ein simples Basic-Statement. Ich würde aus dem hohlen Bauch heraus vermuten, das liegt wohl eher daran, dass das Ausführen von "unrestricted Agents" nicht gestattet ist (Security im Serverdokument).

[koehlerbv]

Woher ich das habe? Hm, zunächst aus dem hohlen Bauch oder besser: Dem Nachvollziehen des "Wozu Shell", dann kurz getestet (und auf dem Server darf ich nun wirklich alles ;-)

Ich lasse mich hier aber gerne eines besseren belehren ;-) Nur: Shell ist wirklich für die UI designed. Allein die Syntax: Shell (program, WINDOWSTYLE) ...

Bernhard

[Semeaphoros]

Uhm, das ist nicht für UI designed, das ist simpel und ergreifend die Syntax des SHELL-Api, und es lassen sich problemlos Batch-Dateien aufrufen, die gar kein UI besitzen, also so ganz einfach ist das nicht.

Das mit dem WinStyle hat damit zu tun, dass intern in Windows jedes Handle ein Window-Handle ist, egal ob sichtbar oder unsichtbar, das sagt also nix aus über UI oder nicht. Ich kann mir durchaus vorstellen, dass ich den Shell ganz gut auf dem Server im Background brauchen könnte .... um irgend eine Batch-Datei anzuwerfen. Mit einem Programm-Dokument im NAB geht das ja auch ...... (womit gleich gesagt ist, dass es über Consolenbefehle auch noch Alternativen zum Shell gäbe, aber da wirds dann schon etwas kompliziert).

[Semeaphoros]

Also, hier kommt die ganze Muschel-Geschichte :-)

Das Kommando ist unter Windows bzw. OS/2 ein reiner Wrapper der Windows-API Funktion "Shell". Daher auch der Windowsstyle Parameter, den ich weiter oben erläutert habe.

Das Ding läuft problemlos auf dem Server.

A-Bär: Es ist sehr heikel in der Anwendung, man sieht das schon an den Anmerkungen in der "Gebrauchsanleitung":

- Using an internal DOS command name generates an error.

- If LotusScript successfully starts program, Shell returns the number 33

*** ziemlich ungewöhnlich, ist aber der reine WinAPI-Returnwert ***

- After Shell starts a program, LotusScript continues to execute the script without waiting to make sure the program has completed. You cannot be sure that a program started by Shell has finished running before the rest of your script is executed.


Das macht den Umgang mit dem Statement recht schwierig, ich spreche da aus Erfahrung, habe ich das doch vor laaanger Zeit mal in Wordmakros ab und an gebraucht. Und ausserhalb davon hab ich mal einen Batch-Prozessor für Windows geschrieben (mit Delphi), der die entsprechende API-Funktion nutzte.


B-Bär:

Sobald man mit Shell etwas macht, wird die Sache sofort plattform-abhängig. Unter dem Abschnitt Unix Plattfrom Differences findet man zum Bleistift:

Shell   Window styles are ignored.

Ok, das ist noch kein Showkiller, aber, wenn ich unter Windows zum Bleisift "MeinProgramm.Bat" aufrufe, werde ich unter Unix/Linux ganz bestimmt nicht dasselbe Programm aufrufen können, sondern werde dort ein eigenes Shell-Script e.g. für Bash schreiben müssen und das dann aufrufen.

Uebrigens, dass Shell unter den Unix-Differenzen aufgeführt wird, zeigt grad auch, dass das Ding auf dem Server läuft, sonst müsste man ja schreiben, läuft nicht.

[Semeaphoros]

Hier noch ein Testbericht:

Folgender James-Bond diente als Test:

Code

Sub Initialize
   Dim retval
   retval=Shell ("cmd")
   Print "cmd "+Str(retval)
   retval = Shell ("calc.exe")
   Print "calc "+Str(retval)
End Sub

Ausführung auf einem Notes 5.0.10 auf OS/2 ergibt folgenden Output:


05.11.2003 22:52:31   AMgr: Agent ('shelltest' in 'debugtest\agenttes.nsf') gibt aus: cmd  33
05.11.2003 22:52:31   AMgr: Agent ('shelltest' in 'debugtest\agenttes.nsf') Fehlermeldung: File not found


Heisst: cmd.exe wird korrekt aufgerufen
calc.exe findet er nicht und bricht ab

So, jetzt muss ich aber schleunigst auf dem Server die vielen Fenster zu machen, die er mir mit CMD aufgemacht hat, sonst zieht es noch ......    

[Semeaphoros]

Und eigentlich würde ich es dann in der Praxis trotzdem anders lösen (jedenfalls hab ich das auch schon gemacht):

Den externen Prozess starte ich entweder mit dem Windoof-Scheduler (AT-Service, der arbeitet zuverlässig) oder wahlweise mit einem Programm-Dokument im Directory. Die Ergebnisse werden in (einem) File(s) abgelegt. Eine gewisse Zeit später wird dann ein Scheduled - 007 gestartet, der dann die vorher erzeugten Files weiter verarbeitet. Mit dem Shell müsste man das ja ähnlich machen, da Script ja nicht bis zum Ausführungsende wartet.

Na, schon wieder ein Thema für ein White-Paper oder so .... :-)

Jens

[StanPete]

Soweit sogut, der Agent läuft und er startet auch externe Programme.
Aber: er startet die Programme nur auf dem Domino Server. Das ist aber nicht in meinem Sinne. Der Agent soll nach Eingang neuer Mail ein Programm auf meinem Client starten. Kann ich den Agenten(nach Eingang Mai) lokal laufen lassen ? Oder muss ich mit periodischen arbeiten ? Die können aber max alle 5 min nach neuen Mails schauen oder ?

@semeaphoros
Wie würdest du es in der Praxis anders lösen ?


Vielleicht mal zum verständniss:
Ich habe vor bestimmte Werte aus den ankommenden Mails(Absender, Datum, Thema) als Parameter an eine EXE datei zu übergeben, die mir dann den entsprechenden Text vorliest, und ihn dann in bestimmte felder des Externen Programms einträgt, und auf dem Bildschirmdarstellt.

[Semeaphoros]

Also, wenn Du von Anfang an gesagt hättest, was Du willst und dass der Agent unbedingt lokal laufen sollte, hättest Du schneller relevante Antworten bekommen.

After new Mail arrives läuft per Definition nur auf dem Server.

Mein Ansatz geht natürlich in dem Falle, dass der Prozess von einem Notes-Ereignis ausgeht, nicht. Normalerweise sind das Batch-Prozesse, die diese Funktionalitäten brauchen und nutzen, da sieht die Sache anders aus als ein von einem Notes-Ereignis angestossener interaktiver Prozess, den Du hier hast - aber wie gesagt, hättest Du von Anfang an die Randbedingungen angegeben, hätten wir nicht noch lange an irrelevanten Infos rumstudiert.

Im Moment hab ich da aber auch keine alternative Idee, insbesondere wenn die Sache ohne User-Interaktion ausgelöst werden soll. Vermutlich müsste man da in die Bookmark.nsf rein oder sogar via API ein Add-In verwenden.

[StanPete]

erstmal danke soweit, ich denke jetzt werd ich mich selbst durchwühlen. Irgendeinen weg wird es schon geben auch wenn es sich der Aufruf ein paar minuten verzögert.

Gut das ich nicht von Anfang an alle Informationen abgegeben haben    sonst hätte ich nicht soviele für mich nützliche hinweise zu dem Thema bekommen  


Danke
Gruß
StanPete

[Semeaphoros]

Stimmt, es hat immer alles seine zwei Seiten ......