Domino 9 und frühere Versionen > ND7: Entwicklung
Bug - Agent execution time?
Demian:
@Bernhard
--- Zitat ---Design - Libs -Masken -User - Massendatenveränderung .... Bahnhof!
--- Ende Zitat ---
das hab ich mir gedacht :)
--- Zitat ---Ich kann mir nicht vorstellen, dass Dein Thema jetzt mit der Verteilung von Designelementen im Zusammenhang mit Änderungen von Daten in anderen Datenbanken basierend auf Datenänderungen in einer initiierenden Datenbank zu tun hat.
--- Ende Zitat ---
irgendwie ja schon. Wollte halt darauf hinaus, dass es 2 Agenten sind, die für alle Datenbanken gelten und deswegen global liegen. Bzw. euch etwas näher bringen wie das Ganze aufgebaut ist.
--- Zitat ---- Was ist das auslösende Ereignis?
--- Ende Zitat ---
Im Endeffekt die Funktion _TempDocCreated in jeder Maskenlib.
--- Zitat ---- Was soll dann geändert werden?
--- Ende Zitat ---
Das einzige Problem was sich bisher ergeben hat, war dass der Agent abgwürgt wurde. Ansonsten läuft das Ganze stabil und sicher. Jede Änderung wird/wurde sofort weiterverarbeitet. Um den Aufwand so gering wie möglich zu halten, am Besten nur den Agent "vor Eingang neuer Mail".
--- Zitat ---Wo soll das geändert werden?
--- Ende Zitat ---
Wo, wäre in Bezug auf den Agenten das Extra-Template um alle anderen betroffenen Designelemente nicht anfassen zu müssen.
--- Zitat ---Ich habe Deine Datenbanken ja gesehen (und bin damals auch durchgestiegen), aber jetzt verstehe ich - wie gesagt - nur noch Bahnhof.
--- Ende Zitat ---
Mir fällt es immer etwas schwer das in Worten wiederzugeben was ich mir dabei gedacht hab und wenn wird es meistens ein Roman.
--- Zitat ---Ich ich helfe gerne weiter!
--- Ende Zitat ---
Das weiß ich und bin dir auch sehr dankbar dafür. Hast mir ja schon mehr wie einmal Hilfestellung gegeben. ;)
@Peter
--- Zitat ---Warum bildest Du nicht alles in einem zentralen Agenten ab?
--- Ende Zitat ---
Habe ich im Prinzip ja, bzw. 2. Einen zum Schicken der Änderung einen zum Verarbeiten.
--- Zitat ---Verstanden habe ich folgendes:
Es gibt einen zentralen Agenten in einer zentralen Datenbank.
--- Ende Zitat ---
Nicht dass wir aneinander vorbei reden. Der Agent ist schon in jede Datenbank kopiert mit Gestaltungsänderungen aktualisieren aktiviert. So dass halt Änderungen am Agent nur an einer Stelle erfolgen.
--- Zitat ---Dieser Agent erhält Aufträge, aufgrund derer er Mails an die betroffenen Datenbanken sendet.
--- Ende Zitat ---
das wäre der 1. Agent der von _TempDocCreated aufgerufen wird und lediglich die Mails verschickt.
--- Zitat ---In diesen betroffenen Datenbanken ist wiederum ein Agent, der die vom vorigen Agenten erstellten Aufträge abarbeitet.
--- Ende Zitat ---
das wäre der 2. Agent
--- Zitat ---Du hast also für jede Datenbank einschließlich der zentralen einen Agenten
--- Ende Zitat ---
das meinte ich mit aneinander vorbei reden. Es sind 2 Agenten, die in alle betroffenen Templates kopiert werden.
--- Zitat ---Spätestens dann, wenn Du mehr Datenbanken hast, als zeitgleich Agenten laufen dürfen, bekommst Du einen Stau
--- Ende Zitat ---
Der Gefahr ist man doch unabhängig von meinem jetzigen Problem eh ausgesetzt?
--- Zitat ---Da der erste Agent 1. weiß, an welche Datenbanken er welche Änderungen versenden soll, und 2. alle Routinen in der zentralen Datenbank vorliegen hat, die er zum Bearbeiten der Dokumente in den Datenbanken benötigt, könnte er die Änderung doch gleich selbst ausführen.
--- Ende Zitat ---
So wie es im Moment ist, müsste der User dann entsprechend wieder warten.
--- Zitat ---Du bräuchtest dazu Deine Routinen vermutlich nur so anzupassen, dass die Änderungen nicht in der CurrentDatabase durchgeführt werden, sondern definierbar ist, welche Datenbank die Grundlage des Handelns ist.
--- Ende Zitat ---
so habe ich es im Prinzip ja. Die Änderungen können unter Umständen auch die aktuelle DB betreffen, in der Regel aber andere.
--- Zitat ---Nur durch eine Umstellung des Konzeptes werden doch die Anzahl der durchzuführenden Änderungen nicht mehr.
--- Ende Zitat ---
Die Anzahl der Änderungen nicht an sich nicht, nur die Anzahl der Änderungen die der Agent dann verarbeiten muss. Und das könnte unter Umständen ausarten.
--- Zitat ---In Deinem Beispiel muss Frankfurt auf jeden Fall zweimal geändert werden, ob zweimal durch einen Agentenlauf oder jeweils einmal bei zwei Agentenläufen.
--- Ende Zitat ---
vom Gefühl her hätte ich halt gesagt, es ist besser der Agent läuft 2x mal hintereinander kurz, als einmal lang. Oder spielt das in der Tat keine Rolle?
--- Zitat ---Falls Du dann noch befürchtest, dass der Agent durch die zu lange Laufzeit vom AMgr abgewürgt wird, beende ihn gezielt selbst.
--- Ende Zitat ---
Das wäre auch eine Option. Wobei dann die Zeitspanne von der Änderung bis zur Verarbeitung ja wieder steigt.
--- Zitat ---Und ich habe alles zentral in dieser einen Datenbank, auch wenn die Anzahl der betroffenen Datenbanken sich seit Beginn deutlich erhöht hat.
--- Ende Zitat ---
Das ist ja mein Ziel. Solch elementare Sachen in einem zentralen Template zu pflegen. Bei neuen Templates wird der Kram reinkopiert und künftige Gestaltungsänderungen übernommen.
Ich schieb mal die 2 Agenten und eine von den libs in ne leere Datenbank und lade sie hoch. Ist dann wahrscheinlich einfacher nachzuvollziehen.
Demian:
Um den Aufwand der Umstellung so gering wie möglich zu halten, habe ich mir mit euren Hinweisen jetzt folgendes überlegt:
Es wird nur der Agent mit dem Trigger vor Eingang neuer Mail insofern geändert, dass alle Änderungsfunktionen in einen separaten Agenten ausgelagert werden die Mail gespeichert und mittels .SendConsoleCommand der ausgelagerte Agent gestartet wird. Dieser würde dann in einer Ansicht der gespeicherten Mails mit .GetFirstDocument nur das 1. Dokument aus der Ansicht holen, verarbeiten und löschen. Man hat dann zwar auch das Verzögerungsproblem, aber es muss nicht sehr viel geändert werden.
Was mich dabei nur vor ein Problem stellt, von .SendConsoleCommand kommt ein "Command has been executed on remote server. Use 'Live' console option, in future, to view response from server." zurück.
Ist das normal? Hatte irgendwie mit einer anderen Rückgabe gerechnet, als dem Hinweis, dass ich doch die Live-Console benutzen soll....Gelaufen ist der per Tell Amgr run aufgerufene Agent aber wunderbar.
Ist das mit der Rückmeldung irgendeine Einstellungssache? Aufziehen würde ich das so eigentlich, nur wenn ich wenigstens ein "akzeptiert" oder "nicht akzeptiert" von .SendConsolecommand zurückkriegen würde.
Tode:
SendConsoleCommand liefert nur für sehr wenige Befehle den direkten Output zurück. Die meisten Befehle werden asynchron ausgeführt, und da bekommst Du als return value halt nur den von Dir angegebenen Text. das ist normal und kann auch nicht geändert werden.
HTH
Tode
koehlerbv:
Das ist (wie oft) auch der identische Text wie ihn die Konsole ausgibt.
Wie ruftst Du überhaupt NotesSession.SendConsoleCommand auf? Hoffentlich über NotesAgent.RunOnServer ...
Bernhard
Demian:
--- Zitat ---das ist normal und kann auch nicht geändert werden.
--- Ende Zitat ---
War ja irgendwie klar. Wär ja auch zu einfach gewesen ::)
--- Zitat ---Wie ruftst Du überhaupt NotesSession.SendConsoleCommand auf?Hoffentlich über NotesAgent.RunOnServer ...
--- Ende Zitat ---
Um ehrlich zu sein, hab ich damit bis jetzt noch nie gearbeitet. Warum über .RunOnServer? Wegen der Berechtigung? Die hat die ID, die das Design signiert. In dem Test jetzt hatte ich es in einem Agenten, den ich manuell übers Menü gestartet habe.
Wenn, hätte ich das jetzt in den Agenten vor Eingang neuer Mail gepackt, aber ohne entsprechenden ReturnCode hat es sich eh erstmal erledigt... *sniff*
Navigation
[0] Themen-Index
[*] Vorherige Sete
Zur normalen Ansicht wechseln