[Part 1 | OLAP Data Access Logging: Part 1 - Introduction and basic settings] - Introduction and basic settings
[Part 2 | OLAP Data Access Logging: Part 2 - Modules and Components] - Modules and Components
[Part 3 | OLAP Data Access Logging: Part 3 - API call timings] - API call timings
[Part 4 | OLAP Data Access Logging: Part 4 - Query logging] - Query logging
[Part 5 | OLAP Data Access Logging: Part 5 - Log Formatting] - Log Formatting
Part 6 - Assertions, Unix and 64 bit Windows
[Part 7 | OLAP Data Access Logging: Part 7 - Choosing the correct settings and example defaults] - Choosing the correct settings and example defaults
Full article also available in SDN's Article section here.
h1. Assertions
Assertions are used by developers to document assumptions about what state a program should be in when it is performing a particular operation. Assertions generally take the form of a logical test, for example the variable A should have a value greater than zero. The OLAP Data Access component has the facility to log when these assertions fail. This is generally a tool used by developers when a product is in development, but it can be a useful trouble shooting tool as it may highlight unusual or unexpected situations.
h2. Turning on assertions
By default assertions are turned off. For the results of failed assertions to be logged assertions must be turned on. This is done by adding a new key Asserts at the same level as the *Log key. The following table shows the location of this key for the different versions of the OLAP Data Access component.</p><table border="1" cellspacing="0" cellpadding="0"><tbody><tr><td width="85" valign="top"><p>Version</p></td><td width="572" valign="top"><p>Asserts location*
SOFA 11.5 | [HKEY_LOCAL_MACHINESOFTWAREBusiness ObjectsSuite 11.5OLAP IntelligenceOCCA(o)Asserts] |
SOFA 12 | [HKEY_LOCAL_MACHINESOFTWAREBusiness ObjectsSuite 12.0OLAP IntelligenceOCCA(o) Asserts] |
MDA 11.5 | [HKEY_LOCAL_MACHINESOFTWAREBusiness ObjectsSuite 11.5VoyagerMDA Asserts] |
MDA 12 | [HKEY_LOCAL_MACHINESOFTWAREBusiness ObjectsSuite 12.0MDA Asserts] |
The Asserts can contain two DWORD values. The first value Model specifies the version of the assertion model that should be used. The following table shows the possible values for Model and explains what each model does.
Value
Description
0 | Off. No assertion tests will be performed |
1 | Log and continue. If the appropriate logging is enabled, any failed asserts will be logged and the program will continue. |
2 | |
Log and abort. If the appropriate logging is enabled, any failed asserts will be logged and the program will terminate. Caution this setting will cause your program to stop if an assertion fails. This should not be used in a production environment.
Message box (windows only). This will log a failed assertion if logging is enabled and pop up a windows message box. Caution the program will pause until a user clicks on the message box. This should not be used in a production environment.
4 | Windows event log (windows only). This will log a failed assertion to the windows event log and in the OLAP Data Access log if it is enabled. |
The second DWORD value available is StackDump. This has two possible values: *0 *and 1. A value of one will log out the call stack for any failed assertions. If the value is missing or has a value of 0 then no stack dumps will be logged. Caution: this setting has been associated with errors when the OLAP Data Access component is hosted by a JVM, for example when used by Voyager. These errors cause the JVM to crash so turning stack dumps on should not be used in a production environment.
An example registry for SOFA 12 would look as follows:
bq.
[HKEY_LOCAL_MACHINESOFTWAREBusiness ObjectsSuite 12.0OLAP IntelligenceOCCA(o)Asserts]
"Model"=dword:00000003
"StackDump"=dword:00000001
This sets the assertion model to 3, which pops up a message box. It also has stack dumps turned on.
h2. Turning on assertion logging
The logging of assertions is controlled by the addition of an *ASSERTION *registry key underneath the Modules folder. As with other logging modules the ASSERTION key should contain a DWORD value called Verbosity. The only available verbosities for assertion however are 0 and 1. That is to say assertion failures are either logged or not. An example registry setting for SOFA 12 would be as follows:
bq.
[HKEY_LOCAL_MACHINESOFTWAREBusiness ObjectsSuite 12.0OLAP IntelligenceOCCA(o)LogModulesASSERTION]
"Verbosity"=dword:00000001
This will turn assertion logging on.
h1. UNIX
UNIX deployments of Business Objects software will obviously not have access to a Windows registry in order to read the configurations for OLAP Data Access logging. However Business Objects does have a pseudo registry on UNIX which plays the same role as the windows registry. Business Objects uses the file system to represent the windows registry. Folders that you observe in the Windows registry will appear as folders in the UNIX file system. Registry values will appear in a file called .registry (note the filename starts with a dot ‘.'). For example, the following Windows registry key:In this folder there should be a file called .registry. The contents of this file should look similar to how a list of values would appear in a windows registry script. So for example if a verbosity value were required the contents of the file should look as follows:
bq.
"Verbosity"=dword:0000000a
The other file that should be in a folder that is part of the Business Objects registry is a file called .keyname (again, note the filename begins with a dot ‘.'). This file simply contains the name of the registry key. So if the folder was to represent the *ODBOMODULE *key, the contents of the file .keyname should be the text ODBOMODULE. The case of the text in the .keyname file should match the case of the name of the example key names given in this document. For example *ODBOMODULE *is all capital letters. However the names of the folders in the file structure need to be all lowercase.
To use the registry examples in this document on UNIX they must be converted to their UNIX form. This means creating the relevant folders and .keyname files for each new key that needs to be created and also adding the required values to the .registry file for each folder.
h2. Known issue with UNIX logging
There is a known issue with the way modules and components are initialized on UNIX systems. The issue means that some information may not be logged under the correct module or component. For example a line that would be logged under the SAPMODULE on a Windows system may appear under MDA_SUPPORT on UNIX. To ensure the required information is being logged it is suggested that logging is turned on by setting the verbosity value in the root Log folder first to see which modules information is being logged under. Logging can then be incrementally turned off as desired by adding in unwanted modules and components and setting the verbosity to zero.
h1. 64 bit Windows
If an installation of Business Objects is on a 64 bit Windows operating system, then the entries in the registry will be in a slightly different place. This is because the Business Objects installation is still a native 32 bit installation (it will be installed by default under the C:Program Files (x86) directory for example). Windows has a separate bit of the registry for applications that are natively 32 bit. The registry keys instead of being located under
bq.
[HKEY_LOCAL_MACHINESOFTWARE]
Are located under
bq.
[HKEY_LOCAL_MACHINESOFTWAREWow6432Node]
This means a registry key such as the following
bq.
[HKEY_LOCAL_MACHINESOFTWAREBusiness ObjectsSuite 12.0MDALog]
Becomes
bq.
[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeBusiness ObjectsSuite 12.0MDALog]
Therefore any of the example registry settings given in this document must be modified to include the additional Wow6432Node folder if they are being applied to a 64 bit system.</p>
