BODS AL Designer Logs Test

Business Objects Data Services is a data integration and transformation tool by SAP, which allows you to design and manage ETL (Extract, Transform, Load) processes. AL Designer (formerly known as Information Design Tool) is used for building data models and universes for reporting. AL Designer itself generates logs that can be useful for troubleshooting. These logs can provide information about errors, warnings, and general activities within the tool. You can find these logs typically in a "Logs" or "Log Files" folder within the installation directory. Look for log files with relevant timestamps to see if there are any issues.

This test monitors the AL Designer logs and collects key metrics like number of high and highest importance messages, fatal messages, error messages etc. Administrators can use these metrics to get insights into how the designer is performing.

Target of the test : A SAP BODS Node

Agent deploying the test : An internal/remote agent

Outputs of the test : One set of result for the BODS node being monitored.

Configurable parameters for the test

Parameter

Description

Test period

How often should the test be executed.

Host

Host name of the server for which the test is to be configured.

Port

Enter the port to which the specified host listens. This should be the port at which the web application server hosting SAP BODS listens.

Log Directory

Specify the full path to directory containing the log files. Typically, logs are written to the ‘logging’ directory in the BODS installation.

Server Abbreviations

Log file names are generally of the following fomat :’ <server abbreviation>.<server type>*.glf’. For e.g., cms_SAPBODS.CentralManagementServer_trace.001284 is one of the log trace files from the Central Management Server running in the node called SAPBODS. Server abbreviation in this case is cms. The default value for this parameter has hence been set as a comma separated list of server descriptions and their abbreviations as follows : <server description>:<server abbreviation>. For AL_Designer logs, the default log file is AL_Designer*.glf

Search Pattern

Enter the specific patterns of messages to be monitored. The pattern should be in the following format: <PatternName>:<Pattern>, where <PatternName> is the pattern name that will be displayed in the monitor interface and <Pattern> is an expression of the form - *expr* or expr or *expr or expr*, etc. A leading '*' signifies any number of leading characters, while a trailing '*' signifies any number of trailing characters.

For example, say you specify ORA:ORA-* in the SEARCHPATTERN text box. This indicates that "ORA" is the pattern name to be displayed in the monitor interface. "ORA-*" indicates that the test will monitor only those lines in the log file which start with the term "ORA-". Similarly, if your pattern specification reads: offline:*offline, then it means that the pattern name is offline and that the test will monitor those lines in the log file which end with the term offline.

A single pattern may also be of the form e1+e2, where + signifies an OR condition. That is, the <PatternName> is matched if either e1 is true or e2 is true.

Multiple search patterns can be specified as a comma-separated list. For example: ORA:ORA-*,offline:*offline*,online:*online

If the alertfile specification is of the format Name@logfilepath, then the descriptor for this test in the eG monitor interface will be of the format: Name:PatternName. On the other hand, if the alertfile specification consists only of a comma-separated list of log file paths, then the descriptors will be of the format: LogFilePath:PatternName.

Also, if a comma-separated list of alert files is provided in the alertfile text box in the format Name@logfilepath, and you want to monitor one/more specific patterns of logs in each alert file, then your specification would be of the format:

Name@<PatternName>:<Pattern>

For instance, say, your alertfile specification is as follows: dblogs@/tmp/db/*dblogs*,applogs@/tmp/app/*applogs*. Now, assume that you want to monitor the following entries in the specified alert files:

Alert file	Pattern
dblogs	error
dblogs	Ora*
applogs	*warning
applogs	ora-info

The searchpattern specification in this case will hence be as follows:

dblogs@error:*error*,dblogs@ora:ora*,applogs@warning:*warning, applogs@info:*ora-info*

If you want all the messages in a log file to be monitored, then your specification would be: <PatternName>:*

Lines

Specify two numbers in the format x:y. This means that when a line in the log file matches a particular pattern, then x lines before the matched line and y lines after the matched line will be reported in the detail diagnosis output (in addition to the matched line). The default value here is 0:0. Multiple entries can be provided as a comma-separated list.

If you give 1:1 as the value for LINES, then this value will be applied to all the patterns specified in the SEARCHPATTERN field. If you give 0:0,1:1,2:1 as the value for LINES and if the corresponding value in the SEARCHPATTERN field is like ORA:ORA-*,offline:*offline*,online:*online then:

0:0 will be applied to ORA:ORA-* pattern

1:1 will be applied to offline:*offline* pattern

2:1 will be applied to online:*online pattern

Rotating File

This flag governs the display of descriptors for this test in the eG monitoring console.

If this flag is set to true and the ALERTFILE text box contains the full path to a specific (log/text) file, then, the descriptors of this test will be displayed in the following format: Directory_containing_monitored_file:<SearchPattern>. For instance, if the ALERTFILE parameter is set to c:\eGurkha\logs\syslog.txt, and ROTATINGFILE is set to true, then, your descriptor will be of the following format: c:\eGurkha\logs:<SearchPattern>. On the other hand, if the ROTATINGFILE flag had been set to false, then the descriptors will be of the following format: <FileName>:<SearchPattern> - i.e., syslog.txt:<SearchPattern> in the case of the example above.

If this flag is set to true and the ALERTFILE parameter is set to the directory containing log files, then, the descriptors of this test will be displayed in the format: Configured_directory_path:<SearchPattern>. For instance, if the ALERTFILE parameter is set to c:\eGurkha\logs, and ROTATINGFILE is set to true, then, your descriptor will be: c:\eGurkha\logs:<SearchPattern>. On the other hand, if the ROTATINGFILE parameter had been set to false, then the descriptors will be of the following format: Configured_directory:<SearchPattern> - i.e., logs:<SearchPattern> in the case of the example above.

If this flag is set to true and the ALERTFILE parameter is set to a specific file pattern, then, the descriptors of this test will be of the following format: <FilePattern>:<SearchPattern>. For instance, if the ALERTFILE parameter is set to c:\eGurkha\logs\*sys*, and ROTATINGFILE is set to true, then, your descriptor will be: *sys*:<SearchPattern>. In this case, the descriptor format will not change even if the ROTATINGFILE flag status is changed.

Exclude Pattern

Provide a comma-separated list of patterns to be excluded from monitoring in the EXCLUDEPATTERN text box. For example *critical*,*exception*. By default, this parameter is set to 'none'.

Unique Match

By default, the UNIQUEMATCH parameter is set to FALSE, indicating that, by default, the test checks every line in the log file for the existence of each of the configured SEARCHPATTERN. By setting this parameter to TRUE, you can instruct the test to ignore a line and move to the next as soon as a match for one of the configured patterns is found in that line. For example, assume that Pattern1:*fatal*,Pattern2:*error* is the SEARCHPATTERN that has been configured. If UNIQUEMATCH is set to FALSE, then the test will read every line in the log file completely to check for the existence of messages embedding the strings 'fatal' and 'error'. If both the patterns are detected in the same line, then the number of matches will be incremented by 2. On the other hand, if UNIQUEMATCH is set to TRUE, then the test will read a line only until a match for one of the configured patterns is found and not both. This means that even if the strings 'fatal' and 'error' follow one another in the same line, the test will consider only the first match and not the next. The match count in this case will therefore be incremented by only 1.

UseUTF8

If UTF-8 encoding is to be used for reading the specified log file, then, set the USEUTF8 flag to true. By default, this flag is set to false. If multiple log files are being monitored, then, for each file, you will have to indicate whether UTF-8 encoding is to be used for reading that file or not. For instance, assume that the ALERTFILE parameter is set to dblogs@/tmp/db/dblogs.log,applogs@/tmp/app/applogs.log. Now, to instruct the test to use UTF-8 encoding for reading the 'dblogs' log file and not to use the UTF-8 encoding while reading the 'applogs' log file, your USEUTF8 setting should be as follows: true,false. Note that the number of values provided against the USEUTF8 parameter should be equal to the number of log files being monitored. Also, note that if the ALERTFILE being monitored has BOM, then the test will automatically use UTF-8 encoding to read that file, even if the USEUTF8 flag is set to false.

Note:

If your ALERTFILE specification consists of file patterns that include wildcard characters (eg., /tmp/db/*dblogs*,/tmp/app/*applogs*), then the files that match such patterns will only support the ANSI format, and not the UTF format, even if the UTF-8 parameter is set to true for such patterns.

UseUTF16

If UTF-16 encoding is to be used for reading the specified log file, then, set the USEUTF16 flag to true. By default, this flag is set to false. If multiple log files are being monitored, then, for each file, you will have to indicate whether UTF-16 encoding is to be used for reading that file or not. For instance, assume that the ALERTFILE parameter is set to dblogs@/tmp/db/dblogs.log,applogs@/tmp/app/applogs.log. Now, to instruct the test to use UTF-16 encoding for reading the 'dblogs' log file and not to use the UTF-16 encoding while reading the 'applogs' log file, your USEUTF8 setting should be as follows: true,false. Note that the number of values provided against the USEUTF16 parameter should be equal to the number of log files being monitored.

Note:

Encode Format

By default, this is set to none, indicating that no encoding format applies by default. However, if the test has to use a specific encoding format for reading from the specified ALERTFILE , then you will have to provide a valid encoding format here - eg., UTF-8, UTF-16, etc. Where multiple log files are being monitored, you will have to provide a comma-separated list of encoding formats – one each for every log file monitored. Make sure that your encoding format specification follows the same sequence as your ALERTFILE specification. In other words, the first encoding format should apply to the first alert file, and so on. For instance, say that your alertfile specification is as follows: D:\logs\report.log,E:\logs\error.log, C:\logs\warn_log. Assume that while UTF-8 needs to be used for reading from report.log , UTF-16 is to be used for reading from warn_log . No encoding format need be applied to error.log. In this case, your ENCODEFORMAT specification will be: UTF-8,none,UTF-16.

Node Name

Specify the name of the BODS node being monitored.

Detailed Diagnosis

To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

The eG manager license should allow the detailed diagnosis capability
Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

Measurements made by the test
Measurement	Description	Measurement Unit	Interpretation
High importance messages	Indicates the number of log messages with importance set to ‘high’ in the last measurement period.	Number	High importance designation for the log message is characterized by the ‘>=’ symbol. For each such message, detailed diagnosis provides the details such as Location (message source), timestamp, trace category, server, message, user etc.
Highest importance messages	Indicates the number of log messages with importance set as ‘highest’ in the last measurement period.	Number	Highest importance designation for the log message is characterized by the ‘>>’ symbol. For each such message, detailed diagnosis provides the details such as Location (message source), timestamp, trace category, server, message, user etc.
Errors	Indicates the number of error log messages in the last measurement period.	Number	Error log messages have Severity values set to ‘E’. For each such message, detailed diagnosis provides the details such as Location (message source), timestamp, trace category, server, message, user etc.
Asserts	Indicates the number of Assert log messages in the last measurement period.	Number	Assert log messages have Severity values set to ‘A’. For each such message, detailed diagnosis provides the details such as Location (message source), timestamp, trace category, server, message, user etc.
Fatal messages	Indicates the number of fatal log messages in the last measurement period.	Number	Fatal log messages have Severity values set to ‘F’. For each such message, detailed diagnosis provides the details such as Location (message source), timestamp, trace category, server, message, user etc.
Problematic message rate	Indicates the rate of all problem messages in the last measurement period.	Messages/Sec
New Messages	Indicates number of log messages in the last measurement period.	Number