Hallo,
ich habe da eine Frage.
Wir haben demnächst eine Umstellung unserer Notesserver (alle bekommen einen neuen Namen), da wir unser Rechenzentrum wechseln.
In diversen Agenten, die z.T. auch interne Mails versenden, ist der entsprechende Server eingestellt unter (ausführen im Namen von).
Kann man diese Einstellung ggf. per Script ändern oder muss ich jeden Agent manuell anfassen?
Ich benutze absichtlich keine Admin- / oder Signer-ID, da hierbei automatisch eine Grußformel angefügt werden würde.
Bin für jeden Tipp dankbar.
Gruß Harald (der 14 Tage vor der Rente steht 
)
diverse Agenten ändern (ausführen im Namen von) per Agent
- Westenseer
- Erledigt
-
Per Script kannst du die Infos nur auslesen.
Mit Tools wie Ytria kannst du solche Einstellungen auch ändern.
Programmiertechnisch würde das nur per C-API gehen
-
Beim Setzen des $OnBehalfOf darauf achten, nicht nur "Server/Org" reinzuschreiben, sondern "CN=Server/O=Org".
Frage dazu: irgendwann habe ich irgendwo in irgendeinem Zusammenhang gelesen, dass bei Agenten, die auf neue oder geänderte Dokumente getriggert sind, besonders aufzupassen ist. Intern verwalten die eine Liste mit den bereits bearbeiteten Dokumenten und wenn sich der Server ändert und/oder bestimmte andere Einstellungen am Agenten, trampelt der glatt nochmal los und weil dann alle Dokumente für ihn neu sind, läuft er auch über alle. Je nach Agent und Dokument kann es "nur" ein Kuddelmuddel" geben, im schlimmsten Falle ein mittleres Chaos (bspw.: Spesenabrechnungen, die dann nocheinmal zur Buchung und Erstattung der Auslagen verarbeitet werden).
Keine Ahnung, ob das heute immernoch so ist; das war IIRC zu frühen 8.0er Zeiten.Und du willst wirklich so kurz vor deiner Rente (meine Glückwunsch dazu!
) noch am System rumdoktorn und nicht lieber deinen Nachfolger auf die Nase fallen lassen? -
Zusatzinfo zu RockWilder's Antwort:
Sobald ein Agent, der als Ziel New or Modified etc. hat, neu gespeichert wird verliert er seine "Liste" der bearbeiten Dokumente.
Also beim ändern des $OnBeahlfOf-Feldes wird der auf jedenfall beim nächsten Lauf alle Dokumente neu bearbeiten.Um das zu umgehen, kann über einen neuen temporären Agent ein Flag auf allen Dokumenten gesetzt werden, anhand welches der Agent die Dokumente erkennt und nicht nochmal neu bearbeitet. Sollte meiner Meinung nach grundsätzlich für Agenten genutzt werden, welche über ein "UpdateProcessedDoc", die bearbeiteten Dokumente markieren.
Hoffe das war verständlich^^
Beste Grüße
Tobi
-
Ich bin mir nur nicht sicher ob das auch passiert wenn man direkt das interne Feld verändert.
Beim Ändern im Designer tut er das.Bezüglich Flag sehe ich das etwas differenzierter, denn es gibt auch Agenten, die gerade dann eben doch wieder alle Dokumente verarbeiten sollen, wenn dieser geändert wurde.
Wenn ich allerdings nur ab diesem Zeitpunkt geänderte Dokumente verarbeiten will, dann ist so ein Flag die besser Variante, muss halt nur im Maskendesign auch berücjsichtigt werden -
Da könnte man dann ja unterschiedliche Flags verwenden. Oder du erstellst über den "Flag"-Agenten ein Multivalue-Feld, welches die Namen der Agent enthält, welche nur neue Dokumente (oder eben alle) bearbeiten sollen. Dann kannst du über eine kleine Funktion in einer Scriptbibliothek in allen Agenten abfragen ob er das jeweilige Dokument bearbeiten soll. Der Übersicht halber würde ich nach dem Umzug und dem Lauf aller Agenten das Feld wieder über einen anderen Agenten entfernen.
Bezüglich Flag sehe ich das etwas differenzierter, denn es gibt auch Agenten, die gerade dann eben doch wieder alle Dokumente verarbeiten sollen, wenn dieser geändert wurde.Wenn ich allerdings nur ab diesem Zeitpunkt geänderte Dokumente verarbeiten will, dann ist so ein Flag die besser Variante, muss halt nur im Maskendesign auch berücjsichtigt werden
Was meinst du mit "Das muss im Maskendesign berücksichtigt werden"? Das Feld muss ja nicht auf der Maske existieren, es reicht wenn es über den Agent auf das Dokument geschrieben wird.
-
@Rockwilder
unsere Umstellung werde ich noch mit machen "müssen". Meinem Nachfolger kann ich das nicht übergeben, da er ein absolutes Greenhorn in Sachen Notes ist. Das kann/will ich ihm nicht antun.
Mit meinem Abtritt stirbt wohl bis auf Weiteres die Entwicklung von Notes-DB's.
@'All'
Im Übrigen habe ich das Script getestet und es funztVielen Dank an alle für eure Kommeentare und für die Tipps in der Vergangenheit. Ich bin dann 'mal fast weg.
Gruß Harald -
-
Ich weiß nicht ob ich deinen Gedankengang genau verstehe. Was hast du denn gewonnen, wenn dein Feld im Maskendesign auftaucht? Das Feld muss im Anschluss ja sowieso durch einen Agenten oder manuell von den Dokumenten gelöscht werden. Oder wie willst du das über das Maskendesign machen?
Zu Programmieren:
2 Agenten "Setze Flag" & "Entferne Flag" erstellen.
1 Funktion "X" auslagern um in bestehenden Agenten zu prüfen was zu tun ist (If/Else existiert Feld & If/Else stehe mein Agentenname in dem Feld). Die Funktion in alle Agenten an den Anfang setzen.Der Ablauf würde wie folgt aussehen:
1. Agent "SetzeFlag" läuft über alle Dokumente und setz ein Flag das in etwa so aussieht:
Feldname: "AgentenDieDieseDokumenteNichtBearbeitenSollen"
Werte: Agent1, Agent2, Agent32. Bestehende Agenten laufen los. Jeder Agent dieser Agenten, prüft ob das Feld auf dem Dokument existiert (Dadurch wird zwischen neu erstellten Dokumenten und alten Dokumenten unterschieden).
Existiert das Feld prüft der Agent ob er in diesem Feld steht, falls ja wird das Dokument über "UpdateProcessedDoc" für diesen Agent als bereits bearbeitet markiert.
Steht der Agent nicht in dem Feld läuft er ganz normal und bearbeitet das Dokument wie im Code vorgesehen.3. Agent "EntferneFlag" läuft über alle Dokumente und entfernt das Flag "AgentenDieDieseDokumenteNichtBearbeitenSollen".
Ergebnis:
- Alle Dokumente sind für alle Agenten als "processed" markiert, ob sie tatsächlich bearbeitet wurden oder nicht, spielt keine Rolle. Und das für einen echt geringen Aufwand
Lg Tobi
PS. Die Namen (Falg, Agenten etc.) bitte nicht ernst nehmen
-
Die Idee mit den Flags überzeugt mich nicht. Zum einen des Aufwands wegen, zum anderen deswegen, weil bei großen Datenbanken eine wilde Repliziererei anfängt, da ja sämtliche Dokumente angefasst werden. Von Maschinen- und Netzwerklast einmal abgesehen, kann das naturgemäß auch zu umfangreichen "Aufräumarbeiten" führen, wenn sich die Replikatoren verhaken. Habt ihr Translogging aktiv, wird sich der Logger vor lauter translogging u.U. gar nicht mehr einkriegen. Das wiederum kann je nach Sicherungsstrategie relevant werden.
Wenn ihr Agenten habt, die nicht mit der Server.id oder der Unterzeichner-ID laufen sollen, was spricht gegen technische IDs, mit denen die Agenten unterzeichnet werden? Davon ab, dass man die Gruppenmitgliedschaften mit erweiterten Rechten gewaltig ausdünnen und/oder die Serverdokumente bereinigen könnte, wäre ohnehin viel gewonnen, wenn bspw. nur */Admin/Org oder */Dev/Org erweiterte Rechte hat und alles unterhalb von bspw. */User/Org halt nicht.
So könntet ihr Datenbanken umziehen, ohne euch um irgendwas kümmern zu müssen: der AdminP weiß schon, was er wann wie zu tun hat und die "ProcessedDocuments"-Liste wird auch mitgenommen.Jetzt ist es erstmal so, wie es ist und neue IDs werden am unmittelbar notwendigen Aufwand auch wenig ändern. Die Frage ist nur, ob ihr euch den Stress das nächste Mal wieder geben wollt, oder ob ihr es diesmal so aufsetzt, dass es eben nur dieses Mal Aufwand ist. Insbesondere wenn du sagst, dein Nachfolger ist noch nicht vollständig einsatzbereit, wäre es eine Überlegung wert, denke ich.
