Logging Events in LogicNets

Introduction to Logging

Logging for security, auditability, troubleshooting, and other uses is very important in any system, and this article summarizes the logging associated with LogicNets' solution. The following lists logging mechanisms in place starting with those events closest to the business process/solution. Note that infrastructure logging is relevant for hosted installations only.

• Business Event Logging, both automatic and customizable
• Application Logging, including extended logging of webservice calls
• Session, Trace, and LogicNets Log Files
• Debug Logging
• IIS/Server Logging
• Windows Event Logging
• Infrastructure Logging

Business Event Logging

Within the business logic built in logicnets, you can create a custom logging event at any place in the process using the Add to Changelog process part. Using this part adds the key and value to the changelog every time the node is traversed. Examples of when you might want to use this part include the following: 

• To store a calculated value*.
• To store a piece of meta data associated with the session but not directly input* by the user (day of week, department, user's cost center, for example).
• To store an "event" when a user selects a specific menu option.

* When you select Enable usage logging for Assessment Framework applications, the system automatically adds all user inputs (form parts) to the changelog, so you do not have to model additional logic to include those variables in an event log.

Some other processing steps offer the opportunity to add their key/value (data object and stored result) to the event log as a part option. Set data object has this feature, and you can use this part as a second step to another other process part that does not offer logging directly as a part configuration option. As an example, the system does not automatically add the result of date calculations to the log, but you can use set data object for this purpose.

The result of logging of this nature is to create a series of records that summarize the business selections made, and you can use this data to create reports and charts by modeling additional views using the LogicNets Reporting Framework. You can make these reports available under their own LogicNets application or incorporate them into the Standard Reporting package.

Application Logging

In addition to any custom or user input logging from above, LogicNets records a set of security-focused events in the following categories:

• Client Requests and Server Responses, such as a webservice URL requested and the response
• Account Information, such as successful or failed authentication attempts
• System Usage Information, such as the number of transactions or sessions 
• Significant Operational Actions, such as application start up and shut down

Release 8.1 includes an extensive list of new security events generated within the LogicNets standard Access Management package, and those are listed here. All of these application/security events are posted to the changelog, and you can review and download them in the Standard Reporting package. 

Together with existing events, LogicNets also supports the NIST 800-92 guideline. More information on that is available here.

LogicNets stores these events for backup and security purposes in a separate file in JSON format.

Extended Logging for Web Service Calls

LogicNets offers extended logging for web service calls. See this article for more information.

Session, Trace, and LogicNets Error Log Files

During runtime, the LogicNets engine creates several files in the logicnets installation:

• session files. The system creates these in the .../[company]/dat/bnt/ses folder and writes them in binary format for performance and security reasons by default. You can change this in the config.sys file; see Binary Session Files for more information. This folder also contains any temporary session tables generated by the client application.
  The system reads and writes to session files on every click. These files contain the latest snapshot of the context (data model structure and values) and other settings used by the LogicNets engine.
• trace files. These are located in the .../[company]/dat/bnt/trace folder and detail the sequence of steps taken by the LogicNets engine.
• error log. The system creates these files in the .../[company]/dat/bnt/log folder, and they consist of entries when there has been an error during runtime; for example,  a database SELECT statement error.

The system removes these files from the logicnets installation folder on a daily basis after the identified retention period. The default retention period is 7 days but that can be configured differently; see Log, Session, and Trace File cleanup for details..

Debug Logging

For those more technically advanced users of LogicNets' on-premise installations, it is possible to add debug log events that show in debugger logs, such as those collected by dbgview.exe. You add such events using the Debug Logging part. Note: This is for on-premise installations only. For more details about viewing debug logs on the server,  see Debug Logging.

IIS Server Logging

You can configure IIS server logs in the IIS Manager view them in the logs in the ../windows/system/inetpub folder. These log events are useful to review when checking what LogicNets processes have been running.

Windows Event Logging

While not LogicNets specific, windows event logs can sometimes be useful to see what caused a machine crash or other unexpected event. These are available through the standard Microsoft Windows Event Manager.

Infrastructure Logging for Hosted Installations

For LogicNets-hosted environments, we monitor and track a wide range of events associated with the WAF, Load Balancer, and other infrastructure components. If you would like to understand more about this or have questions regarding your on-premise installation, please contact your LogicNets Project Manager.

Changelog Table

The data.db contains the changelog table, which stores business and application logging events and serves as the source of data for the Standard Reporting package. For actively used applications, this table grows over time, slowing data manipulation speeds. To move/manipulate data faster and potentially merge data from multiple sources, you can create a cron job that periodically moves data from here to an enterprise database. See Move changelog Data to Enterprise Database with a Cron Job for more details.