Business Objects Classic Logging and Standard Tracing
If you have ever had a serious issue with your Business Objects environment that wasn’t easily fixed by a service pack, fix pack, or limited availability fix then you probably have had to enable logging on some or even all of your BusinessObjects servers. This is also frequently referred to as “tracing”. I’d like to discuss this briefly, but I want to say up-front that this article is not intended to replace any instructions you receive from SAP BO. Hopefully, it will just confirm information you receive from them, give you something to experiment with, or even prompt some deeper discussion between you and your BO Support engineer.
-Trace, or Dash Trace
I believe that -Trace is new to BO with the roll-out of BOXI, or Business Objects XI. My sources say that it comes from the “Crystal” technology and their for it has its own features and limitations. For this reason it may be especially useful on a BO WebI Report Server server with a particular issue, but on a different environment with a different Web Intelligence Report Server problem it may be useless. In my experience “-trace” can drastically impact performance depending on usage of the BO server and the limiters placed on the “-trace“.
It is called “-trace” because that is the name of the parameter that is used in the BO server’s command line to enable the tracing or logging. By the way, the command line parameters of BO servers/services are edited through CCM on the server. The parameter itself accepts no settings, but I believe that additional parameters can place configurations and limits on the trace logging (for example, “-maxlogfilesize“).
All of the tracing log files will be placed in the “\Program Files\Business Objects\BusinessObjects Enterprise 11.5\Logging” directory. So this can be a problem if the hard drive to which BO is installed does not have much room on it. It seems that by default BO servers are always doing some light tracing/logging to this folder. Once you begin “-trace” logging, you should see a huge spike in the file sizes and the file names should correspond to their servers more or less.
Business Objects Classic Logging, BO Classic Logging
Although BO was migrated to the Crystal platform we know that some fundamentals and tools remained virtually unchanged (for example Designer). Apparently under the hood there are still some things that can only be examined with what is now called “BO Classic Logging”. Apparently this is usually only for servers such as WebI Report Servers.
BO Classic Trace Logging is enabled through a collection of manual configurations on the server. The settings below are representative of possible settings, an example. If you are testing this out you could use these settings, but I would not place them in your “production” environment without consulting BO or some additional authority.
Create the following environment variables on the server:
- BO_TRACE_CONFIGFILE
Set this variable equal to the complete path to a file on your server, such asC:\Logs\BO_Trace.ini - BO_TRACE_LOGDIR
Set this variable equal to the complete path to a folder on your server, such asC:\Logs
Create the following environment variables on the server:
- Create a file named “BO_Trace.ini”. I think it can have any name that corresponds to the environment variable value and it must be placed in the location specified by the environment vairable value as well.
- In the file place the following code:
if (name == "busobj") {
active = true;
size = 100 * 1000;
keep = true;
importance = xs;
}
With either flavor of tracing or logging you will need to stop and start the affected BO servers in order to have the tracing take effect. In fact, to “-trace” logging you will need to stop the service first to make the command line parameter addition. You will need to monitor disk space constantly so that this doesn’t bring down your Business Objects environment. Since these are text files, the files compress rather well. Expect many similar sized files that have the start time/date stamp in the file name. Keep in mind that these will be on the server’s timezone and a file dated in the file name as Jan 19th can easily have data for Jan 19th, 20th, and 21st depending on your environment’s activity.
Note: Watch the sub-directory that is created with the name “wicdztrace”. This directory fills up with lots and lots of small files. They are a mess and will need to me deleted often.
Conclusions
Remember, now you know enough to be dangerous. I can’t support you if you crash your system with this. Test it out and engage BO and demand that they help you configure your logging to meet their needs and yours.
[...] Some of you may have that handy-dandy Business Objects error code cross-reference document (I should see about sharing it next time I find it) and you are thinking these error codes can be found there. Sorry, nice try, wrong, thanks for playing. Failing that look-up I asked around and this is what I found out: Very Short Answer: nothing Short Answer: they can only be used in deep debugging analysis Long Answer: Those error codes are internal Web Intelligence error codes which depend on the workflow followed and on the specific API which failed. The error codes should be able to be referenced in the trace logs produced through active “-trace” logging on the corresponding WebI Report Server (more on this topic in our article “Business Objects Classic Logging and Standard Tracing“). [...]
Hi,
Good post Julian.
I want to know the complete command to enable tracing for WebIntelligence Processing Server.
Or the complete steps for the same. Can you please reply asap.
Hi Ani,
If you are asking for all of the options then I can offer you this:
// Default values (for all processes)
//
//
// active: trace is enabled for current process if active is true
// ____________________________________________________________________________
//
//active = false; default value is false
// possible values are false, true
//
//
//
// importance: importance threshold over which messages can be traced
// ____________________________________________________________________________
//importance = m; default value is m (ie '==')
// possible values are '< <','<=','==','>=','>>'
// and xs, s, m, l, xl
// '< <' is the most disk consuming choice
//
// alert: auto activation of severe traces is enabled for if alert is true
// ____________________________________________________________________________
//alert = true; default value is true
// possible values are false, true
//
// severity: severity threshold over which messages can be traced
// ____________________________________________________________________________
//severity = 'E'; default value is error (ie 'E')
// possible values are ' ','W','E','A'
// and success, warning, error, assert
// ' ' is the most disk consuming choice
//
// size: maximal size (in messages) over which a new _trace.log file is created
// ____________________________________________________________________________
//size = 100000; default value is 100000 (approx 10MB)
// possible values are integers >= 10
// warning: size = 5; results in size being 10
//
// keep: when a new _trace.log file is created, the last old _trace.log is kept
// ____________________________________________________________________________
//keep = false; default value is false
// possible values are false, true
//
// consultant: annotation of output log file by consultant
// ____________________________________________________________________________
//consultant = "hello"; default value is ""
// this string will be inserted into log file
// if (display_mask & consultant_mask) != 0
Can you tell me what the S and L are in above importance option? XS is extra severe? Extra small trace? etc. How do you know what level may be necessary for what you are looking for?
Hi Bill, I don’t have the specifics, but “xs” stands for “extra small”, meaning the least amount of trace logging. As you can guess the rest proceed in increasing logging levels, just like clothing sizes, with “l” being the most verbose level of logging… or so I think.