The benefit of logging processes, as opposed to debugging them, is that you can review this information to find errors in your SAP configurations. Logging in SAP BusinessObjects Planning and Consolidation 7.0, version for SAP NetWeaver is extremely detailed and provides tremendous value when you need to quickly identify and solve problems. You are able to do so without having to step through code line by line.

The difference between logging and tracing is that while logging registers all system activities, tracing provides detailed information for a particular user. It enables you to trace all actions the user performs to look for issues based on certain scenarios and the user’s execution path. For example, you can trace a user to see if his or her security is incorrect, versus reading a log that gives the security information for all users in the system.

This is our second article on SAP BPC. The focus here is troubleshooting system or application issues. We discuss common logging and tracing options on this platform. We discuss capability available to system administrators for troubleshooting technical issues such as “insufficient memory for your dialog processes,” and functional issues, such as EVDRE functionality, which is an SAP BPC function that creates ad hoc templates and input schedules with which you analyze and send data.

Logging Within .NET Server

Two primary logging mechanisms exist within the SAP BPC .NET Server:

• SAP BPC .NET Server logs, which display any logs specific to SAP BPC application on the server
• Microsoft IIS Server logs, which display any logs specific to the Microsoft IIS Web Server

Each log provides different kinds of information that you can use to troubleshoot technical and functional issues. For example, the SAP BPC .NET Server log can tell you if the SAP BPC write-back failed. The Microsoft IIS Server logs can tell you about any connectivity related issues to the Web server, such as an http 404 error (which means the Web page cannot be found).

SAP BPC .NET Server Logs

The SAP BPC .NET Server logs are located at Logging, which is typically C:BPCLogging if you’ve used the defaults during installation. Subfolders describe the module (.DLL name) that reports the logged error. Each module has only one subfolder with the logs related to that module.

As of SAP BPC Support Pack 01, you can control the level of logging set for the SAP BPC .NET Server. Four log levels are available:

• ERROR = 1
• WARNING = 2
• INFO = 3
• TRACE = 4

To set these logs, log in to SAP BPC Administration at https:///osoft, select BPC Administration, and then click Set AppSet parameters. To set the log level parameter you enter a value (e.g., 4) in the LOGLEVEL field (Figure 1), and then click the Update button.

Figure 1

Set the log levels

Now that the logs are set, you can view the logs for users after they have accessed the system. To view a log, click the BPC folder (found at the install location, typically C:BPC), click the Logging folder, and then click the OSoftUserManage folder. The logs specific to SAP BPC .NET applications are stored on this server (Figure 2). All logs are time-stamped by day (e.g., 5-24-2008.txt), and a new file is created each day within each module subfolder. So this would mean that for each module, all errors that are logged will be in one file per day.

Figure 2

Example of logs for the SAP BPC .NET Server

You can view the contents of a log using a text editor, such as Notepad, as shown in Figure 3.

Figure 3

View the content of a log with a text edito

The log shows that the user’s logon failed because the server was not started.

In addition to the above, you can use Event Viewer (in Microsoft Windows) to view the same SAP BPC .NET Server logs. To open Event Viewer, follow menu path Control Panel > Administrative Tools > Event Viewer (Figure 4).

Figure 4

Use Event Viewer to view logs

The OutlookSoft log in Event Viewer is the same log as the SAP BPC .NET Server log. As we mentioned earlier, the log is stored in a subfolder, where the subfolder has the same name as the DLL file without the .DLL extension. You also have access to information from the Application log, Security log, System log, and the Microsoft Office logs. For example, the Security log tells you if the issues a user is encountering are due to missing authorization specifications. The Microsoft Office logs show issues with Microsoft Office products, such as Excel or PowerPoint, that may affect SAP BPC.

Microsoft IIS Server Logs

You have several options for troubleshooting Microsoft IIS Web Server (or IIS for short). Here are the two most common options for tracing IIS-related issues:

• Currently executing requests tracing — used for long-running processes
• Request-based tracing — used for most common problem tracing

With currently executing requests tracing, you can narrow down the source of the problem by executing a command from a command prompt. For example, enter logman start W3wpTrace –p “IIS: Request Monitor” –ets at a command prompt. Let the trace session run for a few moments, and then enter logman stop W3wpTrace –ets. The currently executing requests tracing returns details about requests that execute at the moment the command was executed.

With this information, you can determine the number of requests for any Active Server Pages (ASPs), the processing state for each request that is processing, and how long each request has been processing. With this information, you can focus your troubleshooting efforts on the pages where the issues exist.

Request-based tracing is a higher-level trace that you use for tracing common problems, such as a 404 (not found) error, which occurs when a Web page is not found. It provides traces by requests. For example, actions that users perform on the SAP BPC client initiate a request to the Microsoft IIS Web Server, and from here, a request for information might be made from the Microsoft IIS Web Server to the ABAP Server in the SAP BPC architecture. The trace shows all requests that interact with the Microsoft IIS Web Server.

Figure 5 illustrates how logging and tracing work in the Microsoft IIS Web Server.

Figure 5

Figure 5 Architecture of tracing IIS

The w3wp.exe process is the Web server process for IIS. To trace the w3wp.exe process, you need to launch the Logman utility and then start IISTRACE-PF process. You need to instruct the trace where to store the file (in this example, MyProvs.txt). Note that you can add the “-ets” switch to send the commands to the event trace session without saving or scheduling this setting. This is optional, but adding the switch helps to optimize performance.

Logging Within the .NET Client

Within SAP BPC, there are two primary client applications: BPC Admin Console and BPC for Office. BPC administrators use the SAP BPC Admin Console to configure BPC. End users who want to do their financial planning use the BPC for Office clients. The client logging primarily applies to the BPC for Office clients. One of these clients is BPC Excel, which also has client logs available. You can see them via Event Viewer (Figure 4).

Three logs are available for the BPC Excel client:

• EV4Excel50.log. The primary log for all issues within the BPC Excel client
• EVDRE_LOG.txt. The log file that contains the history of all actions performed by the EVDRE function within reporting
• EVDRE_TRACE.txt. The trace file that keeps track of all the queries issued by EVDRE function within reporting

SAP BPC Excel Logs

All SAP BPC Excel-related issues are logged in the EV4Excel50.log. You can view this file in Event Viewer under the OutlookSoft log. The OutlookSoft log that you can view in the Event Viewer is the same file as the BPCEv4Excel50.log, which is stored in the Program Files folder on the client machine. Client-based logs contain information about the client and errors that occur on the client machine. For example, the client log shown in Figure 6 indicates that the user toggled the toolbar on and off.

Figure 6

Log displays activities that occurred in the SAP BPC Excel application

The Ev4Excel50.log for BPC Excel, which can be viewed in Event Viewer or a text editor such as Notepad, is located on the client. Previously, the SAP BPC .NET Server logs were viewed by launching Event Viewer on the server machine. The logs are viewed the same way, but different sets of logs (client vs. server) are located on different machines.

The EV4Excel50.log is always enabled by default. If additional logging is needed, you can set the file for EVDRE reporting, which is described next.

EVDRE Logs

To set up logging on EVDRE, you need to create two files locally in the My Documents folder on the SAP BPC client. When running, the SAP BPC system automatically appends a set of information to two text files, if they exist. The files are called EVDRE_LOG.TXT and EVDRE_TRACE.TXT, and they must reside in your My Documents folder. The log file contains the history of all actions performed by the EVDRE functionality; whereas, the trace file keeps track of all the queries issued by the EVDRE query engine.

If the files do not exist, create them in a text editor, such as Notepad, and save them to your My Documents folder on the client. Then, run an EVDRE workbook, and the system automatically writes to the files.

When you enable these logs some overhead to performance occurs, so be sure that you delete this file after you have resolved any issues found.

Tracing and Logging in SAP NetWeaver AS ABAP

ABAP offers numerous options for logging and tracing, and SAP NetWeaver offers tracing capabilities as well as debugging capabilities. The focus here, however, is on the most common options for tracing and logging that are relevant to SAP BPC.

Most application logic for SAP BPC is implemented in ABAP. Using logs and traces before you begin to debug an issue can save time and effort because you can quickly find errors in the logs and traces. To resolve issues in the ABAP stack only for SAP BPC, we recommend you perform the following steps:

• Step 1. Check for ABAP dumps using transaction ST22.
• Step 2. Check for connection errors using transaction SM21.
• Step 3. Check SAP BPC-specific logs using transaction SLG1 or transaction SLG2.
• Step 4. Enable detailed tracing using transaction ST01 or ST05.

As the steps indicate, you should check logs first because they will display common errors. If the error isn’t available in a log, then tracing a user step-by-step through the application is your next task. If the tracing doesn’t help, then you can set breakpoints and debug the application. Debugging should be used only if tracing and logging don’t resolve the issue.

Step 1. Check for ABAP Dumps Using Transaction ST22

ABAP dumps are generally caused by SAP BPC programming bugs and should be reported to SAP. Some may be caused by system issues, so check the details of the errors to see the root cause. Run transaction ST22 (ABAP dump analysis). As shown in Figure 7, there is a coding error that can be reported to SAP.

Figure 7

Find out if the issue is caused by an ABAP dump

Step 2. Check for Connection Errors Using Transaction SM21

If the issue has not been caused by an ABAP dump, then you need to see if there are any connection errors, since SAP BPC applications connect from the .NET Server to the SAP NetWeaver AS ABAP using Remote Function Calls (RFCs). Run transaction SM21 (online system log) and click the Reread system log to display connection errors. As shown in Figure 8, the line that reads Database error indicates an error at the database connection tier.

Figure 8

Look for connection errors in system logs using transaction SM21

Step 3. Check SAP BPC-Specific Logs Using Transaction SLG1 or Transaction SLG2

If errors aren’t found in transaction ST22 or transaction SM21, then you can check the logs via transaction SLG1 (application logs: display logs). Transaction SLG1 displays logs written by SAP BPC within ABAP. These logs provide different types of information to help you delineate errors from “nice to have” or FYI information:

• Error message
• Warning message
• Debug message

To view all logs related to SAP BPC, run transaction SLG1, enter object UJ as the object, and click the execute icon (Figure 9).

Figure 9

SLG1 logs for SAP BPC

The first column shows the date, time, and SAP BPC user. The SAP BPC user information identifies which user’s activities generated this log. Although the logs in transactions SM21 and ST22 display the ABAP user, the SLG1 log provides more detail. The External ID field identifies the AppSet and application ID the BPC user was using at the time of the error. The Sub-object text field displays the module that issued the log. The Program field lists the ABAP program or RFC-enabled function module that was executed. You can use this information to set breakpoints in the correct function module.

To see detailed logs, double-click Problem class Other under the log entry, as shown in Figure 10. To see the detailed logs, click the Det. (Details) button.

Figure 10

Display the details of the SLG1 log

As you can see, the log details the SQE call UJQ_RUN_XML_QUERY from the .NET tier. The Shared Query Engine (SQE) logs all details based on the type of call. Therefore, you can see all the multi-dimensional expressions (MDX) statements executed within the system logs.

All calls to SQE are centralized and written to system logs, giving you all the logs within your SAP BPC system, whether it is from BPC for Excel, script logic (the business logic within the SAP BPC product), or Data Manager (the entitlement and liability transfer [ETL] mechanism within the SAP BPC product). Figure 11 shows the MDX statement of an SQE call.

Figure 11

SQE log for the MDX statement

If there are numerous log entries, you might want to break down the SLG1 logging even further using the subobjects. Run transaction SLG1 to open the selection screen, and then click the Subobject button (or press F4), as shown in Figure 12.

Figure 12

SLG1 logs for SAP BPC

Although logs are invaluable in finding and addressing errors and problems, you also need to manage them so they don’t negatively affect system performance. For information on an important administrative task see the sidebar, “Purge Log Files.”

Step 4. Enable Detailed Tracing Using Transaction ST01 or ST05

If the logs don’t include enough details, you should examine them using a trace option that will help you uncover details that could be helpful when resolving issues. A trace allows you to record all the details of a user’s execution path. To set traces, use transaction ST01 (system trace), as shown in Figure 13.

Figure 13

System tracing using transaction ST01

The common traces you can enable (or disable) are:

• Authorization check for ABAP authorization objects (not SAP BPC authorizations)
• Kernel functions
• General kernel
• DB access (SQL trace)
• Table buffer trace
• RFCs
• Lock operations

The RFCs, DB access, and authorization check traces are most useful for starting traces. You set the traces for the connection user, not the SAP BPC user, because this trace only applies to ABAP users. This is one of the three ABAP service users used in SAP BPC.

As an alternative, you can use transaction ST05 (performance trace) to set the trace as well, but this transaction is a subset of the functionality in transaction ST01.

As a last resort, if logging and tracing don’t help in resolving the issue, then you need to debug the issue (as outlined in the first article in this series). To easily determine the tier within the architecture where the problem exists, we recommend that you start at the client tier, examine the .NET Server tier, and then check the ABAP tier.

Prakash Darji

Prakash Darji is currently director of product management in the Enterprise Performance Management area within SAP Business Objects. In his current role as a director of product management for the SAP BusinessObjects Planning and Consolidations product, his responsibilities include inbound product management through working on the short- and longer-term roadmap for SAP's Planning Solutions, managing deliverables for multiple releases, as well as creating product specifications for innovative features and functions to differentiate against key competitors. His full bio is available at: www.linkedin.com/in/prakashdarji.

You may contact the author at prakash.darji@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.

Ryan Leask

Ryan Leask currently runs the SAP BusinessObjects Planning and Consolidation solution management team for SAP, based out of Palo Alto, CA. Prior to this position, he led the EPM solution architecture team with a main focus on the design of SAP BusinessObjects Planning and Consolidation 7.0, version for SAP NetWeaver. Ryan has also worked on SAP xApp Analytics, SAP NetWeaver Visual Composer, SAP NetWeaver BW, SAP SEM, ABAP, SAP CRM, analytics/data mining, and whatever else seemed interesting. He has also co-authored SAP xApp Analytics (SAP PRESS, 2006), written many articles, and presented at numerous conferences.

You may contact the author at ryan.leask@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.