Log Level Slider
The log level slider turns logs off and on and can control the level of logging. Changing the slider position changes the logging level and this change is effective immediately. The image above is just the Application level log slider from the “Application Logs” screen.
Log levels exist both at the Application and the Entity (webpart, process, workflow) level. This allows users to turn off logs for the entire application, but then turn logs on for a single process which needs debugging or is currently being developed. The image above is the log level sliders that are available on the log tab of a process. The App Level still controls the entire application, but the Entity Level slider controls the particular process that is currently open.
Logs can be either written to the database in a designated log table (EP_Logs) or written to a text file in the LogFiles folder of the Toolset for the environment. The “Fatal”, “Error”, and “Info” level logs are written to the SQL database and “Debug” and “Trace” are written to the text file. Below are examples of both types of logs.
The logs that show in the Application logs screen are useful because they are viewable through EASYProcess which provides an easy to use UI to traverse through the XML. However, the logs are not written to the EP_Logs table until the process completes. This means if the process fails to complete, the logs will never be written. In this case, logs written to the text file can be more useful to debug issues that the Application Logs written to the database cannot. The drawback of the text file is that it must be opened by finding the file in a file explorer and opening in a text editing application. The tools available to traverse through logs in EASYProcess, will not be available.
With “Off” at the far left and “All” at the far right, each level in between shows a more detailed view of what is occurring on the application. Each log level contains the previous lower levels of logs as well. For example, if the slider is set to “Info”, it will also show “Error” and “Fatal” level logs. If it is set to “All”, it will show “Fatal”, “Error”, “Info”, “Debug”, and “Trace” level logs.
This turns off all logging. No logging will be recorded in the SQL tables to be displayed in the Application Logs screen or written to the log text file.
When the slider is set to “Fatal” only logs considered fatal will be written to the database and shown in the Application Logs screen. Fatal logs are shown in red in the Application Logs screen.
Fatal logs are reported by internal use processes or subsystems. These are failures which cause application failures. You should never see Fatal logs returned from a process or webpart logs because if a process does not run or webpart does not load, it will not make the whole system go down. An example of a fatal log is when a batch job cannot run due to an error or when the system is set to monitor that the database connection to JDE is up, but it goes down.
When the slider is set to “Error” logs considered either “Fatal” or “Error” level will be written to the database and shown in the Application Logs screen. “Error” logs are shown in red in the Application Logs screen. “Error” level logs are exceptions that occur when some component of a process or webpart fail as a result of failed queries or unexpected input in process services. These sort of exceptions can cause unexpected outcomes in logic of processes or the display of webparts, but these are not application failures.
When you click on the log record in the Application Logs screen, a panel will show you more information about the error. Below is an example of JDE Business Function (BSFN) call which failed due to the BSFN Java Server not running, so the request timed out. This call is made in a pricing process. On the page a user wanted to look up an item and so the request was made to price the item so it could be shown on the page. This failure could cause the page that would have displayed the price to have a blank value instead.
Below is another Error level logs example This occurred when a SQL query ran against the JDE database with too wide of a filter range. The number or records that would be returned or the time it would take to return those records was too large and so JDE would not attempt to return the requested results. This query was run when the user on the site clicked on their order history. This failure could cause the order history page to display an error message indicating an error occurred and the order history cannot be displayed.
When the slider is set to “Info” logs considered either “Fatal”, “Error”, or “Info” will be written to the database and shown in the Application Logs screen. “Info” level logs are all the log for the webpart, webpage, process, or workflow which ran. “Info” logs are shown in green in the Application Logs screen.
When you click on the log record in the Application Logs screen, a panel will show you more information about the Info log. The below example is of a process log. Clicking on the WorkData level gives you all the xml for the process that ran. It is broken down by the processes and is displayed in the order they ran. In this example you can see the WorkData level is selected and the panel displays lots of text and has a scrollbar to see it all.
You could also click on individual services that ran in the process and expand services to see the child nodes. Below is that same process, but with a service expanded and the service selected to show that the child nodes are both present in xml on the right panel and shown in a tree view on the left.
When the slider is set to “Debug” logs considered either “Fatal”, “Error”, or “Info” will be written to the database and shown in the Application Logs screen. This is also the first level which controls the text file logs. At the “Debug” level, everything that happens is logged. Data at the beginning and end of each webpart, process, onload, API, etc, will be written to a text file. It also prints out running requests. When the Enterprise Server receives a request, it assigns it an Id. Every 30 seconds, it will print out the running requests. These Enterprise Server logs will print memory usage which can be used to follow a memory leak (which request is causing it). These text files are saved in the LogFiles folder of the Toolset of the environment.
Having “Debug” level logs on does add processing time to the application running, but this is an acceptable performance hit. It should not always be on, but could be turned on momentarily to debug an issue. This could be done in a production environment actively in use if it is monitored and turned off when no longer needed.
This is useful when an error is causing the process/webpart/page load to start, but not finish. Since logs are only written to the database upon the completion of the run, if it fails to complete, no logs will be shown in the Application Logs screen.
For example, if a process that runs on a page load contains an infinite loop, it will never complete, so the page will never load. It will also overload and crash the Enterprise Server, which is needed to run EASYProcess. So debugging the issue in EASYProcess alone can very difficult because as soon as the page is loaded, the infinite loop begins and crashes the Enterprise Server Service, which makes using EASYProcess not possible. Instead, you could set the application level logs to Debug, then load the page. You can then open the text file to find the last thing that started, but did not finish. This will tell the developer troubleshooting the issue where to look for the cause.
Here is an example of what the logs look like from within the text file when a single process has “Debug” mode on and is run once:
2019/01/05 15:17:37:4797935 - 01 --> DEBUG : ProcessHtml_Execute : Process started. Process Id:PRC-10000464
2019/01/05 15:17:37:6204159 - 01 --> DEBUG : Process_Execute : Process Ended. Process Id:PRC-10000464
Here is a screenshot of the text file when the entire application was set to “Debug” mode. These are logs from just a few seconds of an application actively in use. These requests are all API calls and the corresponding processes running. Some of those contain JDE Business Function (BSFN) calls.
Here is another screenshot when a webpage was loaded. These logs include web requests, webpart datasources, webpart section onload processes, and further process calls from within the webpart processes. These are logs from loading a site and logging in.
When the slider is set to “Trace” logs considered either “Fatal”, “Error”, or “Info” will be written to the database and shown in the Application Logs screen. This also does all the same actions “Debug” does to the text file, but it also provides all the input and output xml, similar to what usually gets written to the database and shown in the “Info” level logs. The difference is that the input and output XML here is not just what is returned to WorkData in the “Info” logs. It also contains the properties of the services that run and input xml that EASYProcess may use, but not return in the output logs. Since it give lots of very detailed data, this level of insight into the application is rarely needed. This is only recommended for expert developers and for a temporary time only.
Having “Trace” level logs on is a much bigger hit on performance than “Debug”. It should not be turned on in production because it will impact performance of the site for the users. It also should not be turned on in an application that is used by multiple users, because the logs generated are so plentiful that it can already be difficult to follow the process flow in text file when there is just one process running from a single user’s API/process/webpage navigation.
The “Trace” level creates lots of logs very fast, which, if left on, can cause disk space issues on the server.
As mentioned previously, all the information written to the text file at the “Debug” level is still written, but with the added volume of logs for “Trace”, the text file will now contain mostly “Trace” log lines. See below, an example of a Debug entry among many Trace entries. Debug logs that the process was started and for each service in the process, Trace will log a line to record the input and output XML. You can see the evidence of this below as the Debug notifies us that PRC469 has started. This is immediately follow by Tace returning the “Start” service XML.
The “All” level is the same as “Trace”. Having an “All” is just for UI purposes to give EASYProcess an easy way to display the max level without requiring users to understand what “Trace” means.