Field Help for Logs Page 
SAP Sourcing maintains log files as a diagnostic tool during normal operation. In general, little is logged beyond server startup. Messages that are logged include the date and time, along with an indicator of whether the message indicates an error or is simply informational. Periodic review of the log files is an important step in issue isolation, as well as an important preventive step to identify warning conditions before problems occur.
Maximum Log File Size (kb)
Log files have a configured maximum size. When this size is exceeded, the file is closed and a new log file is created. Background processing can remove old log files. This technique prevents system logging from consuming all available hard disk storage space, but when errors occur it is not unusual to see multiple sequential log files.
The maximum log file size can be changed on the Logs page by the system administrator.
Note
The following when changing log file size:
If there are multiple systems, the maximum log file size must be set for each system.
The maximum log file size set in this manner is temporary and will reset to the default size defined in fcisystem.properties when the system is restarted.
The minimum log file size is 1024 KB. This minimum is to prevent users from setting an abnormally low log file size, causing the system to spend an excessive amount of time initializing log files.
Accessing Log Files
Log Files can be accessed from the "logs" subdirectory in the application home of the application server(s). For administrators that do not have direct access to the server file systems, log files can also be accessed from the System Information page. The Logs tab displays the available log files, and provides a Download link for each, allowing an administrator to access the log files from a browser.
Errors
Periodically, scan the most recent log files for the string "ERROR". If errors are being logged in your system, they should be brought to the attention of SAP Technical Support. In some cases, the software may have degraded gracefully after the error, leaving the original operator unaware that a problem occurred. Scanning the logs helps to identify these conditions.
Query Performance
In addition to errors, the system will automatically log SQL statements that exceed a pre-configured execution time limit. This is often an early indicator of performance issues. Scan the log files for Start SQL Execute. If you find multiple occurrences, contact SAP Technical Support with the log files available.
Logging Modes
The System Information page provides the ability to change both the diagnostic and SQL logging settings. Changing these settings will log an extremely large amount of data and materially affect performance, and should only be done temporarily under the specific guidance of SAP Technical Support.
Logging Severities
The application log uses the following standard types of logging severities:
Info
Warning
Error
Alert
Critical
Debug
Alerts
SAP Sourcing logs three different types of alerts to the application log. An alert indicates an event that may require immediate action. However, some events may occur as part of the normal operation of the system. The three alerts that are currently logged by the system are:
Slow Transaction Alert: Any database transaction that takes more than
<threshold>seconds to complete. The default threshold is 10 seconds.Slow Page Alert: Any user page that takes more than
<threshold>to complete. The default threshold is 15 seconds.Low Memory Alert: Any moment that
<threshold>percentage of available memory is used. The default threshold is 90%.
The amount of memory used is computed using the currently allocated memory as a percentage of the total memory heap size currently available. Java can be configured with a dynamic heap size specifying a initial starting heap size and a maximum heap size. For our hosted customers, the minimum heap size is set to 512Mb and the maximum heap size is set to 1024Mb. The Java virtual machine can dynamically increase the heap size as needed.
The Java virtual machine is also responsible for freeing up unused memory in a process known as garbage collection (GC). Often the JVM will not expand the heap of available memory or clean up unused memory until 90% of the current memory is allocated. This has the side affect of causing low memory alerts to be logged. Low memory alerts should be monitored but are generally not an issue unless several (10-20) alerts occur in a short period of time, the heap has been extended to its maximum value, and any garbage collections activities fail to free up memory. This scenario indicates that all memory is being used and there is none available for the application to continue.
Low memory alerts logged before the heap size is extended or prior to a successful garbage collection are considered normal operation of the application.