Autor Thema: Bug - Agent execution time?  (Gelesen 5709 mal)

Offline Demian

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 569
  • Geschlecht: Männlich
Bug - Agent execution time?
« am: 07.05.11 - 10:30:10 »
Moin,moin,

ich hab da ein kleines Problem mit einem Agenten der auf "vor Eingang neuer Mail" getriggert ist. Dieser wird nach nicht mal einer Minute Laufzeit wegen Überschreitung des Zeitlimits abgebrochen (siehe Anhang). Eingestellt ist bei uns eine Laufzeit von 30 min. am Tag und 15 min. Nachts. Ein anderer jedoch periodischer Agent in dieser DB läuft auch so seine 10 min. ohne Abbruch.

Hier der Code bei dem die Agent-Ausführung abbricht:
Zitat
Sub City_EditAllHits
   '**********************************************************************************************************************************************   
   'This function gets the changed City in the DB, and edit all documents which inherits data from the changed city.    '**********************************************************************************************************************************************
   'Parameters         none
   '**********************************************************************************************************************************************
   On Error Goto ErrHandle
   '**********************************************************************************************************************************************   
   Const EventName = "City_EditAllHits" 'for reports
   '**********************************************************************************************************************************************   
   'Declarations
   Dim viewLookup As NotesView
   Dim docColToEdit As NotesDocumentCollection
   Dim docToEdit As NotesDocument
   Dim docArchive As NotesDocument
   Dim strCity As String      
   'only for form CostObject
   Dim itemInterface As NotesItem
   '**********************************************************************************************************************************************   
   'search for all docs which inhereits changed data
   If Not (docMod Is Nothing) Then
      
      strCity = Cstr(docMod.CityOLD(0))
      Call ReportWrite(Eventname & " - geändertes Quell-Dokument gefunden: " & strCity & ", suche zu ändernde Dokumente")   
      
      Set viewLookup = db.GetView("lkpEditCities")      
      Set docColToEdit = viewLookup.GetAllDocumentsByKey(strCity,True)
      
      If docColToEdit.Count = 0 Then
         Call ReportWrite(Eventname & " - es wurden keine zu ändernden Dokumente gefunden")
         Exit Sub
      End If 'docColToEdit.Count = 0
      
      Call ReportWrite(Eventname & " - es wurden " & docColToEdit.Count & " zu ändernde Dokumente gefunden")
      
      Set docToEdit = docColToEdit.GetFirstDocument      
      
      'run over all documents
      While Not (docToEdit Is Nothing)
         'create archive doc
         Set docArchive = docToEdit.CopyToDatabase(db)
         docArchive.Archived = 1
         docArchive.ArchivedDate = Now
         
         
         'change data
         docToEdit.City = Cstr(docMod.CityNEW(0))
         docToEdit.Provision = Ccur(docMod.ProvisionNEW(0))      
         docToEdit.AverageLinearDistance = Clng(docMod.AverageDistanceNEW(0))   
         Call docToEdit.AppendItemValue("$UpdatedBy",strMod_User)
         
         'special form handles
         '---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
         'CostObject
         If docToEdit.Form(0) = "CostObject" Then         
            Call ReportWrite(Eventname & " - Kostenträger " & Cstr(docToEdit.ID(0)) & " wird bearbeitet | setze Schnittstellenkennzeichen - Auslösung = " & docMod.ProvisionNEW(0))
            
            'set specified fields
            Set itemInterface = docToEdit.GetFirstItem("InterfaceIndicator")
            If itemInterface Is Nothing Then docToEdit.InterfaceIndicator = "U"         
            
            Set itemInterface = docToEdit.GetFirstItem("InterfaceIndicatorProvision")
            If itemInterface Is Nothing Then docToEdit.InterfaceIndicatorProvision = "U"      
         End If 'docToEdit.Form(0) = "CostObject"
         
         'Reservation
         If docToEdit.Form(0) = "Reservation" Then         
            Call ReportWrite(Eventname & " - es wird eine Reservierung bearbeitet - erstelle Benachrichtigungsmail")
            
            'set specified fields
            docToEdit.ReservationCity = Cstr(docMod.CityNEW(0))
            'delete not needed fields
            Call docToEdit.RemoveItem("City")
            Call docToEdit.RemoveItem("Provision")
            Call docToEdit.RemoveItem("AverageLinearDistance")
            
            'send info mail to owner of reservation
            Call Reservation_Edit(docArchive,docToEdit)
            
            'delete archive doc, because in the Archive only old reservations will be shown
            Call docArchive.Remove(True)                   
         End If 'docToEdit.Form(0) = "Reservation"       
         '---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
         
         'save all changes
         If Not (docArchive Is Nothing) Then
            Call docArchive.Save(True,False)
         End If 'Not (docArchive Is Nothing)
         
         Call docToEdit.Save(True,False)
         
         'get next document
         Set docToEdit = docColToEdit.GetNextDocument(docToEdit)
      Wend      
      
      Call ReportWrite(Eventname & " - es wurden alle " & docColToEdit.Count  & " Dokumente geändert")         
   End If 'Not (docMod Is Nothing)
   
Leave:
   Exit Sub
   
ErrHandle:
   Call ReportWriteError(EventName & " - Error" & Str(Err) & ": " & Error$ & " in Zeile " & Erl)
   Resume Leave   
End Sub


Der Abbruch erfolgte die beiden Male in der Zeile

Code
Call ReportWrite(Eventname & " - Kostenträger " & Cstr(docToEdit.ID(0)) & " wird bearbeitet | setze Schnittstellenkennzeichen - Auslösung = " & docMod.ProvisionNEW(0))

Die Ansicht lkpEditCities enthält knapp 23.000 Dokumente und ist in der 1. Spalte kategorisiert nach Ort. Der Ort bei dem abgebrochen wird enthält 730 Dokumente. Bei Orten mit weniger Dokumenten läuft der Agent laut meinem Log durch. Aber wieso wird er bei diesem Ort so früh abgebrochen? Die Dauer nach der abgebrochen wird variiert auch. Der letzte Abbruch erfolgte beim 195. Dokument nach einer Zeit von 32 Sekunden. Der Abbruch davor erfolgte beim 676. Dokument (da waren es noch 710 für diesem Ort) nach einer Zeit von 51 Sekunden. 

Wenn ich die Dokumente bei denen abgebrochen wurde, über die Eigenschaften mit denen die bearbeitet wurden vergleiche, kann ich so keine Unterschiede feststellen. Sie haben die selben Items wie die anderen Dokumente auch.

Hat es was mit dem Code zu tun? Werden bei Agenten mit dieser Triggerung die Servereinstellungen ignoriert und nach einer anderen Zeitspanne abgebrochen? Ist es ein Bug?  :-:

Da, dieser Fehler erstmal unbemerkt blieb stellt sich mir auch die Frage, welche Möglichkeiten es gibt um zu überprüfen ob ein Agent wegen Zeitüberschreitung abgebrochen wird/wurde um mich benachrichtigen zu lassen? Schade, dass hier nicht das normale Errorhandle greift  :-\

Gibt irgendeins der Agenten-Flags hier vielleicht einen Wert zurück, der nur für abgebrochene Agenten gilt?

Gruß
Demian
Gruß
Demian

Offline koehlerbv

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 20.460
  • Geschlecht: Männlich
Re: Bug - Agent execution time?
« Antwort #1 am: 07.05.11 - 11:12:04 »
Demian, schau bitte hier:
http://lotus-blogs.blogspot.com/2007/08/before-new-mail-arives-agent.html

Das ist ja auch naheliegend, da derartige Agents massiv an der Router-Performance ziehen.

Wenn es tatsächlich notwendig ist, bei New Mail sofort zu reagieren, würde ich auf jeden Fall einen anderen Weg wählen. Beispiel: Dein Router-triggered Agent erzeugt ein "Bescheid-sag"-Dokument. Und darauf stürzt sich ein zweiter Agent, der auf neue und modifizierte Dokumente reagiert.

HTH,
Bernhard

Offline Demian

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 569
  • Geschlecht: Männlich
Re: Bug - Agent execution time?
« Antwort #2 am: 07.05.11 - 11:52:50 »
Hallo Bernhard,

danke für den Link. Irgendwie hab ich aber auch ein Talent dafür in solche Fettnäpfchen zu treten  ;D

Das mit dem 2. Agenten hatte ich auch schon überlegt, wenn sich das mit dem Ignorieren der Servereinstellungen bestätigt. Wobei ich den dann über .RunOnServer mit der ID aufrufen wollte?

Gruß
Demian
Gruß
Demian

Offline koehlerbv

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 20.460
  • Geschlecht: Männlich
Re: Bug - Agent execution time?
« Antwort #3 am: 07.05.11 - 11:58:47 »
Genau das wird nichts, Demian: Dann wartet eben dieser Agent auf den zweiten - und da war doch was mit der Agent Excecution Time  ;)

Bernhard

Offline Demian

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 569
  • Geschlecht: Männlich
Re: Bug - Agent execution time?
« Antwort #4 am: 07.05.11 - 12:45:26 »
ok, dann muss ich mir mal Gedanken machen, wie ich gewährleiste, dass jede Änderung sofort verarbeitet wird, um zu vermeiden die letzte Änderung ermitteln zu müssen.

Vielen Dank für das Bestätigen meiner Vermutung mit dem Trigger und Ignorieren der Servereinstellungen.

Wünsche dir noch ein schönes Wochenende.

Gruß
Demian 
Gruß
Demian

Offline Demian

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 569
  • Geschlecht: Männlich
Re: Bug - Agent execution time?
« Antwort #5 am: 08.05.11 - 22:28:09 »
...wobei sich mir das mit der Router-Performance nicht so ganz erschließt. Ich hätte gedacht, dass ein Agent mit diesem Trigger zwar regelmäßig den Router auf Mails prüft, jedoch bei Verarbeitung dann "losgelöst" arbeitet. Bei .RunOnServer dachte ich bisher eigentlich auch, die Agenten laufen dann autark auf dem Server.

Meine Überlegung wäre jetzt ggf. mit .SendConsoleCommand und Tell Amgr run zu arbeiten. Nur wirklich sicher sein, dass der Agent dann direkt lostritt und das Änderungsdokument verarbeitet kann ich hier nicht sein, oder?
Gruß
Demian

Offline koehlerbv

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 20.460
  • Geschlecht: Männlich
Re: Bug - Agent execution time?
« Antwort #6 am: 08.05.11 - 23:27:49 »
Wieso erschliesst sich das nicht? VOR Eingang neuer Mail heisst: Der Router kann erst weiter machen, wenn der durch den Eingang neuer Mail gestartete Agent fertig ist - eher kann da ja nix weitergehen. Wenn Du dann eine Aktion antreten würdest, die eine Stunde läuft, dann wqeisst Du, was das bedeutet: Du kannst max. 24 Mails am Tag empfangen.

Weiters erschliesst sich mir nicht, was ein Agent in Bezug auf eine neue Mail soviel herumwurschteln muss. Verarbeite halt die Mail und packe etwas in die DB, die das was angeht. Und da kann dann ein Agent "Auf neue oder modifizierte Dokumente" losrennen (oder anderes).

Bernhard

Offline Demian

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 569
  • Geschlecht: Männlich
Re: Bug - Agent execution time?
« Antwort #7 am: 09.05.11 - 10:45:10 »
Wieso erschliesst sich das nicht? VOR Eingang neuer Mail heisst: Der Router kann erst weiter machen, wenn der durch den Eingang neuer Mail gestartete Agent fertig ist - eher kann da ja nix weitergehen. Wenn Du dann eine Aktion antreten würdest, die eine Stunde läuft, dann wqeisst Du, was das bedeutet: Du kannst max. 24 Mails am Tag empfangen.
Ok, also läuft das vom Router aus? Ich hätte gedacht, der Agent prüft den Router regelmäßig auf Mails und wenn eine da, wird die halt verarbeitet. Sowas steht aber auch nicht in der Hilfe, jedenfalls nicht da wo die Einstellung erläutert ist.  :(

Weiters erschliesst sich mir nicht, was ein Agent in Bezug auf eine neue Mail soviel herumwurschteln muss. Verarbeite halt die Mail und packe etwas in die DB, die das was angeht.
So ähnlich läuft es ja. In DB 1 wird etwas geändert und davon sind unter Umständen auch Dokumente in DB2 betroffen. DB1 schickt also eine Mail mit den alten und neuen Feldwerten des geänderten Dokumentes an DB2, die dann alle betroffenen Dokumente ändern soll.

Und da kann dann ein Agent "Auf neue oder modifizierte Dokumente" losrennen (oder anderes).

Hätte ich ursprünglich auch gerne so gelöst, nur hab ich dann das Problem, dass ggf. schon wieder eine weitere Änderung gemacht wurde und der Agent die 1. noch gar nicht verarbeitet hat, weil er erst später anspringt. Genau das konnte ich mit dem Trigger "vor neuer Mail" vermeiden. Hier wird/wurde die Änderung dann direkt weiterverarbeitet. So müsste ich im Agent noch programmatisch vergleichen, welche Änderung denn die letzte ist. Da hier nicht nur eine Maske in einer DB betroffen ist, würde das den Rahmen ziemlich "sprengen".

Steh im Moment etwas auf dem Schlauch wie ich es hinkriege, dass die Änderung sofort weiterverarbeitet wird.
Gruß
Demian

Offline koehlerbv

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 20.460
  • Geschlecht: Männlich
Re: Bug - Agent execution time?
« Antwort #8 am: 09.05.11 - 10:55:27 »
"Sofort" ist beim Domino immer "sowie er Zeit hat".

Du kannst doch an DB2 ein Änderungsanforderungsdokument schicken. Das landet in einer "unsortierten" Ansicht (es wird also nach Erstellungszeitpunkt sortiert) - damit hast Du immer die korrekte Reihenfolge der abzuarbeitenden Tasks.

HTH,
Bernhard

Offline Tode

  • Moderatoren
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 6.883
  • Geschlecht: Männlich
  • Geht nicht, gibt's (fast) nicht... *g*
Re: Bug - Agent execution time?
« Antwort #9 am: 09.05.11 - 11:33:50 »
Ergänzend ist noch zu sagen:

Du darfst in Deinem Agenten dann natürlich NICHT auf unprocessed documents gehen (diese collection ist nämlich wieder unsortiert), sondern musst über einen View- Navigator oder direkt über die view (mit GetFirst und GetNext) gehen....

Gruss
Tode
Gruss
Torsten (Tode)

P.S.: Da mein Nickname immer mal wieder für Verwirrung sorgt: Tode hat NICHTS mit Tod zu tun. So klingt es einfach, wenn ein 2- Jähriger versucht "Torsten" zu sagen... das klingt dann so: "Tooode" (langes O, das r, s und n werden verschluckt, das t wird zum badischen d)

Offline Thomas Schulte

  • @Notes Preisträger
  • Freund des Hauses!
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 4.388
  • Geschlecht: Männlich
  • Ich glaub mich tritt ein Pferd
Re: Bug - Agent execution time?
« Antwort #10 am: 09.05.11 - 12:03:22 »
Und noch eine Ergänzung: Wenn du von DB1 in DB2 eine Mail schickst, dann machst du einen Umweg. Das Dokument direkt in DB2 erstellen ist schneller und sinnvoller.
Thomas Schulte

Collaborative Project Portfolio and Project Management Software

"Aber wo wir jetzt einmal soweit gekommen sind, möchte ich noch nicht aufgeben. Versteh mich recht, aufgeben liegt mir irgendwie nicht."

J.R.R.Tolkien Herr der Ringe, Der Schicksalsberg

OpenNTF Project: !!HELP!! !!SYSTEM!!  !!DRIVER!!

Skype: thomasschulte-kulmbach

Offline Demian

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 569
  • Geschlecht: Männlich
Re: Bug - Agent execution time?
« Antwort #11 am: 09.05.11 - 13:09:05 »
Ich antworte euch auf die Beiträge wenn ich nachher Feierabend habe. Da kann ich in Ruhe schreiben. Hier werd ich durch meinen eigentlichen Job als rausgerissen :-\
Gruß
Demian

Offline Demian

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 569
  • Geschlecht: Männlich
Re: Bug - Agent execution time?
« Antwort #12 am: 09.05.11 - 19:44:29 »
also dann erstmal zu euren Beiträgen:

Zitat
"Sofort" ist beim Domino immer "sowie er Zeit hat".
Dessen bin ich mir bewusst und hatte mich gefreut das eben mit diesem Trigger vermeintlich ausgehebelt zu haben.

Zitat
NICHT auf unprocessed documents gehen
.UnprocessedDocuments habe ich bisher eigentlich nur in Zusammenhang mit manuell markierten Dokumenten verwendet.  

Zitat
Wenn du von DB1 in DB2 eine Mail schickst
Hintergrund war der Agent-Trigger. Näheres dann gleich.

Also ich versuche mal mein Konzept (wenn man es denn so nennen kann) zu beschreiben:

Mein Grundgedanke war, die Änderungen, die sich auf andere Dokumente/Datenbanken auswirken zentral an einer Stelle zu warten. Hierzu habe ich ein Extra-Template, welches nur global gültige Designelemente enthalten soll, die dann entsprechend in die eigentlichen Templates meiner Datenbanken kopiert und bei künftigen Gestaltungsänderungen aktualisiert werden.
 
Die Templates an sich versuche ich auch weitgehend identisch aufzubauen. Ich verwende z.B. für jede Maske eine eigene Lib, die die grundlegenden Maskenereignisse, sowie diverse Zusatzfunktionen beeinhaltet. Fast alle meine Masken-Libs sind wie auf dem Screenshot aufgebaut und vom Code bis auf z.B. Feldnamen grundlegend identisch.

Im _Postopen speicher ich die aktuellen Werte, um diese im _Postsave zu vergleichen. Wurde ein Wert geändert wird im _Postsave zunächst _Archived und dann _TempDocCreated aufgerufen. _TempDocCreated macht im Prinzip nichts anderes als ein Änderungsdokument mit den alten und neuen Werten zu erstellen, dieses mit dem Namen der geänderten Maske, sowie dem Namen des Users zu versehen und dann einen Agenten per .RunOnServer und der ID des Änderungsdokuments loszutreten.

Dieser Agent ist für alle Datenbanken gleich (und schön kompakt) und liegt deswegen in oben genannten Extra-Template.

Er entscheidet anhand des Maskennamens an welche Datenbank/en die Änderung weitergegeben werden muss und verschickt entsprechend das Änderungsdokument per Mail an ein oder mehrere Datenbanken. Nach Verschicken der Mail/s wird das Änderungsdokument gelöscht.

In der Empfänger-DB läuft dann der Agent mit dem Trigger vor Eingang neuer Mail an und entscheidet anhand des Maskennamens welche Änderung (z.B. oben stehendes City_EditAllHits) losgetreten wird. Nach Verarbeitung wird die Mail gelöscht.

Auch dieser Agent ist für alle DB's gleich und löste zusammen mit dem aufrufenden Agenten damals für mich viele Probleme auf einmal ohne programmatischen Mehraufwand:

- Die User sind nur bis zum Verschicken der Mail an der Verarbeitung beteiligt. Zuvor hatte ich Änderungen dieser Art immer in den jeweiligen Masken-Libs ausgeführt und der User musste so Lange warten, bis alles verarbeitet war.  
- Die Maskenlibs sind nahezu identisch aufgebaut und dadurch erheblich übersichtlicher und einfacher zu warten.
- Die Änderungen werden sofort ausgeführt (so lange der Router läuft... ::)).
- Die Agenten sind übersichtlich und schnell (näheres weiter unten).
- All meine Änderungen aus allen DB's, die sich auf andere Docs/DB's auswirken stehen an zentraler Stelle in 2 Agenten.

Wenn ich über eine Ansicht und den Trigger "nachdem Dokumente erstellt..." gehen würde (darüber habe ich damals auch nachgedacht) muss ich alle "Anforderungen" in einer Schleife durchlaufen, die dann wiederum die Schleife in z.B. oben stehenden Code auslöst.

Angenommen an Position 1 der Ansicht ist ein Änderungsdokument für den Ort Frankfurt, an Position 2 eins für den Ort Hamburg, an Position 3 eins für die Auftragsnummer XYZ und an Position 4 wieder eins für den Ort Frankfurt. Für Frankfurt müsste der eine Agent ja dann 2x alle betroffenen Dokumente in einem Lauf verarbeiten. Außerdem noch die Änderungen für den Ort Hamburg und der Auftragsnummer XYZ.

Je nach Anzahl der vorhandenen Änderungsdokumente + Anzahl der betroffenen Dokumente dürfte dieser Agent auf diese Art einiges zu tun haben. Er würde ja dann nicht nur eine Änderung für eine Maskenart verarbeiten, sondern alle Änderungen für alle Maskenarten. Das beeinhaltet zum Beispiel auch das Verschicken von Mails usw.

Der Höchstwert der betroffenen Dokumente die mein Agent in den letzten 1,5 Jahren in einem Lauf zu verarbeiten hatte, war jetzt 730 (siehe oben). Ansonsten sind es auch schonmal um die 100 Dokumente oder auch nur 1. Bei einer Änderung einer Maskenart.

So und wer jetzt nicht eingeschlafen oder total verwirrt ist, darf mich verbal verhauen ;D

Edit: Anhang fehlte.
« Letzte Änderung: 09.05.11 - 19:46:59 von Demian »
Gruß
Demian

Offline koehlerbv

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 20.460
  • Geschlecht: Männlich
Re: Bug - Agent execution time?
« Antwort #13 am: 10.05.11 - 00:10:47 »
Design - Libs -Masken -User - Massendatenveränderung .... Bahnhof!

Bitte, bitte, Demian: Trenne die Themengebiete. 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.

- Was ist das auslösende Ereignis?
- Was soll dann geändert werden?
- Wo soll das geändert werden?

Ich habe Deine Datenbanken ja gesehen (und bin damals auch durchgestiegen), aber jetzt verstehe ich - wie gesagt - nur noch Bahnhof. Ich ich helfe gerne weiter!

Bernhard

Offline Peter Klett

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 2.713
  • Geschlecht: Männlich
Re: Bug - Agent execution time?
« Antwort #14 am: 10.05.11 - 07:50:35 »
Warum bildest Du nicht alles in einem zentralen Agenten ab?

Verstanden habe ich folgendes:

Es gibt einen zentralen Agenten in einer zentralen Datenbank. Dieser Agent erhält Aufträge, aufgrund derer er Mails an die betroffenen Datenbanken sendet. In diesen betroffenen Datenbanken ist wiederum ein Agent, der die vom vorigen Agenten erstellten Aufträge abarbeitet.

Du hast also für jede Datenbank einschließlich der zentralen einen Agenten, der aktiviert und überwacht werden muss. Spätestens dann, wenn Du mehr Datenbanken hast, als zeitgleich Agenten laufen dürfen, bekommst Du einen Stau.

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

Die Sorge, dass der Agent zuviel zu tun hat, sehe ich nicht. Nur durch eine Umstellung des Konzeptes werden doch die Anzahl der durchzuführenden Änderungen nicht mehr. In Deinem Beispiel muss Frankfurt auf jeden Fall zweimal geändert werden, ob zweimal durch einen Agentenlauf oder jeweils einmal bei zwei Agentenläufen. Auch Dein Agent würde damit nicht wesentlich komplizierter, evtl. musst Du nur das Initialize des Agenten in eine eigene Funktion packen, etwa so:

Set doc = col.GetFirstDocument
Do While Not doc Is Nothing
   Call MacheWasDerAgentNurEinmalTat  (doc)
   Set doc = col.GetNextDocument (doc)
Loop

Falls Du dann noch befürchtest, dass der Agent durch die zu lange Laufzeit vom AMgr abgewürgt wird, beende ihn gezielt selbst. Ich habe einen ähnlichen Agenten, der per Mail (i.d.R. Nachts) Dateien entgegennimmt und importiert. Wenn alle Lieferanten gleichzeitig liefern würden, wären das schon mal 1.000 Dateien am Stück (die senden zwar mit unterschiedlichen Zeiten, aber wenn z.B. mal wieder die Replikation zwischen dem MailServer und dem Anwendungsserver hängt - was NIE vorkommt - dann stehen alle Aufträge zeitgleich - gerne auch tagsüber -  auf der Liste). Die Agentenlaufzeitbegrenzung würde also wenigstens einen Import pro Agentenlauf stören. Deshalb ist der Agent so gebaut, dass er alle 10 Minuten startet. Zu Beginn errechnet er sich eine Stoppzeit (jetzt + 8 Minuten). Vor Verarbeitung der nächsten Datei prüft er, ob die Stoppzeit erreicht wurde. Wenn ja, beendet sich der Agent selbst und wird kurz darauf wieder neu gestartet. Es gibt dann zwar immer eine Lücke von etwa 2 Minuten, in der der Agent nichts macht, aber er ist noch nie abgewürgt worden. Und das ganze läuft schon seit 5 Jahren.

Und ich habe alles zentral in dieser einen Datenbank, auch wenn die Anzahl der betroffenen Datenbanken sich seit Beginn deutlich erhöht hat.
« Letzte Änderung: 10.05.11 - 07:52:06 von Peter Klett »

Offline Demian

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 569
  • Geschlecht: Männlich
Re: Bug - Agent execution time?
« Antwort #15 am: 10.05.11 - 08:50:58 »
@Bernhard

Zitat
Design - Libs -Masken -User - Massendatenveränderung .... Bahnhof!
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.
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?
Im Endeffekt die Funktion _TempDocCreated in jeder Maskenlib.

Zitat
- Was soll dann geändert werden?
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?
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.
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!
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?
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.
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.
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.
das wäre der 2. Agent

Zitat
Du hast also für jede Datenbank einschließlich der zentralen einen Agenten
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
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.
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.
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.
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.
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.
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.
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.

« Letzte Änderung: 18.05.11 - 17:45:24 von Demian »
Gruß
Demian

Offline Demian

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 569
  • Geschlecht: Männlich
Re: Bug - Agent execution time?
« Antwort #16 am: 10.05.11 - 11:59:00 »
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.
Gruß
Demian

Offline Tode

  • Moderatoren
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 6.883
  • Geschlecht: Männlich
  • Geht nicht, gibt's (fast) nicht... *g*
Re: Bug - Agent execution time?
« Antwort #17 am: 10.05.11 - 16:04:09 »
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
Gruss
Torsten (Tode)

P.S.: Da mein Nickname immer mal wieder für Verwirrung sorgt: Tode hat NICHTS mit Tod zu tun. So klingt es einfach, wenn ein 2- Jähriger versucht "Torsten" zu sagen... das klingt dann so: "Tooode" (langes O, das r, s und n werden verschluckt, das t wird zum badischen d)

Offline koehlerbv

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 20.460
  • Geschlecht: Männlich
Re: Bug - Agent execution time?
« Antwort #18 am: 10.05.11 - 16:32:36 »
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

Offline Demian

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 569
  • Geschlecht: Männlich
Re: Bug - Agent execution time?
« Antwort #19 am: 11.05.11 - 09:40:17 »
Zitat
das ist normal und kann auch nicht geändert werden.
War ja irgendwie klar. Wär ja auch zu einfach gewesen  ::)

Zitat
Wie ruftst Du überhaupt NotesSession.SendConsoleCommand auf?Hoffentlich über NotesAgent.RunOnServer ...
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*
Gruß
Demian

 

Impressum Atnotes.de  -  Powered by Syslords Solutions  -  Datenschutz