There are more topics I would like to talk about on the BI Publisher logging & debugging. Especially there is now a new feature that allows you to enable the 'Report Generation Logging’ option at each report template level. So instead of enabling the logging feature at the server level you can quickly and easily enable the logging feature only for the report you are working without asking for your system administrator’s help!
Also, sometimes you might wonder what exactly the property values are coming to the RTF template. So I also will talk about this in this post. So let’s start with the ‘Report Level Logging Feature’!
Report Generation Logging Option at Report Level
This is a new feature that has been introduced recently with either October or November patch set release. This gives you an option to set if you want to enable the logging and what level of information at the report template level.
I have talked about how to enable the reports generation logging before and that is a setting at the BI Publisher server level. So if you have enabled the feature then all the reports start generating the log when they run.
While enabling the logging feature at the server level is useful when you want to debug all the reports at a testing environment, it might not be ideal when you want to debug only a particular report without impacting other reports’ performance. In order to turn on or off the logging feature at the server level you need to restart the server, which again might not be ideal when you need to find and ask the system administrator and wait for the next restarting schedule.
With this report level setting you can simply enable the report logging feature only for the reports you’re interested in and no need to wait for the server restart.
How to Set the Logging at Report Level?
You can simply add a BI Publisher command called ‘xdo-debug-level’ in your RTF template. Here is an example.
The ‘debug-level’ should be replaced by one of the following options.
- STATEMENT - This log write all the reporting running process information.
- PROCEDURE - This will log only the procedure level information. This is required to measure the time consumed per each process.
- ERROR - This will log only the error related information.
- OFF - This will not log any information.
The debug_level value is not case sensitive so it can be either upper or lower case. For example,
The debug log directory will be generated in one of the following locations:
- <java.io.tmpdir>/xdodebug (if system-temp-dir is not defined
Again, this setting can be done at the template level, this mean you can either modify the existing RTF template by adding the above command or create a new template which contains only the above command if you’re interested only in debugging the data model or parameter values generation part.
How about XSL Template?
If you are using the XSL Template instead, then you can add ‘<!--xdo-debug-level="statement"-->’ in the first 500 character of the template file.
How to See What Property Values are Passed in RTF Template?
Sometimes you wonder what exactly the values are passed to your RTF template. For example, when you set a custom variable at the server level and try to get the value to do a further operation in the template, it might work or not work the way you wanted. And you want to see if the value is really set and being passed to your template.
There is a very useful command to address this concern. You can simply type the following command in your template.
And you can upload the template and run from the BI Publisher Server UI. You should get something like below in your report output.
All the above variables are available for you to use in your RTF template. And you can see the values if they are the ones you were expecting or not.