Logging

Different targets canbe defined for logging. Target systems can be used alternatively, or in parallel.

If an error occurs during program start while the configuration data is being read, the desired logging options may also not yet be read successfully. In this case, the error message is written to the Windows Event Viewer and the log file xSuiteInterface5.log. If write permissions are available, this log file will be created directly in the program directory. If there are no write permissions, the file will be created in the temporary directory of the executing user account.

Console
Windows Event Viewer
Log file xSuiteInterface5.log
If there are no write permissions, the file will be created in the temporary directory of the executing user account.

Only error messages that occur during startup are written to the Windows Event Viewer and the log file. In the console, both error messages and other messages are written.

If the Windows service has problems starting, it can be helpful to first run the program as a console application and check the error messages displayed there. It should be noted that different user accounts are usually used for the two types of execution. The different types of execution types might lead to different kinds of behavior in the program (e.g., due to different authorizations or missing drive links in the context of the service account).

Property	Description
Logging.Level	Level of logging detail in descending order: `Trace` `Debug` `Information` (default value) `Warning` `Error` `None` Use the `Trace` level only temporarily for problem analysis. When this level is used, log entries are generated permanently, even if no data is pending processing. The `Debug` level generates significantly more detailed information than the default value. With sufficient memory (including through regular deletion of older log data), this level can still remain activated for a longer period of time.
Logging.File	Path of the log file, if logging is written to a file By including the variables `%Date%`, `%Tenant%` and `%Category%`, folder names and file names can be generated dynamically, meaning that logging can be broken down into separate files according to these criteria. If logs are not separated by tenant (`%Tenant%`) and category (`%Category%`), this information is written to the log text instead. The category here is an identifier describing the worker type or the web service type that generated a log entry. In the case of a worker, the identifier is supplemented by the worker instance number. The variables `%WorkerName%` and `%Scenario%` can also be used. However, these variables are not always assigned a value. Therefore, different log file names might result, some with a variable value already set and some without a variable value. The "WorkerName" can only be used for configuring worker instances and scheduler instances (properties `Worker [].Name` and `Schedule[].Name`). A "Scenario" context is generally only available for workers. However, workers also have log messages that are independent of the scenario.
Logging.OpenFileInNpp	Boolean value defining whether the log files created via `Logging.File` are automatically opened in the text editor Notepad++ Default value: `TRUE` Prerequisites: Notepad++ is installed locally on the system. xSuite Interface is executed as a console application under Microsoft Windows. This option is not designed for ongoing operation. The automatic opening of files in the text editor provides support when creating a new configuration and when analyzing problems. If this option is used, a new instance of the text editor will be started and each log file will be opened in this instance the first time it is used within the current program run. The file is opened in monitoring mode. In this mode, the display is automatically updated each time the file is changed. The file display in the text editor therefore behaves in a similar way to the continuous log output in the console window. However, in contrast to the display in the console window, the information of all worker instances running in parallel is not displayed in the same window. If the log files are separated accordingly, the files for each worker are displayed in a separate editor tab. This makes the log output easier to read.
Logging.Database	Configuration of a database connection if log data is to be written to a database table (optional) The configuration properties and supported database systems correspond to those under the `Database` property for the internal administrative database (see Administrative Database). If the same internal database connection is used for logging as it is for the other administrative data, the database connection already configured can be referenced at this point. To do this, set the `Logging.Database.Type` property to the value `Internal`. The display of log entries the Status Monitor is based on database logging (see property `StatusService.Activate`). To use this feature, enable database logging. Logging via the internal connection with `Logging.Database.Type: "Internal"` is performed by tenant into the respective database. Only global entries are written into a separate database with the pseudo-tenant-name "Global." When logging to an external database, xSuite Interface does not separate by tenant. All entries end up in the same table and can only be distinguished via a corresponding table field. Furthermore, such log entries cannot be viewed via the internal Status Monitor, and an internal macro function for deleting old log entries cannot access the external database either.
Logging.ToConsole	Boolean value determining whether, if the program is executed as a console application, log data will be output in the console window Default value: `TRUE`
Logging.ToEventLog	Boolean value determining whether log data will be output in the Windows Event Viewer This one output of log data is basically limited to messages of the types "Warning" and "Error." Default value: `TRUE`
Logging.EventLogErrorsOnly	Boolean value determining whether the output of log data in the Windows event display should only be sent for messages of type "Error" (and not for "Warning" too) Default value: `TRUE`
Logging.LogStackTrace	Boolean value determining whether a stack trace will also be output for error messages A stack trace is extensive, but can be useful for analysis of errors in development. Default value: `TRUE`
Logging.Mail	Configuration of a mail server connection if a status message is sent by email for messages of type "Warning" and/or "Error" (optional) The basic connection parameters are the same as those found at Mail Server Connection, limited to the interfaces or protocols that can be used for outgoing email, EWS, Graph,Gmail and SMTP, plus properties that are specific to this context (listed below).
Logging.Mail.From(*)	Email address of the sender This property only applies to the SMTP protocol; in all other cases, the email address is set implicitly based on the user login.
Logging.Mail.To[]* Logging.Mail.Cc[] Logging.Mail.Bcc[]	Mail addresses of the primary recipients and the optional CC/BCC recipients
Logging.Mail.Subject Logging.Mail.Body	Individual contents of the subject field and the message text Both fields are preset with a default text. The following variables can be used: `%EventType%`: type of event (i.e., "Warning" or "Error") `%Scope%`: detailed information about the context of the occurrence `%Message%`: message text
Logging.Mail.EventIdFilter Logging.Mail.TextFilter	Filters for event classes and text contents (optional) Syntax: see Name Filter Syntax These filters restrict email dispatch to messages of certain event classes or text contents, or explicitly exclude messages that are irrelevant.
Logging.Mail.ErrorsOnly	Boolean value determining whether the email should only be sent for messages of type "Error" No emails are then sent for messages of the "Warning" type. Default value: `TRUE`
Logging.Mail.LogBufferSize	Maximum number of log lines cached To provide additional contextual information regarding an error, log messages generated prior to the occurrence of the error can be cached internally and attached to the email as a file attachment. Default value: `0` (with inactive caching)

Property

Description

Logging.Level

Level of logging detail in descending order:

Trace
Debug
Information (default value)
Warning
Error
None

Use the Trace level only temporarily for problem analysis. When this level is used, log entries are generated permanently, even if no data is pending processing.

The Debug level generates significantly more detailed information than the default value. With sufficient memory (including through regular deletion of older log data), this level can still remain activated for a longer period of time.

Logging.File

Path of the log file, if logging is written to a file

By including the variables %Date%, %Tenant% and %Category%, folder names and file names can be generated dynamically, meaning that logging can be broken down into separate files according to these criteria. If logs are not separated by tenant (%Tenant%) and category (%Category%), this information is written to the log text instead. The category here is an identifier describing the worker type or the web service type that generated a log entry. In the case of a worker, the identifier is supplemented by the worker instance number.

The variables %WorkerName% and %Scenario% can also be used. However, these variables are not always assigned a value. Therefore, different log file names might result, some with a variable value already set and some without a variable value. The "WorkerName" can only be used for configuring worker instances and scheduler instances (properties Worker [].Name and Schedule[].Name). A "Scenario" context is generally only available for workers. However, workers also have log messages that are independent of the scenario.

Logging.OpenFileInNpp

Boolean value defining whether the log files created via Logging.File are automatically opened in the text editor Notepad++

Default value: TRUE

Prerequisites:

Notepad++ is installed locally on the system.
xSuite Interface is executed as a console application under Microsoft Windows.

This option is not designed for ongoing operation. The automatic opening of files in the text editor provides support when creating a new configuration and when analyzing problems. If this option is used, a new instance of the text editor will be started and each log file will be opened in this instance the first time it is used within the current program run.

The file is opened in monitoring mode. In this mode, the display is automatically updated each time the file is changed. The file display in the text editor therefore behaves in a similar way to the continuous log output in the console window. However, in contrast to the display in the console window, the information of all worker instances running in parallel is not displayed in the same window. If the log files are separated accordingly, the files for each worker are displayed in a separate editor tab. This makes the log output easier to read.

Logging.Database

Configuration of a database connection if log data is to be written to a database table (optional)

The configuration properties and supported database systems correspond to those under the Database property for the internal administrative database (see Administrative Database). If the same internal database connection is used for logging as it is for the other administrative data, the database connection already configured can be referenced at this point. To do this, set the Logging.Database.Type property to the value Internal.

The display of log entries the Status Monitor is based on database logging (see property StatusService.Activate). To use this feature, enable database logging.

Logging via the internal connection with Logging.Database.Type: "Internal" is performed by tenant into the respective database. Only global entries are written into a separate database with the pseudo-tenant-name "Global."

When logging to an external database, xSuite Interface does not separate by tenant. All entries end up in the same table and can only be distinguished via a corresponding table field. Furthermore, such log entries cannot be viewed via the internal Status Monitor, and an internal macro function for deleting old log entries cannot access the external database either.

Logging.ToConsole

Boolean value determining whether, if the program is executed as a console application, log data will be output in the console window

Default value: TRUE

Logging.ToEventLog

Boolean value determining whether log data will be output in the Windows Event Viewer

This one output of log data is basically limited to messages of the types "Warning" and "Error."

Default value: TRUE

Logging.EventLogErrorsOnly

Boolean value determining whether the output of log data in the Windows event display should only be sent for messages of type "Error" (and not for "Warning" too)

Default value: TRUE

Logging.LogStackTrace

Boolean value determining whether a stack trace will also be output for error messages

A stack trace is extensive, but can be useful for analysis of errors in development.

Default value: TRUE

Logging.Mail

Configuration of a mail server connection if a status message is sent by email for messages of type "Warning" and/or "Error" (optional)

The basic connection parameters are the same as those found at Mail Server Connection, limited to the interfaces or protocols that can be used for outgoing email, EWS, Graph,Gmail and SMTP, plus properties that are specific to this context (listed below).

Logging.Mail.From(*)

Email address of the sender

This property only applies to the SMTP protocol; in all other cases, the email address is set implicitly based on the user login.

Logging.Mail.To[]*

Logging.Mail.Cc[]

Logging.Mail.Bcc[]

Mail addresses of the primary recipients and the optional CC/BCC recipients

Logging.Mail.Subject

Logging.Mail.Body

Individual contents of the subject field and the message text

Both fields are preset with a default text.

The following variables can be used:

%EventType%: type of event (i.e., "Warning" or "Error")
%Scope%: detailed information about the context of the occurrence
%Message%: message text

Logging.Mail.EventIdFilter

Logging.Mail.TextFilter

Filters for event classes and text contents (optional)

Syntax: see Name Filter Syntax

These filters restrict email dispatch to messages of certain event classes or text contents, or explicitly exclude messages that are irrelevant.

Logging.Mail.ErrorsOnly

Boolean value determining whether the email should only be sent for messages of type "Error"

No emails are then sent for messages of the "Warning" type.

Default value: TRUE

Logging.Mail.LogBufferSize

Maximum number of log lines cached

To provide additional contextual information regarding an error, log messages generated prior to the occurrence of the error can be cached internally and attached to the email as a file attachment.

Default value: 0 (with inactive caching)

In this section:

xSuite Interface Windows Prism 5.x – Online Help

Logging

Search results