Logging

Für das Logging sind verschiedene Ziele definierbar. Die Ziele können alternativ oder parallel genutzt werden.

Die verschiedenen Ziele sind erst verfügbar, wenn die Logging-Optionen erfolgreich aus der globalen Konfiguration eingelesen wurde. Wenn beim Programmstart vor oder während des Lesens der Konfigurationsdaten ein Fehler auftritt, erfolgt die Log-Ausgabe in die folgenden Standardziele:

Konsole
Windows-Ereignisanzeige
Log-Datei xSuiteInterface5.log
Wenn keine Schreibrechte vorhanden sind, wir die Datei im Temporärverzeichnis des ausführenden Benutzerkontos erstellt.

In die Windows-Ereignisanzeige und in die Log-Datei werden ausschließlich Fehlermeldungen geschrieben, die beim Start auftreten. In die Konsole werden auch sonstige Startmeldungen geschrieben.

Bei Start-Problemen des Windows-Dienstes kann es hilfreich sein, das Programm zunächst als Konsolenanwendung auszuführen und die zusätzlichen Startmeldungen zu beachten. Dabei ist zu berücksichtigen, dass für die beiden Ausführungsarten in der Regel unterschiedliche Konten verwendet werden (Dienstkonto oder interaktives Benutzerkonto). Die verschiedenen Ausführungsarten können zu einem abweichenden Programmverhalten führen, z. B. aufgrund unterschiedlicher Berechtigungen oder fehlenden Laufwerksverknüpfungen im Kontext des Dienstkontos.

Eigenschaft	Beschreibung
Logging.Level	Detailgrad des Loggings in absteigender Reihenfolge: `Trace` `Debug` `Information` (Standardwert) `Warning` `Error` `None` Der Grad `Trace` sollte nur temporär für Problemanalysen genutzt werden. Wenn dieser Grad genutzt wird, werden permanent Log-Einträge generiert, auch wenn keine Daten zur Verarbeitung anstehen. Der Grad `Debug` generiert gegenüber dem Standardwert deutlich mehr Detailinformationen. Wenn genug Speicherplatz vorhanden ist oder ältere Logdaten regelmäßig gelöscht werden, kann dieser Grad dennoch über einen längeren Zeitraum aktiviert bleiben.
Logging.File	Pfad der Log-Datei, wenn die Protokollierung in eine solche Datei erfolgt Durch Einbindung der Variablen `%Date%`, `%Tenant%` und `%Category%` können Ordnernamen und Dateinamen dynamisch generiert werden, d.h. das Logging kann nach diesen Kriterien in separate Dateien aufgegliedert werden. Wenn die Trennung nach Mandant (`%Tenant%`) und Kategorie (`%Category%`) nicht stattfindet, werden diese Informationen stattdessen in den Protokolltext geschrieben. Die Kategorie ist hierbei eine Kennung, die den Worker-Typ oder den Webservice-Typ beschreibt, der einen Log-Eintrag generiert hat. Im Fall eines Workers wird die Kennung durch die Worker-Instanznummer ergänzt. Die Variablen `%WorkerName%` und `%Scenario%` sind ebenfalls nutzbar. Allerdings sind diese Variablen nicht immer mit einem Wert belegt. Daher können unterschiedliche Logdateinamen entstehen, teils mit gesetztem Variablenwert und teils mit leerem Variablenwert. Der "WorkerName" ist nur optional für Worker-Instanzen und Scheduler-Instanzen konfigurierbar (Eigenschaften `Worker[].Name` und `Schedule[].Name`). Ein "Scenario"-Kontext ist generell nur für Worker vorhanden. Allerdings existieren bei Workern auch Log-Meldungen, die unabhängig vom Szenario sind.
Logging.OpenFileInNpp	Wahrheitswert, ob die Log-Dateien, die über `Logging.File` erzeugt wurden, automatisch in dem Texteditor Notepad++ geöffnet werden Standardwert: `FALSE` Voraussetzungen: Notepad++ ist lokal auf dem System installiert. xSuite Interface wird als Konsolenanwendung unter Microsoft Windows ausgeführt. Diese Option ist nicht für den laufenden Betrieb ausgelegt. Das automatische Öffnen der Dateien im Texteditor dient zur Unterstützung bei der Erstellung einer neuen Konfiguration und bei der Problemanalyse. Wenn diese Option verwendet wird, wird eine neue Instanz des Texteditors gestartet und jede Log-Datei wird bei der ersten Verwendung innerhalb des aktuellen Programmlaufs in dieser Instanz geöffnet. Das Öffnen der Datei erfolgt im Monitoring-Modus. In diesem Modus wird die Anzeige bei jeder Dateiänderung automatisch aktualisiert. Die Dateianzeige verhält sich dadurch im Texteditor ähnlich wie die fortlaufenden Log-Ausgaben im Konsolenfenster. Die Informationen aller parallelläufigen Worker-Instanzen werden jedoch im Gegensatz zur Anzeige im Konsolenfenster nicht in dasselbe Fenster ausgegeben. Wenn die Log-Dateien entsprechend separiert sind, werden die Dateien je Worker in einem eigenen Editor-Tab angezeigt. Dies erhöht die Lesbarkeit der Log-Ausgaben.
Logging.Database	optionale Konfiguration einer Datenbankverbindung, wenn die Protokollierung in eine Datenbanktabelle erfolgt Die untergeordneten Konfigurationseigenschaften und die unterstützten Datenbanksysteme entsprechen denen unter der Eigenschaft `Database` für die interne Verwaltungsdatenbank (siehe Verwaltungsdatenbank). Wenn für das Logging die gleiche interne Datenbankverbindung wie für die übrigen Verwaltungsdaten genutzt wird, kann an dieser Stelle auf die schon konfigurierte Datenbankverbindung verwiesen werden. Dazu muss die Eigenschaft `Logging.Database.Type` auf den Wert `Internal` gesetzt werden. Die Anzeige von Log-Einträgen im Statusmonitor beruht auf dem Datenbank-Logging (siehe Eigenschaft `StatusService.Activate`). Um diese Funktion zu nutzen, muss das Datenbank-Logging aktiviert sein. Das Logging über die interne Verbindung erfolgt mandantenspezifisch in die jeweilige Datenbank. Nur globale Einträge werden unter einem separaten Datenbanknamen mit einem in Suffix für den Pseudo-Mandantennamen "Global" geschrieben. Bei der Protokollierung in eine externe Datenbank findet von xSuite Interface keine Mandantentrennung statt. Alle Einträge landen in derselben Tabelle und können nur über ein entsprechendes Tabellenfeld nach Mandanten unterschieden werden. Außerdem können solche Log-Einträge nicht über den internen Statusmonitor eingesehen werden und eine interne Makrofunktion zum Löschen alter Log-Einträge kann ebenfalls nicht auf die externe Datenbank zugreifen.
Logging.ToConsole	Wahrheitswert, ob eine Ausgabe von Logdaten im Konsolenfenster erfolgen soll, wenn das Programm als Konsolenanwendung ausgeführt wird Standardwert: `TRUE`
Logging.ToEventLog	Wahrheitswert, ob eine Ausgabe von Logdaten in die Windows-Ereignisanzeige erfolgen soll Diese eine Ausgabe von Logdaten beschränkt sich grundsätzlich auf Meldungen der Typen "Warning" und "Error". Standardwert: `FALSE`
Logging.EventLogErrorsOnly	Wahrheitswert, ob die Ausgabe von Logdaten in die Windows-Ereignisanzeige nur für Meldungen vom Typ "Error" erfolgen soll (und nicht auch für "Warning") Standardwert: `TRUE`
Logging.LogStackTrace	Wahrheitswert, ob bei Fehlermeldungen auch ein Stack Trace ausgegeben wird Ein Stack Trace ist umfangreich, kann aber für die entwicklungsseitige Fehleranalyse hilfreich sein. Standardwert: `FALSE`
Logging.Mail	optionale Konfiguration einer Mailserver-Anbindung, wenn für Meldungen vom Typ "Warning" und/oder "Error" eine Statusmeldung per E-Mail verschickt wird Die grundlegenden Verbindungsparameter entsprechen den Parametern unter Mailserver-Anbindung, beschränkt auf die für ausgehende Mails nutzbaren Schnittstellen oder Protokolle EWS, Graph, Gmail und SMTP. Hinzu kommen nachfolgende Eigenschaften, die spezifisch für diesen Kontext sind.
Logging.Mail.From(*)	Mail-Adresse des Absenders Diese Eigenschaft ist nur für das SMTP-Protokoll relevant. In allen anderen Fällen wird die Mail-Adresse implizit anhand der Benutzeranmeldung gesetzt.
Logging.Mail.To[]* Logging.Mail.Cc[] Logging.Mail.Bcc[]	Mail-Adressen der primären Empfänger und der optionalen CC-/BCC-Empfänger
Logging.Mail.Subject Logging.Mail.Body	individuelle Inhalte des Betreff-Feldes und des Nachrichtentextes Beide Felder sind mit einem Standardtext vorbelegt. Folgende Variablen sind nutzbar: `%EventType%`: Art des Ereignisses, d.h. "Warning" oder "Error" `%Scope%`: Detailinformationen zum Kontext des Auftretens `%Message%`: Meldungstext
Logging.Mail.EventIdFilter Logging.Mail.TextFilter	optionale Filter für Ereignisklassen und Textinhalte Syntax: siehe Syntax von Namensfiltern Diese Filter beschränken den Mail-Versand auf Meldungen bestimmter Ereignisklassen oder Textinhalte oder klammern bestimmte, nicht relevante Meldungen explizit aus.
Logging.Mail.ErrorsOnly	Wahrheitswert, ob der Mail-Versand nur für Meldungen vom Typ "Error" erfolgen soll Für Meldungen vom Typ "Warning" werden dann keine E-Mails versendet. Standardwert: `TRUE`
Logging.Mail.LogBufferSize	maximale Anzahl von Logzeilen, die zwischengespeichert werden Um weitere Kontextinformationen zu einem Fehler zu liefern, können Log-Meldungen, die vor dem Fehlerauftritt generiert wurden, intern zwischengespeichert und als Dateianlage an die E-Mail angefügt werden. Standardwert: `0` (Zwischenspeicherung ist inaktiv)

Eigenschaft

Beschreibung

Logging.Level

Detailgrad des Loggings in absteigender Reihenfolge:

Trace
Debug
Information (Standardwert)
Warning
Error
None

Der Grad Trace sollte nur temporär für Problemanalysen genutzt werden. Wenn dieser Grad genutzt wird, werden permanent Log-Einträge generiert, auch wenn keine Daten zur Verarbeitung anstehen.

Der Grad Debug generiert gegenüber dem Standardwert deutlich mehr Detailinformationen. Wenn genug Speicherplatz vorhanden ist oder ältere Logdaten regelmäßig gelöscht werden, kann dieser Grad dennoch über einen längeren Zeitraum aktiviert bleiben.

Logging.File

Pfad der Log-Datei, wenn die Protokollierung in eine solche Datei erfolgt

Durch Einbindung der Variablen %Date%, %Tenant% und %Category% können Ordnernamen und Dateinamen dynamisch generiert werden, d.h. das Logging kann nach diesen Kriterien in separate Dateien aufgegliedert werden. Wenn die Trennung nach Mandant (%Tenant%) und Kategorie (%Category%) nicht stattfindet, werden diese Informationen stattdessen in den Protokolltext geschrieben. Die Kategorie ist hierbei eine Kennung, die den Worker-Typ oder den Webservice-Typ beschreibt, der einen Log-Eintrag generiert hat. Im Fall eines Workers wird die Kennung durch die Worker-Instanznummer ergänzt.

Die Variablen %WorkerName% und %Scenario% sind ebenfalls nutzbar. Allerdings sind diese Variablen nicht immer mit einem Wert belegt. Daher können unterschiedliche Logdateinamen entstehen, teils mit gesetztem Variablenwert und teils mit leerem Variablenwert. Der "WorkerName" ist nur optional für Worker-Instanzen und Scheduler-Instanzen konfigurierbar (Eigenschaften Worker[].Name und Schedule[].Name). Ein "Scenario"-Kontext ist generell nur für Worker vorhanden. Allerdings existieren bei Workern auch Log-Meldungen, die unabhängig vom Szenario sind.

Logging.OpenFileInNpp

Wahrheitswert, ob die Log-Dateien, die über Logging.File erzeugt wurden, automatisch in dem Texteditor Notepad++ geöffnet werden

Standardwert: FALSE

Voraussetzungen:

Notepad++ ist lokal auf dem System installiert.
xSuite Interface wird als Konsolenanwendung unter Microsoft Windows ausgeführt.

Diese Option ist nicht für den laufenden Betrieb ausgelegt. Das automatische Öffnen der Dateien im Texteditor dient zur Unterstützung bei der Erstellung einer neuen Konfiguration und bei der Problemanalyse. Wenn diese Option verwendet wird, wird eine neue Instanz des Texteditors gestartet und jede Log-Datei wird bei der ersten Verwendung innerhalb des aktuellen Programmlaufs in dieser Instanz geöffnet.

Das Öffnen der Datei erfolgt im Monitoring-Modus. In diesem Modus wird die Anzeige bei jeder Dateiänderung automatisch aktualisiert. Die Dateianzeige verhält sich dadurch im Texteditor ähnlich wie die fortlaufenden Log-Ausgaben im Konsolenfenster. Die Informationen aller parallelläufigen Worker-Instanzen werden jedoch im Gegensatz zur Anzeige im Konsolenfenster nicht in dasselbe Fenster ausgegeben. Wenn die Log-Dateien entsprechend separiert sind, werden die Dateien je Worker in einem eigenen Editor-Tab angezeigt. Dies erhöht die Lesbarkeit der Log-Ausgaben.

Logging.Database

optionale Konfiguration einer Datenbankverbindung, wenn die Protokollierung in eine Datenbanktabelle erfolgt

Die untergeordneten Konfigurationseigenschaften und die unterstützten Datenbanksysteme entsprechen denen unter der Eigenschaft Database für die interne Verwaltungsdatenbank (siehe Verwaltungsdatenbank). Wenn für das Logging die gleiche interne Datenbankverbindung wie für die übrigen Verwaltungsdaten genutzt wird, kann an dieser Stelle auf die schon konfigurierte Datenbankverbindung verwiesen werden. Dazu muss die Eigenschaft Logging.Database.Type auf den Wert Internal gesetzt werden.

Die Anzeige von Log-Einträgen im Statusmonitor beruht auf dem Datenbank-Logging (siehe Eigenschaft StatusService.Activate). Um diese Funktion zu nutzen, muss das Datenbank-Logging aktiviert sein.

Das Logging über die interne Verbindung erfolgt mandantenspezifisch in die jeweilige Datenbank. Nur globale Einträge werden unter einem separaten Datenbanknamen mit einem in Suffix für den Pseudo-Mandantennamen "Global" geschrieben.

Bei der Protokollierung in eine externe Datenbank findet von xSuite Interface keine Mandantentrennung statt. Alle Einträge landen in derselben Tabelle und können nur über ein entsprechendes Tabellenfeld nach Mandanten unterschieden werden. Außerdem können solche Log-Einträge nicht über den internen Statusmonitor eingesehen werden und eine interne Makrofunktion zum Löschen alter Log-Einträge kann ebenfalls nicht auf die externe Datenbank zugreifen.

Logging.ToConsole

Wahrheitswert, ob eine Ausgabe von Logdaten im Konsolenfenster erfolgen soll, wenn das Programm als Konsolenanwendung ausgeführt wird

Standardwert: TRUE

Logging.ToEventLog

Wahrheitswert, ob eine Ausgabe von Logdaten in die Windows-Ereignisanzeige erfolgen soll

Diese eine Ausgabe von Logdaten beschränkt sich grundsätzlich auf Meldungen der Typen "Warning" und "Error".

Standardwert: FALSE

Logging.EventLogErrorsOnly

Wahrheitswert, ob die Ausgabe von Logdaten in die Windows-Ereignisanzeige nur für Meldungen vom Typ "Error" erfolgen soll (und nicht auch für "Warning")

Standardwert: TRUE

Logging.LogStackTrace

Wahrheitswert, ob bei Fehlermeldungen auch ein Stack Trace ausgegeben wird

Ein Stack Trace ist umfangreich, kann aber für die entwicklungsseitige Fehleranalyse hilfreich sein.

Standardwert: FALSE

Logging.Mail

optionale Konfiguration einer Mailserver-Anbindung, wenn für Meldungen vom Typ "Warning" und/oder "Error" eine Statusmeldung per E-Mail verschickt wird

Die grundlegenden Verbindungsparameter entsprechen den Parametern unter Mailserver-Anbindung, beschränkt auf die für ausgehende Mails nutzbaren Schnittstellen oder Protokolle EWS, Graph, Gmail und SMTP. Hinzu kommen nachfolgende Eigenschaften, die spezifisch für diesen Kontext sind.

Logging.Mail.From(*)

Mail-Adresse des Absenders

Diese Eigenschaft ist nur für das SMTP-Protokoll relevant. In allen anderen Fällen wird die Mail-Adresse implizit anhand der Benutzeranmeldung gesetzt.

Logging.Mail.To[]*

Logging.Mail.Cc[]

Logging.Mail.Bcc[]

Mail-Adressen der primären Empfänger und der optionalen CC-/BCC-Empfänger

Logging.Mail.Subject

Logging.Mail.Body

individuelle Inhalte des Betreff-Feldes und des Nachrichtentextes

Beide Felder sind mit einem Standardtext vorbelegt.

Folgende Variablen sind nutzbar:

%EventType%: Art des Ereignisses, d.h. "Warning" oder "Error"
%Scope%: Detailinformationen zum Kontext des Auftretens
%Message%: Meldungstext

Logging.Mail.EventIdFilter

Logging.Mail.TextFilter

optionale Filter für Ereignisklassen und Textinhalte

Syntax: siehe Syntax von Namensfiltern

Diese Filter beschränken den Mail-Versand auf Meldungen bestimmter Ereignisklassen oder Textinhalte oder klammern bestimmte, nicht relevante Meldungen explizit aus.

Logging.Mail.ErrorsOnly

Wahrheitswert, ob der Mail-Versand nur für Meldungen vom Typ "Error" erfolgen soll

Für Meldungen vom Typ "Warning" werden dann keine E-Mails versendet.

Standardwert: TRUE

Logging.Mail.LogBufferSize

maximale Anzahl von Logzeilen, die zwischengespeichert werden

Um weitere Kontextinformationen zu einem Fehler zu liefern, können Log-Meldungen, die vor dem Fehlerauftritt generiert wurden, intern zwischengespeichert und als Dateianlage an die E-Mail angefügt werden.

Standardwert: 0 (Zwischenspeicherung ist inaktiv)

In diesem Abschnitt:

xSuite Interface Windows Prism 5.x – Online-Hilfe

Logging

Suchresultat