Domino 9 und frühere Versionen > Entwicklung

Agenten asynchron starten (mittels Lotusscript)

<< < (2/5) > >>

DerRalph:
Noch etwas zur Semantik, wie von Bernhard gewünscht:
Die Agenten sind Teil eines selbstgebastelten Reporting-Systems.
Jeder Agent 1, 2, ... N kann beliebig viele Reports jeweils einer Reportart
generieren und an anfragende Anwender schicken.

Natürlich können alle diese Reportagenten zeitgesteuert gestartet werden.
Sie prüfen, ob etwas zu tun ist, und wenn ja, tun sie etwas,
und wenn nein, beenden sie sich direkt wieder.

Ich hatte gedacht, daß es "eleganter" und insgesamt handlicher ist,
einen übergeordneten Steuerungsagenten ("Agent A") zu schreiben,
der die Reportagenten nur bei Bedarf startet.

Es kann theoretisch sein, daß ein Reportagent länger als die
ihm vom System zur Verfügung gestellte Zeit laufen kann
(Systemeinstellung: 20 Minuten).
Das würde wegen der synchronen Verbandelung wahrscheinlich auch den
Steuerungsagenten betreffen. Der würde vom System wegen der insgesamt
langen Laufzeit gleich mitbeendet werden, so daß die Prüfung auf Start der
anderen Reportagenten anwendungsbedingt sich mindestens bis zum nächsten
Start des Steuerungsagenten verzögern würde.
(Meine Kenntnisse von Interna des Domino-Systems sind leider sehr gering.)

Also: meine Idee taugt nichts bzw. ist nicht leicht umzusetzen.

Die Äußerung "Da das Problem nicht ohne ist ..." (Bernhard)
läßt kaum Hoffnung auf eine einfache Lösung keimen.

Da es bekanntlich viele Wege nach Rom gibt (siehe Lösung von Axel, Danke!),
werde ich mein Konzept wohl umstellen müssen.

animate:
Ich weiß zu wenig über diese Anwendung, aber ich sehe nicht, was an einem Steueragent elegant oder handlich ist.
Du würdest Logik (muss ich was tun oder nicht?), die IMHO in die einzelnen Agents gehört in diesen Steueragent verlegen. Das bedeutet auch, immer wenn du einen neuen Reportagent erstellst musst du Änderungen an einem bereits getesteten Modul (der Steueragent) machen und läufst so Gefahr, dass das die ganze Reportsteuerung lahmlegt. Außerdem würde der Steueragent vermutlich pro neuem Report größer, unhandlicher und komplexer (-> schwierige Wartung).

Oder sehe ich das falsch?

flaite:
Ich seh das auch wie Thomas.
Ausserdem:
Warum stellst du nicht einfach die Reportanforderungen in eine Queue (als Dokumente) und lässt zeitlich gesteuerte Agenten diese Anforderungen verarbeiten (Report generieren) und in einen anderen Status setzen, um etwa Reports in einer bestimmten Reihenfolge zu generieren. Das letzteres Sinn macht halte ich allerdings für sehr unwahrscheinlich. Wenn du z.B. 3 Reports brauchst, kannst du auch einfach 3 Reportanforderungen generieren.
In der Reportanforderungen stehen dann so Daten drin wie: Welches Dokument soll verarbeitet werden (UniqueID), welcher Report, etc. .
Ich würde die Reportanforderung als eigenes Dokument betrachten. Du könntest das auch direkt in das zu reportierende Dokument als Feld schreiben. Die Lösung, die Anforderung in einen eigenen Dokumenttyp zu packen macht aber Sinn z.B. zur Verhinderung von Speicher & Replizierkonflikten, weil der Reportagent muss ja irgendwann das Anforderungsdokument speichern (um es zu einem Status zu setzen, aus dem folgt, dass es nicht noch einmal verarbeitet wird).


Mit zeitgesteuerten Agenten hat Domino eigentlich ein Mittel zur asynchronen Verarbeitung. Und es ist dokumentenorientiert. Bestimmte typische Merkmale des SOA Zeugs gibts also schon in Domino. Wobei das natürlich nicht dasselbe ist.  ;D

Übergeordneter Steuerelement heisst ja, dass du eine Komponente schaffst, die den anderen sagt, was zu tun ist. Du brauchst das hier nicht. Die Reportagenten kannst du mit sehr geringen Aufwand so schlau programmieren, dass sie wissen was zu tun ist. Gegen die Queue pollen und bei Bedarf einen Report erzeugen.

DerRalph:
Für Thomas Völk:

Was soll ich auf die Frage "Oder sehe ich das falsch?" antworten
bzw. ist das noch nötig nach dieser Programmierlehrstunde für einen "Frischling"?

Mir scheint, du hast die eigentliche Frage aus den Augen verloren.

Bei meiner Suche für ein Konzept für die skizzierte Teilaufgabe des Reporting-Systems
bin ich auf die Frage gestoßen, ob ein Agent einen anderen Agenten asynchron anstoßen kann.
Die "gestandenen" Notes-Entwickler in meiner Umgebung waren ratlos.
Die Frage halte *ich* für nachforschenswert und interessant auch für andere.
Kann ja sein, daß es nicht geht, nachfragen darf man aber.

Leider habe ich mich verleiten lassen, die Frage aus dem Abstrakten
in eine konkrete Anwendung zu stellen.
Ob die Realisierung letztendlich diesen Weg beschreiten wird, wer weiß.
Wie bereits geschrieben: es gibt viele Wege nach Rom.
Entwickeln ist eine kreative Arbeit.

Nun zu meiner Antwort:
"Ich weiß zu wenig über diese Anwendung, ..." ... eben!


P.S.:
Bitte nicht ärgern!
Ich halte deinen Beitrag für deplaziert.

Um keine endlose Diskussion führen zu müssen ...
Meinen Ärger habe ich runtergeschluckt. Ok?!

P.S.-2:
Nachdem auch ein Beitrag von "kennwort" zum Them "Reportsystem" eingegangen ist,
erst einmal Danke (und das ohne Ironie!) für die Zeit und die Gedanken,
die ihr zur Beantwortung investiert.
Ich glaube aber, ich sollte einen neuen Beitrag "Reportsystem" öffnen,
in dem das Thema diskutiert werden kann.
Ich klinke mich aber aus.

Um eine Grundlage zu schaffen:
An ca. 70 Standorten sitzen mehrere hundert Anwender, die per Notes-Client
verschiedene (parametrisierbare) Reportarten anfordern können.
Die Datengrundlage der Reports ist eine zentrale Oracle-Datenbank mit
einem komplexen DB-Schema, verwaltet von einer anderen Anwendung.
Die Reports sollen wahlweise als pdf-Datei oder Word-Datei erstellt werden.
Das Aussehen der Reports sollte kundentauglich sein.
Und alles soll so schnell wie möglich ablaufen.

Ich bin mit meinem Konzept für das Gesamtsystem recht zufrieden,
möchte allerdings die Abholseite noch "elegant" ;-) gestalten.

Bye.

flaite:
Ich mag Leute, die zu Wutausbrüchen neigen. Ich tue es selber, manchmal.
Es ist völlig normal, dass man mal ein paar Basics aus den Augen verliert. Deshalb ist Thomas und mein Beitrag völlig normal. Ein Entwickler/Designer/Architekt, der bei seinen Gedankengängen alle Basics immer richtig im Auge behält, gibt es nicht. Das genau ist nämlich das Problem, aus meiner Sicht.
Ich mache nicht gerade selten Design-Fehler und muß deshalb weite Teile umprogrammieren. Der Grund ist *immer*, dass ich ein paar Basics nicht beachtet habe.
Ob du *jetzt* mit deinem Konzept für das Gesamtsystem zufrieden bist, ist schön für dich. Entscheidend ist aber, ob es eine gute Basis für realen Code ist. Ich hoffe für das Team, dass du dann ein bischen offener auf sachliche Kritik reagierst. Genau das unterscheidet nämlich ein gutes Team von einem schlechten Team. Ich habe noch kein Design Konzept gesehen, in dem keine schwerwiegenden Fehler oder Lücken drin waren. Inklusive der, bei denen ich mitgeschrieben habe.

Eine Sache, die mir eigentlich erst in meinem Go-Hobby so richtig klargeworden ist:
Kageyama (cooler Autor) sagt das die Qualität bei Top-Weltliga-Professionals darin besteht, dass sie die Basics sehr, sehr sicher beherrschen. Nicht perfekt. Weil das geht nicht. Und ich sehe genau das in jedem Spiel. Und es läßt sich prima auf IT übertragen. 

btw: Warum benutzt ihr nicht sowas wie Jasper-Reports, macht das ganze auf Tomcat oder einem appServer und kommuniziert gegen das ganze über Webservices. Am besten noch verbunden mit einem Messaging Server? (just curious)

peace Axel

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete