Event Logging Settings

Event logging settings can be found on the 'Application Monitoring' page of 'Global Settings'.

• Enabling of Event Logging

  In standard Valuemation, event logging is disabled by default. To enable it, set the 'Enabled' check box of 'Event Logging' settings to True.

• Privacy Settings

  Event logging tracks user behaviour and the corresponding response of the application. If having user behaviour registered constitutes a privacy breach in the given environment, it is possible to use privacy settings to obfuscate the user information or to exclude some users from event logging completely.

• Event Selection

  Click the 'More' button in 'Application Monitoring Settings' to see a list of events which can be selected for logging. The events can be divided into three categories:

  • Technical events
  • User Events
  • Errors

Important: The logging configuration made in Global Settings can also be made via Mainparameters. Using the Mainparameters catalog (look for path = 'eventlog'), it is possible to make the settings directly in Valuemation Web Client (i.e. without the need to switch to the Rich Client and then restart the web server). The changes apply immediately upon saving the catalog.

Questions of Privacy

As each of the logged events has a relation to the user, user-related information is part of event logging and user activity can be observed via the records. The following two settings can be used if revealing the activity of individual users is perceived as problematic:

• Encrypt User ID

  'Encrypt User ID' can be used to obfuscate user identity. If enabled, then the relation to the user is not stored with log entries. Only user login ID in an encrypted form is stored instead. As a result, only a hexadecimal string from which the actual user cannot be recognized can be seen as part of event log information.

• Exclude Users

  It is also possible to completely exclude some users from event logging. This can be used not only for users with a serious paranoia issues, but also to exclude so called "technical users", i.e. virtual users used by some application elements (such as the process engine or escalation), which could potentially create lots of data of little or no value for user behaviour analysis.

Technical Events

The first four event types in the Events list under 'Event Logging' are internal, background application events information about which can be used e.g. for performance analysis.

• SQL - SQL statements will be logged.

  SQL statement (SELECT/INSERT/UPDATE/DELETE/CREATE/DELETE..) most important information contains the statement text (including bind variables) and its duration. See 'Viewing Event Data' for more information.

• Workflow data - untranslated metaworkflow names will be logged

  A workflow is the runtime object based on a customized Metaworkflow. In addition to workflow name it is also important to know how it was started - from the sidebar/catalog/editor/relation (then its parent is an action), or as a subworkflow (then its parent is the workflow which started it).

• Workflow Activity - names of workflow activities will be logged

  A workflow activity is executed as part of a workflow execution (e.g. OpenCatalogView, OpenBo, RunScript, SubworkflowActivity etc). It is also important to know the workflow that started the activity. Some important activities provide additional data in the event.

• Request - requests URL will be logged. Threshold should be set to a reasonably high time so that only significantly slow requests are logged.

  The most important information here is the request time, which is the interval between the time when the user clicks (i.e. the request is send to the server) and the request is finished (i.e. the response comes and the html page gets displayed). This time between clicking in the GUI and the response visible on the GUI is what the user perceives as application performance.

Technical events filtering

As a potentially overwhelming number of technical events is likely to get logged, filters can be used to restrict the logging only to events fulfilling a defined condition.

Two ways of event filtering are available:

• Filters - specify a regular expression which must be fulfilled by the event to get logged.

  For example, regular expression 'OpenBo|OpenCatalogView' used for workflow activities will result in only workflow activities named 'OpenBo' or 'OpenCatalogView' being logged. Regular expression '^((?!task=(img|push)).)*$' will result in all requests except for requests which handle displaying of images.

• Thresholds - specify event time (in ms). Only events taking longer than the specified time will get logged. The intended use is to focus only on events taking "suspiciously long".

User Events

User events are events triggered by application users. These can be used to analyze user activity such as which catalogs or actions are most commonly used, which windows switched to and in what sequence, etc. Information of this kind may be instrumental in ticket solving, it can also contribute to GUI optimization or predictive behaviour development. For instance, the need to switch windows too often may be a sign that GUI or user workflow changes should be considered.

User events provide no filtering, all events of the enabled type will be logged.

Errors

The standard place where all exceptions occurring during running the application are logged is the Valuemation log.

When the 'Error' check box under 'Event Logging' is selected, application exceptions are also part of event logging. This way exceptions are recorded in the database and listed in the 'Event Log' catalog. In comparison with standard Valuemation log, using 'Event Log' for errors has the following advantages:

• the information includes the context of the errors
• the information is searchable

See 'Viewing Event Data' for information on the 'Data' and 'Parameters' fields.