Skip to Content

OLAP Data Access Logging: Part 1 – Introduction and basic settings

Part 1 – Introduction and basic settings
OLAP Data Access Logging: Part 2 – Modules and Components – Modules and Components
OLAP Data Access Logging: Part 3 – API call timings – API call timings
OLAP Data Access Logging: Part 4 – Query logging – Query logging
OLAP Data Access Logging: Part 5 – Log Formatting – Log Formatting
OLAP Data Access Logging: Part 6 – Assertions, Unix and 64 bit Windows – Assertions, Unix and 64 bit Windows
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.

The OLAP Data Access component

A number of Business Objects products all share a data access component to access OLAP data. Although in any one particular release of the Business Objects suite, different products may be using different versions of the OLAP data access component they all share a similar logging facility.

The OLAP Data Access component is written in C++ and all logging facilities are controlled through the registry. On a Windows platform this in the 32 bit Windows registry. On a UNIX platform this is through the pseudo-Windows registry that Business Objects products use. This is different than the MainWin registry that some Crystal Reports UNIX users may be familiar with.

In the XI R2, XI 3.0 and XI 3.1 versions of Business Objects software there are two different evolutions of the OLAP data access component in existence. There is the legacy version known as SOFA (Simple OLAP Framework Architecture) and the newer version known as MDA (Multidimensional Data Access). Table 1 shows which products use which versions.

Table 1 OLAP Data Access component versions

 

XI R2

XI 3.0 and XI 3.1

OLAP Intelligence

SOFA 11.5

N/A

Web Intelligence

SOFA 11.5

MDA 12

Crystal Reports

SOFA 11.5

SOFA 12

Voyager

MDA 11.5

MDA 12

It is important to be aware of which version of the OLAP Data Access component is being used as it affects precisely where the registry settings are located and what logging facilities are available. It is also important to know that the settings for one version of the component will affect all products using that version of the component. For example, if logging is set up for SOFA 11.5, any instance of OLAP Intelligence, Web Intelligence or Crystal Reports will use those settings.

Registry Location

Logging is controlled through the registry. The logging settings are located in and below a root registry key for the particular version of the OLAP Data Access component that is being used. The locations ofthe logging roots are given in table 2.

Table 2 Logging root locations

Version

Root location

SOFA 11.5

[HKEY_LOCAL_MACHINESOFTWAREBusiness ObjectsSuite 11.5OLAP IntelligenceOCCA(o)Log]

SOFA 12

[HKEY_LOCAL_MACHINESOFTWAREBusiness ObjectsSuite 12.0OLAP IntelligenceOCCA(o)Log]

MDA 11.5

[HKEY_LOCAL_MACHINESOFTWAREBusiness ObjectsSuite 11.5VoyagerMDALog]

MDA 12

[HKEY_LOCAL_MACHINESOFTWAREBusiness ObjectsSuite 12.0MDALog]

 

Main settings

Underneath the root registry key are a number of registry values that control the main logging settings. Explanations are given here.

Values that are required to be present are indicated as being mandatory. Values not indicated as being mandatory are allowed to be absent from the registry.

Location

Value type:String

Mandatory: Yes

This indicates the location of a string resource dll used by the logging system. This should be set up with a default install and should not need to be changed. Table 3 shows the values of this registry entry.

Table 3 Locationregistry entries

Version

Location

SOFA 11.5

“Location”=”C:Program FilesBusiness ObjectsOLAP Intelligence 11.5Bin”

SOFA 12

“Location”=”C:Program FilesBusiness ObjectsBusinessObjects Enterprise 12.0win32_x86”

MDA 11.5

“Location”=”C:Program FilesBusiness Objectscommon3.5 in”

MDA 12

“Location”=”C:Program FilesBusiness ObjectsBusinessObjects Enterprise 12.0win32_x86”

If this value is missing, contains the incorrect path, or the string resource dll is missing then some logging statements may not appear correctly.

LogFile

Value type: String

Mandatory: Yes

This specifies name and location of the file to log to. The value of this setting can be changed to any valid file name and path. As an example here is the default value of this setting for MDA 12:

“LogFile”=”C:ProgramFilesBusiness ObjectsBusinessObjects Enterprise 12.0LoggingMDA.log”

This means that any logging will be done in the file MDA.log located in the folder C:Program FilesBusiness ObjectsBusinessObjects Enterprise 12.0Logging

If this registry value is absent then there will be no logging.

OverWrite

Value type:String

Mandatory: No

This determines whether a log file should be appended to or overwritten. A value of “Yes” overwrites the log file and a value of “No”appends to the log file. This value determines the behavior of a new process. If a process has been logging to a file already and has been idle for a while, the next time it logs it will append to the log file regardless of this setting. If the process was restated and the value was “Yes” then it would overwrite the log file.

Note If a processis already logging to the file and the value is set to ‘Yes’ and an additional process is started it may overwrite the current log.

An example entry would look as follows:

“OverWrite”=”Yes”

AppendPID

Value Type:String

Mandatory: No

This setting appends the ID of the current process to the file name specified in the LogFile value. This value is useful if a machine has multiple processes that will be using the OLAP Data Access component. For example if you have multiple Voyager MDAS servers or a mixture of Voyager and Web Intelligence servers both accessing OLAP data. With the value of this property set to ‘Yes’ all processes will log to their own log file. With the value set to ‘No’ all processes will log to the same log file. If a server restarts and comes back with a differentprocess ID and the setting is ‘Yes’ it will now log to a different log file than it did before.

An example entry would look as follows:

“AppendPID”=”Yes”

Verbosity

Value Type: DWORD

Mandatory: No

Verbosities are the controls which determine how much information is logged. Entering a verbosity value in the root Log folder specifies a global value for the entire OLAP Data Access component. Possible values are shown in table 4.

Table 4 Possible verbosity values

Value

Description

Example registry entry

0

Never. Nothing is logged.

“Verbosity”=dword:00000000

1

Critical. Only critical errors are logged.

“Verbosity”=dword:00000001

2

Serious. All errors are logged.

“Verbosity”=dword:00000002

3

Warning. Errors and warnings are logged

“Verbosity”=dword:00000003

4

Info. In addition to errors and warnings, other useful information is logged.

“Verbosity”=dword:00000004

5

Debug. Error, warnings, information and some additional debugging information is logged.

“Verbosity”=dword:00000005

10

Debug Extra. Everything is logged out.

“Verbosity”=dword:0000000a

LogFormat

Value Type:String

Mandatory: No

It is possible to override the default format that entriesare written to the log file. This is discussed in detail in a later post.

2 Comments
You must be Logged on to comment or reply to a post.
  • I really like the fact that Business Objects contains all of their trace/log info in simple to use files.  Plus of course the "audit" database functionality that's built in to the suite.
    Was wondering if there's any way to get Explorer searches logging information?