SAP BusinessObjects Planning and Consolidation (SAP BPC) is the product that SAP acquired when it bought OutlookSoft Corporation in 2007. It is now a part of SAP’s overall Enterprise Performance Management (EPM) portfolio. It is a solution dedicated to fulfilling your planning, budgeting, and forecasting requirements, as well as enabling legal and management consolidations and advanced reporting capabilities. Furthermore, it enables all of these functions to operate through a single unified application with a best-in-class user interface (UI).

SAP BPC is also designed to enable business users to effectively manage their businesses without relying on the IT department to move ahead with any changes. Figure 1 represents a common scenario in which the business is changing at a faster rate than the IT systems that support it.

Figure 1

Rate of change for business vs. IT systems

It’s no surprise that business changes faster than IT, with businesses constantly evolving and adapting to changing market conditions and customer requirements, performing mergers and acquisitions, lowering costs, improving efficiency, driving new revenue opportunities, and meeting new legislative requirements. So, how do companies manage all of these tasks? If they are well managed and have an existing EPM system in place, they usually ask IT to modify the system to support their new, high-priority change, such as needing a property (COLOR) added to a dimension (PRODUCT). At that point, the request typically goes into a queue that IT manages. When IT receives the request, the IT team works to translate it into a detailed system impact. Next, IT estimates the time and cost of the project and subsequently sends the request back to the business for approval. Once IT receives the approval, the team begins to work on the system, collaborating back and forth with the business until the change is just right. Finally, IT rolls out the change to all users.

Depending on the nature of the change, this process could take weeks or months after the initial event occurred that triggered the change. In the meantime, more changes have occurred, and the queue for IT continues to grow. Typically, the business can’t wait for the change to be rolled out, so they begin managing their information in a method they can control themselves: the ubiquitous spreadsheet! SAP BPC tackles this problem by putting the power of administration back into the hands of the business. Of course, IT still plays a very important role in installations, monitoring, governance, and implementing complex scenarios, but now in many situations the business can implement its own changes in SAP BPC.

Since the OutlookSoft acquisition, SAP has pursued a dual-stack release strategy for SAP BPC, providing two different products to the market:

• SAP BusinessObjects Planning and Consolidation, version for the Microsoft platform
• SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver

When SAP acquired OutlookSoft, SAP BPC ran only on the Microsoft platform (Windows operating system, SQL Server, Analysis Services, Reporting Services, Data Transformation Services [DTS]/SQL Server 2005 Integration Services [SSIS]). SAP continues to invest strategically in the Microsoft version of BPC to maintain its commitment to these customers. (The official name is “SAP BusinessObjects Planning and Consolidation, version for the Microsoft platform,” but it is occasionally referred to unofficially with an M suffixed to the release name — for example, SAP BPC 7.0 M would refer to version 7.0 of SAP BPC running on the Microsoft platform.)

Although the Microsoft platform works well for many users, a lot of SAP users run SAP NetWeaver Business Intelligence (SAP NetWeaver BI) and want to use this system to its greatest capability. Since the acquisition of OutlookSoft, SAP has been working on integrating SAP BPC into the SAP NetWeaver BI platform (The official name for this release is “SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver," and it is occasionally referred to unofficially with an NW suffix — for example, SAP BPC 7.0 NW would indicate version 7.0 of SAP BPC, running on the SAP NetWeaver platform.) For the purposes of this article, we use the unofficial abbreviation SAP BPC 7.0 NW, or simply SAP BPC, throughout the article, with the understanding that we are talking about the version for SAP NetWeaver. Users employ the platform they prefer, and SAP continues to invest in both versions going forward.

This article begins with an overview of the architecture for this release and then drills down more detail about how to set up the connectivity between the different BPC clients and servers. Next, it describes how to change different ABAP and .NET settings to optimize system performance, which enables you to optimize your system according to your users’ requirements. While no specific product knowledge is assumed on behalf of the reader, this article is designed for technical consultants, and a base level understanding of SAP NetWeaver BI or SAP BPC, version for the Microsoft platform is advantageous.

Architecture for SAP BPC 7.0 NW

In this section, we discuss the different clients and servers that are required for SAP BPC 7.0 NW, and then compare and contrast this to SAP BPC 7.0 M architecture. We also describe how SAP BPC 7.0 NW leverages the underlying SAP NetWeaver BI and ABAP application servers. Figure 2 shows an architectural overview of SAP BPC 7.0 NW.

Figure 2

SAP BPC 7.0 NW architecture

All of the available client options for running SAP BPC are at the top of Figure 2:

• Admin: This is the client application that the system administrators use to create and change applications, maintain users and their security, and other such tasks. The admin client presents these types of complex tasks in an extremely straightforward manner, which empowers business users to administer the system themselves.
• Microsoft Office clients: End users primarily run SAP BPC 7.0 NW through Microsoft Excel. However, you can also use both Microsoft Word and PowerPoint to interact with SAP BPC data.
• Web: SAP BPC offers a zero footprint option for users who don’t need all of the functionality that Microsoft Excel provides. In some SAP BPC documents, the Web client is called a zero footprint client or thin client. Thin clients don’t require end users to install any software, which is the same way, for example, that the Web-based application Gmail, from Google, does not require any software to be installed to use it.
• Others: SAP BPC Server Manager is a client application that runs on the .NET application server and configures the system and connectivity details. Another option is for you to create custom client applications by consuming Web services available on the application server. In addition, you can also perform some configuration directly through the SAPGUI.

In SAP BPC, little processing remains in the .NET application server (the next layer down in the figure from the clients). The .NET application server in SAP BPC mostly repackages (i.e., converts) the data from SAP NetWeaver Application Server (SAP NetWeaver AS) into the required format that the SAP BPC clients expect.

SAP BPC clients don’t connect directly with SAP NetWeaver AS ABAP. They always go through the .NET Web server or .NET application server. In SAP BPC 7.0 NW, the majority of SAP BPC application logic was rewritten into ABAP code (previously, it was all in .NET) so that it could be executed on SAP NetWeaver AS. The .NET application server connects to SAP NetWeaver AS via a Remote Function Call (RFC), which is the standard interface for communications among SAP systems. (For more information on the SAP BPC/SAP NetWeaver AS connection, see the sidebar below.)

SAP BPC interacts with SAP NetWeaver BI on two fronts: objects and data. First, it performs the Create, Read, Update, and Delete (CRUD) operations for SAP NetWeaver BI objects, such as InfoProviders and InfoObjects. This way, the SAP BPC administrator never needs to maintain any of these objects directly in SAP NetWeaver. Second, SAP BPC also performs CRUD operations on the data stored in SAP NetWeaver BI. When reading the data from SAP NetWeaver BI InfoCubes, SAP BPC uses two different SAP NetWeaver technologies:

• Online Analytical Processing (OLAP) BAPIs, which allow SAP BPC to access the data in SAP NetWeaver BI InfoCubes via the Multidimensional Expressions (MDX) language.
• Internal APIs, which enable SAP BPC to use private APIs (unsupported for third-party or customer use) to read data from SAP NetWeaver BI InfoCubes.

The Shared Query Engine (SQE), a module of SAP BPC, determines the optimal technology to use: internal APIs or OLAP BAPIs.

The relational database is in the database tier of SAP BPC 7.0 NW (Figure 1). This database is the same one that SAP NetWeaver BI uses for storage, and the SAP BPC application creates a number of new tables in this database in which to store its data. In addition to using the database to store data, SAP BPC 7.0 also uses the database to store files. You can run SAP BPC on any relational database that SAP NetWeaver supports (the list of supported databases is in the Product Availability Matrix [PAM] on SAP Service Marketplace at https://service.sap.com/PAM > SAP NetWeaver 7.0 [2004s]).

You can use the SAP NetWeaver BI Accelerator (BIA), although it is not mandatory, for SAP BPC InfoProviders. You can add this hardware appliance to SAP NetWeaver BI to provide consistently fast response times, even as data volumes and the number of users increase. The details of how SAP NetWeaver BI Accelerator works are beyond the scope of this article, but its performance improvements can extend to SAP BPC, too. (For more information on SAP NetWeaver BI Accelerator, visit SDN at https://www.sdn.sap.com/irj/sdn/bia.) Now that we have covered the architecture of SAP BPC 7.0 NW, we can examine how the connectivity between all the different tiers is handled.

Connectivity

To understand the underlying SAP BPC architecture and the interaction among the different tiers, you need to look at their methods of communication. First, let’s examine the connectivity from the client machine to the Microsoft .NET Server, which has two components: the IIS Web server and the .NET application server.

The client connects to the .NET Web server through Web service calls. The client is then authenticated and connected using the Domain user that was used to log in. In addition, the client can connect to the .NET application server directly through COM+ components. (COM is a basic specification and set of services for creating modular, object-oriented distributed applications; COM+ includes the basic COM services and other more advanced services, such as transactions, queuing, deployment, and administration.) However, the client will never connect directly to the SAP NetWeaver AS ABAP tier — the .NET application server and the .NET Web server are the only ways you can access this tier. Figure 3 shows the connection path.

Figure 3

Connectivity between the architectural tiers

Connectivity between the Microsoft .NET server tier and the SAP NetWeaver AS ABAP tier exists through the SAP .NET Connector framework (version 2.0). Because of this connection, you must have both the Microsoft .NET 1.1 and .NET 2.0 frameworks installed on the .NET application server to be able to run SAP BPC 7.0 NW. All calls are made as RFC connections. Figure 4 illustrates the connection between the Microsoft .NET server and SAP NetWeaver AS.

Figure 4

SAP .NET Connector architecture

To configure and install SAP .NET Connector on the .NET application server to connect to ABAP, you need to complete the following steps:

1. Install Microsoft .NET 1.1 Framework and .NET 2.0 Framework on the .NET application server. To install Microsoft .NET Framework 1.1 or .NET Framework 2.0, download the files from the Microsoft Web site at https://msdn.microsoft.com/netframework and go to Downloads and then select the required version. Then, select the version you want to install and follow the interactive installation procedures. It is also a best practice to apply the latest .NET support packages after installation.
2. Install the librfc32.dll on the .NET application server. The easiest way to do this is to install SAPGUI on the server directly. Download the media for SAPGUI from the SAP Service Marketplace at https://service.sap.com/swdc and follow menu path Download > Installations and Upgrades > Entry by Application Group > SAP Frontend Components > SAP GUI FOR WINDOWS > SAP GUI FOR WINDOWS 7.10 CORE > Installation. Once installed on the .NET application server, SAPGUI deploys the correct platform-specific version of librfc32.dll. If you don’t want to install SAPGUI on the .NET application server, manually deploy the platform-specific librfc32.dll (SAP Note 182805 shows you the steps). We recommend that you install SAPGUI for the easiest installation process.
   
   
   Note
   The librfc32.dll is platform-dependent and is different for Unicode and non-Unicode versions of SAP NetWeaver, so you should download the correct version for your platform. For more information, see the article “Provide Accurate and Consistent Language Support for Your Global MDMP Systems by Converting to Unicode.”
3. Install the SAP BPC 7.0 NW.NET server application on the .NET application server. The required DLLs for the SAP .NET Connector are included in the SAP BPC.NET server application installer. To install the.NET server application, download the latest SAP BPC Server 7.0 file from SAP Service Marketplace, assuming you have the appropriate license, at https://service.sap.com/swdc, following menu path Download > Support Packages and Patches > Entry by Application Group > SAP Application Components > SAP BPC FOR SAP NETWEAVER > SAP BPC 7.0 FOR SAP NETWEAVER > SAP CPM BPC 7.0. Next, the installation process is described in detail.

Installing SAP BPC 7.0 .NET Server Application

Before you perform the installation, make sure that you have installed all the prerequisite software on the server. Also make sure to follow all of the pre- and post-installation configuration steps outlined in the official SAP BPC Installation Guide. The install guide can be found at https://service.sap.com/instguidesCPM-BPC.

1. Run the executable file you previously downloaded to launch the installation wizard.
2. Click the Next button through the introduction, select the appropriate language (e.g., English), and then click the Next button.
3. Select the locations where the files Xceedzip.dll and AntiXSSlibrary.dll can be found, as shown in Figure 5.
   
   

   Note
   For legal reasons, you must download these two DLL files separately to the .NET server application installer, from the Cryptography page on SAP Service Marketplace (https://service.sap.com/swdc: Download > SAP Cryptographic Software). Save these two DLLs in a temporary directory so you can select them, as shown in Figure 5.

   
   

   Figure 5

   Selecting locations for the first two DLLs
4. Enter your name and the name of your company.
5. Specify a user ID and password to log on to the .NET application server. This user will be the service user with which the tasks on the server are executed.
6. Select your target installation location (the default is C:BPC), click the Next button, and then click the Install button. When the installation completes, click the Finish button.
7. Enter the path to the message queue on your .NET server, as well as the ABAP application server name, client, language, system number, and three ABAP service users (the three service users are described later in the article), as shown in Figure 6. Setting up a MessageQueue on your .NET application server is described in detail in the official installation guide.
   
   
   
   

   Figure 6

   SAP NetWeaver AS ABAP connection settings
8. When prompted on the final screen, click the Install button to begin the installation process.

Once the installation is finished, the system deploys the SAP .NET Connector and sets it up on the .NET application server appropriately. Now the SAP BPC .NET application server/Web server tier (Figure 2) can successfully communicate with the ABAP system specified in the installation.

During the installation process, you are prompted for service user information (as in step 7 and Figure 6). The service users are identified by ABAP user IDs that you need to create manually in your ABAP system. SAP BPC needs them so it can establish the connection between the .NET application server and SAP NetWeaver AS ABAP. Create all of these users as ABAP communications users to ensure it is impossible for someone to initiate a dialog connection with them.

SAP BPC requires three different users:

• SYSADMIN is the ABAP user employed when SAP BPC Server Manager connects to the ABAP back-end system. The recommended naming convention for this role is _SYSADMIN. Use the delivered ABAP role SAP_BPC_SYSADMIN for this user.
• ADMIN is the ABAP user that SAP BPC Administration uses to connect to the ABAP back-end system. The recommended naming convention for this role is _ADMIN. Use the delivered ABAP role SAP_BPC_ADMIN for this user.
• USER is the ABAP user applied when SAP BPC Office and SAP BPC Web connect to the ABAP back-end system. The recommended naming convention for this role is _USER. Use the delivered ABAP role SAP_BPC_USER for this user.

During a connection from the client to the .NET application server and then to the ABAP application server, user authentication and authorization occur on two different levels. First, the system authenticates the SAP BPC end user as a valid Active Directory user against the Windows domain before sending the request to the server. Then the .NET application server authenticates the ABAP service user to SAP NetWeaver. Then the authorizations of the ABAP service user are checked to ensure that he or she can perform the required operation (this should generally not be an issue if you have assigned the correct ABAP role to your service user as described). Finally, the SAP BPC ABAP application layer checks the authorization of the SAP BPC user against the SAP BPC security layer (i.e. against the SAP BPC Member Access Profiles and Task Profiles). The user can perform the requested operation only if all of these checks are successful.

Now, let’s look at the different settings for SAP BPC that the ABAP application server tier can maintain.

ABAP Configuration

To optimally configure the system to your users’ requirements, you should understand the purpose of the ABAP parameters. Specifically, we discuss: the basic ABAP profile parameters, many of which are well known, that apply to the whole ABAP server and are not SAP BPC-specific; the concurrency-locking parameters, which you can configure to alter the behavior of the system when locking data during a write-back to an SAP BPC application; and the SQE parameters, which influence what is considered a request for a “sparse” data set.

Basic ABAP Profile Parameters

Even without the SAP BPC add-on installed on SAP NetWeaver BI, you can configure numerous profile parameters to optimize your ABAP application server. These parameters are configured in transaction RZ10 (Maintain Profile Parameters) in SAP NetWeaver. Note that it’s possible to have hundreds of parameters to adjust here. No new parameters have been introduced specifically for SAP BPC, so this section highlights a couple of parameters that are important to keep in mind when optimizing the SAP BPC system.

• The rdisp/max_wprun_time parameter determines the timeout (in seconds) for a dialog process. The recommended value for an SAP NetWeaver BI system is 3,600 seconds. This value might need to be adjusted for SAP BPC.
• The abap/heap_area_* parameterscontrol how much memory your system allocates to work processes. With 64-bit platforms, individual work processes are no longer limited to just 2GB of memory. See SAP Note 146289 – Parameter Recommendations for 64-bit SAP Kernel for more details.

Concurrency-Locking Parameters

Various parts of SAP BPC can write data to the underlying SAP NetWeaver BI InfoProvider. For example, a user in a basic planning scenario might enter a number into the SAP BPC Excel client and save it to the back-end system, or a planning function that needs to update data might be running. In any scenario that writes data to the InfoProvider, it’s critical for data-integrity reasons that two different users not write to the same cell in the same InfoCube at the same time. The concurrency-locking module in SAP BPC manages data locks to prevent this scenario from happening.

When the system saves data to an InfoCube, the system performs the following high-level, concurrency-locking steps:

1. Analyze the region of data contained in the request and determine the appropriate data ranges to lock.
2. Try to obtain the lock. If the system successfully obtains the lock, it continues processing. If the system doesn’t obtain the lock — because at least one record is already locked — then it doesn’t allow the user to save the data and exits processing, which returns an error to the user informing they are working on a region of data that someone else is already trying to change.
3. If the lock was obtained successfully in Step 2, the system saves the data to the InfoCube and releases the lock.

All mechanisms that write data into an InfoCube (e.g., manual user-planning in Excel, on the Web, loading and logic from data manager) must execute a concurrency-locking check before they save the data to the SAP BPC application. There are no exceptions. You cannot bypass this concurrency- locking check under any circumstances.

When you lock regions of the InfoCube, you might not want to lock each individual record that you save. When locking records, there is a trade-off between the users’ and system’s points of view:

• The more granular the locks, the better it is for the users because they are less likely to lock unnecessary records (i.e., they only lock the very specific cells they are updating).
• The more granular the locks, the greater the amount of memory that the system requires to store the locks and the more time it takes to check them.

For example, imagine that you have an InfoCube with 10 records in it and you want to change a value in two of those records. Ideally, you just lock the two records you’re changing and allow other users to continue changing the other eight records. However, at the other extreme, you could lock all 10 records in the InfoCube. This creates a bad situation for the users — only one user can save a record at a time because each write back request will lock all 10 records. However, it is very efficient in this scenario because the system doesn’t have to spend any time determining which records to lock. It just locks them all.

There is logic built into SAP BPC to manage this trade-off, and parameters are available to tweak its behavior. You can change five parameters in transaction UJR0 (SAP BPC Write Parameters) in your SAP system, as shown in Figure 7. You generally won’t need to change these values from the default values, so we won’t go into the details of what each parameter does (you can refer to the official product documentation on help.sap.com for this), but note that these parameters exist to optimize the locking process for your specific requirements.

Figure 7

Transaction UJR0

You can define the overall logic for implementing concurrency-locking and the purpose of these parameters in the following way. (For information on changing the locks, see the sidebar below.)

SQE Parameters

The SQE is the central module for reading all of the data from an SAP BPC application. Some examples of the functions that call the SQE are the SAP BPC Excel client, the Web, and the data manager. Technically, the SQE in SAP BPC 7.0 NW consists of the following four sub-modules. These sub- modules are completely invisible to the end users. Rather, they describe the internal implementation of the SQE, and it’s important to understand them to be able to correctly configure the SQE parameters:

• RSDRI query. RSDRI (which means External Call of the Data Manager) is the function group in SAP NetWeaver BI that deals with access to InfoProviders. In the SQE, an RSDRI query means calling the internal SAP NetWeaver BI functions to read data from an InfoProvider.
• MDX query. SAP NetWeaver BI exposes OLAP BAPIs to access data from an InfoProvider through MDX. The MDX query method in SAP BPC generates the MDX statements required to retrieve data with the SAP BPC application logic applied. It is always used when there are dimension member formulas, measure formulas, or hierarchy parent values to be retrieved.
• Axis query. To request a contiguous region of data (e.g., an array of data to be displayed in a grid in SAP BPC Excel), the system uses the Axis query, which contains internal logic that determines — among other things — whether an RSDRI query or an MDX query will do the actual retrieval of data. Then, the Axis query calls the appropriate method. In some cases, the Axis query even breaks one request into multiple queries, each of which might call an RSDRI query or an MDX query, and then merges the results.
• Cell query. In direct contrast to an Axis query, this method specifically deals with requests for sparse data. A Cell query is required because SAP BPC supports users building highly formatted reports by retrieving several different individual cells from an SAP BPC application.

The parameters available to influence SQE behavior apply to the Cell query, so the rest of the “SQE Parameters” section later in this article focuses on this SQE sub-module.

The Cell Query Sub-Module

From a performance perspective, SAP BPC handles requests for contiguous and discontiguous data regions separately (namely, contiguous requests go to the Axis query and non-contiguous regions go to the Cell query). For example, consider a simple scenario with just two dimensions: category and entity. Assume one cell asks for a category equal to BUDGET and an entity equal to SALESUS, and the other cell calls for a category equal to ACTUAL and an entity equal to SALESCA. If you combine these dimensions into a single contiguous request, you need to ask for a total of four records, even though you only want two records (i.e., you would retrieve ACTUAL and SALESUS, and then BUDGET and SALESCA even though you don’t need those cells). This is an extremely simplified example — if there are 10 or more dimensions, and maybe 20 or more records being submitted, the number of permutations can grow exponentially. Therefore, the Cell query sub-module deals specifically with these types of requests with maximum efficiency.

One of the first checks in a Cell query is to determine whether the incoming request is sparse. If a record set is sparse, the records requested share very few common dimension members. Conversely, if a record set is not sparse, the records are fairly continguous. So, the Cell query logic includes a sparsity check. Transaction UJQ0 (BPC Query Runtime Parameters) in SAP BPC enables you to change the value of the sparsity parameter specifically for the Cell query, as shown in Figure 8.

Figure 8

BPC Query Runtime Parameters

The Cell query handles sparse vs. not sparse requests by changing the SPARSITY_COEF parameter. Specifically, the Cell query sends sparse requests to the MDX query method in the SQE; a sparse request can result in one or more actual data-retrieval queries. If the records requested are not sparse, then the Cell query sends them to the Axis query to request contiguous regions of data. The Axis query might return more records than you need, but for data regions that are not sparse, this is actually more efficient than making multiple requests to the InfoCube to retrieve the data. You generally won’t need to change this sparsity value from the default value, and it is a complex calculation, so we won’t go into the details of how this parameter is calculated (you can refer to the official product documentation on the SAP Help Portal at https://help.sap.com for this), but it is important to know that this parameter exists should you want to tune the behavior of the SQE.

Now that we have discussed some of the configuration options for the ABAP application server running BPC, we can take a look at some of the .NET configuration options.

.NET Configuration

Within the .NET application server, there are numerous optimization techniques available, mostly in the area of optimizing connectivity. These are two major techniques to consider:

• Number of connections, processes, and threads for .NET application and Web server. This technique is used for setting Web server parameters, such as threads and connections.
• Number of connections, processes, and threads for COM+. This technical is used for persisting connections for COM+ objects.

These settings ensure that your system performs reliably without significant cost to concurrency and performance response times.

Number of Connections, Processes, and Threads for .NET Application and Web Server

To ensure that users can gain access to the .NET application and Web server when numerous concurrent requests exist, set the number of threads and processes in the Machine.Config file correctly. The Machine.Config file is located in the Microsoft.NETFrameworkv1.1.4322Config directory. (For more details about defining these parameters, see the Microsoft knowledgebase article at https://support.microsoft.com/kb/821268.)

The configuration options include:

• maxWorkerThreads. The maximum number of threads for traditional unrestricted threads. The default is 20, but the recommended default value for SAP BPC is 100.
• maxIOThreads. The maximum number of threads for I/O objects, such as a stream or a pipe. The default is 20, but the recommended default value for SAP BPC is 100.
• minFreeThreads. The minimum number of free threads required to execute a request. If a sufficient number of threads isn’t available, the request remains queued and periodic checks for thread availability continue until the required number of threads is present. The default value is 8, but the recommended default value is calculated as “88 x # of CPUs on server”.
• minLocalRequestFreeThreads. The number of free threads that Microsoft’s Web application framework, ASP.NET, keeps available to allow new local requests to execute. (ASP.NET is the successor to Microsoft’s Active Server Pages [ASP] technology.) The intent is to avoid a possible deadlock with recursive reentry into the Web server. The recommended default value is calculated as “76 x # of CPUs on server”.
• appRequestQueueLimit. The maximum number of requests that ASP.NET queues for the SAP BPC application. ASP.NET queues requests when there are insufficient free threads to process the requests. The recommended default value is 500.
• connectionManagement. If deploying where the Web servers do not reside on the same servers as the Application servers, adjust these HTTP TCP/IP connections settings. This controls the maximum number of connections allowed to the server.
• executionTimeout. The maximum number of seconds a request can execute before ASP.NET automatically shuts it down. The default is 90 seconds. However, for ABAP dialogs, the default timeout is set to 300, so you should logically set executionTimeout to match your ABAP timeout.

Number of Connections, Processes, and Threads for COM+

Because COM+ components establish some of the connections between the client and the .NET application server, set the pool size for COM+ object application pooling (pooling for a COM+ component allows multiple instances of it to remain in a pool for any future requests to the component). OSoftSystemConfig COM+ is the primary component for which you need to set up application pooling. This COM+ component is used for SAP BPC connections, and it is recommended that you set this to 2.

To set this parameter to the recommended value, follow these steps:

1. Log in to Windows on the .NET application server.
2. Select Start > Control Panel > Administrative Tools > Component Services (options could vary slightly depending on the operating system you are running).
3. Under Component Services, click COM+ Applications and then click OSoftSystemConfig (Figure 9).
   
   
   
   

   Figure 9

   Component Services
4. Right-click the relevant COM+ application, and then click Properties. First, right-click OSoftSystemConfig and set its properties as specified in step 5, and then repeat this step and step 5 for OSoftDataService.
5. On the Pooling & Recycling tab, change the application pool size to 2 (Figure 10).

Figure 10

Component services application pooling

Although several SAP BPC releases are available, the focus here is on SAP BPC 7.0 NW. The architecture of this new release differs fundamentally from the OutlookSoft architecture that preceded it. The connectivity between the different tiers in this architecture (clients, .NET application and Web servers, and ABAP application server) is also different and needs to be set up and configured. In addition, you can configure various technical parameters, including both ABAP parameters and .NET parameters. Some of these parameters are purely system options, such as timeout settings, thread and work processor settings, and so forth. Others, while still technical, are more functionally oriented, such as concurrency-locking and SQE parameters. You should now have an appreciation for the overall SAP BPC architecture, and understand how connectivity needs to be set up between the various tiers. In addition, you should now also have an understanding of the different types of parameters that can be configured to influence the system behavior.

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.

Prakash Darji

Prakash Darji is an experienced professional with more than 10 years of end-to-end experience in enterprise software. He has a broad depth of experience including corporate strategy, sales, product management, architecture, and development. He has experience in product launch activities, including positioning, packaging, and pricing. He has delivered numerous product releases in a variety of capacities through his career. He thrives on building high-performing, scalable teams to achieve strategic deliverables, whether they close strategic sales deals, roll in product features, or roll out new releases. He is a recurring author for several publications and a speaker at SAP conferences around the world. Prakash is on LinkedIn at https://www.linkedin.com/in/prakashdarji.

You may contact the author at editor@BIexpertOnline.com.

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