Domino 9 und frühere Versionen > Entwicklung

Log-Funktion in DB

<< < (2/3) > >>

TMC:

--- Zitat von: scipio am 05.08.05 - 09:13:32 ---Das Logdoc besitzt ein berechnetes (Text)Feld $PublicAccess mit dem Wert "1"; in den Maskeneigenschaften habe ich den Haken bei 'Verfügbar für Benutzer mit öffentlichem Zugriff' gesetzt.
--- Ende Zitat ---

Maskeneigenschaften sind hier egal, da Du das Dokument im Backend erstellst. Das computed Feld wird wird auch erst beim nächsten Speichervorgang im Frontend aktualisiert.

Du musst also $PublicAccess bereits beim Erstellen des Backend-Dokumentes setzen.

flaite:
Warum wird nicht einfach das loga.ntf Template benutzt? und NotesLog Klasse.
Dann kann das direkt für mehrere Datenbanken benutzt werden, wenn Bedarf aufkommt.
Ich finde nicht, dass so ein Logging in die eigentliche Anwendung gehört, wo LotusNotes ja schon eine Lösung dafür bereithält.

TMC:
Sehe ich genau so, Axel/Kennwort.

Wobei die log.nsf meiner persönlichen Meinung nach nicht wirklich taugt.
Ich musste bsp. Agenten sauber loggen. Dabei Realsituation: Domino-Admin kommt mit einem dicken Kopf Montag morgen ins Büro. Als erstes schaut er nach, ob alles sauber gelaufen ist am Wochenende. Spätestens hier ist m.E. die Log.nsf unzureichend. Ich habe daher was eigenes erstellt, womit über ErrorHandling in einigen Datenbanken eine zentrale DB entsprechend gefüllt wird (inkl. mehrerer Status, etc. etc.). Einziger Nachteil bei meiner Lösung: die TMC-Log.lss muss in alle Datenbanken übertragen werden, wenn ich was ändere.
Eine Traumlösung stellt log.nsf für mich nicht dar.

Aber letztendlich sollte so ein Logging in jedem Fall in einer 2. DB stattfinden, so sehe ich das auch.

koehlerbv:
Ich sehe das wie Matthias. Die NotesLog class ist "für die fixe Lösung", weist aber im realen Einsatz durchaus Probleme auf. Ich selbst habe sie noch nie produktiv eingesetzt wegen ihrer Grenzen und setze ebenfalls eine eigene Klasse ein (natürlich mit den gleichen nachteilen, die Matthias genannt hat, aber ob das wirklich Nachteile sind, wage ich zu bezweifeln - das Kopieren einer Library in eine neue Applikation stellt ja nun keinerlei Problem dar).
Die Vorteile überwiegen:
- Logging in der gleiche noder einer eigenen DB
- Übersichtliche Darstellung der Stati
- Aufteilung auch langer zu loggender Sessions notfalls in x Dokumenten, aber mit einer Zusammenfassung
- optionale Benachrichtigungen an Admins oder andere frei zu konfigurierende Personen / Gruppen / Rollen
- eigene Zugriffssteuerung auf die Log-Dokumente (wichtig vor allem, wenn das Logging in der gleichen DB erfolgt)

Bernhard

flaite:
Man kann in diese Log-DB bessere Ansichten einbauen. Dann wird die übersichtlicher. Z.B. Ansicht mit ALLES nach Datum sortiert. Spezielle kritische-Fehler-Ansicht, etc.
Ausserdem gibt es auf diesem Open-Source Portal, wo Thomas S. und Ulrich ihr !Help! haben auch eine Log-Template das ziemlich gut sein soll.
Ich hab schon ein paar selbstgebaute Log-Lösungen gesehen, die wirklich schlecht programmiert waren. Deshalb würde ich sowas immer auf vorhandenes aufbauen.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete