SAP BusinessObjects Planning and Consolidation is designed to empower the business by reducing its dependency on the IT department for making system changes. Application administration is an area that is usually in the hands of the IT department. With SAP BusinessObjects Planning and Consolidation, business users can directly configure many objects, such as dimensions, applications, users, and security. This allows them to help themselves and avoid having the IT department become a bottleneck in setting up, or making changes to, the system. 

Throughout this article, we will call out much of the complexity that has been hidden from the user in the interest of supporting business user configuration. For example, when you are creating an application in SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, you never need to think about data modeling, line item dimensions, or any such IT-specific concerns because the system takes care of all of it.

Although someone working in the Admin client doesn’t need to know what goes on behind the scenes, it can be very helpful to understand what is really going on when a new application is created. You can use this knowledge for better error tracking, debugging, custom developments, tuning performance, and understanding what can and can’t be changed in SAP NetWeaver BW directly.

The user experience is almost identical (even for administration) between SAP BusinessObjects Planning and Consolidation, version for the Microsoft platform, and SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver. However, the back-end implementations are quite different. All the content and behavior we describe in this article apply just to the version for SAP NetWeaver.

Application Management in the Admin Client

You can think of an application in SAP BusinessObjects Planning and Consolidation as being like an InfoCube, although an application is much more than that. Figure 1 shows the SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver Admin client, where we’ve selected the PLANNING application.

Figure 1

Application management in the Admin client

The Admin client is broken into three sections:

• The left side (underneath the PLANNING application) contains options such as Work Status Settings, Dimensions, Business Rules, Journals, and Script Logic. All these objects belong to the selected application.
• The middle section contains the application properties (e.g., Description and AppType)
• The right side contains the Action Pane, which describes what actions you can perform. In this case, we can modify or delete the application. We can also optimize the application’s performance.

Before we delve into some of these details, let’s understand what it takes to create a new application.

Create a New Application

Once you have created your AppSet and Dimensions, you can create your applications. Select the option to create a new application (via the Action Pane). The system prompts you to enter some information via a step-by-step process:

Step 1. Enter a description. Enter a name for the application and a longer description.

Step 2. Select the application type. An application type provides a semantic definition of the application. For example, you can use the financial application type for both reporting and planning. It has built-in intelligence to deal with currency conversions. Consolidations is another application type designed specifically for performing legal consolidations. Overall, six application types are available, including two generic ones that you can use for any purpose.

In addition to providing built-in intelligence, the application type also determines which dimension types must be assigned to the application. (See our article “SAP BusinessObjects Planning and Consolidation: Business-Owned Administration: AppSet and Dimension Management” if you aren’t familiar with the dimension type concept.) For example, if you create an application and select the consolidations application type, then your application must contain the following dimension types: account, category, entity, time, and DataSource. This is required so that the built-in consolidation logic can work with your new application, which allows you to skip a lot of other configuration — and as a result, save significant setup time.

Step 3. Select the related objects. The settings you see in this step depend on the application type that you selected in step 2. Figure 2 shows what the Action Pane looks like in this step with the consolidation application type selected. We specifically selected the consolidation application type in this example because it has the most options to fill out in step 3. If you select any other application type, fewer fields are displayed.

The Select Source Application field is the only field that appears for every application type. This field allows you to copy an existing application so you don’t have to configure each new application entirely from scratch. There must always be at least one source application from which to select. SAP BusinessObjects Planning and Consolidation includes some applications that you can use as a source in the ApShell application set that is created during installation.

Next are the Rate application and Ownership application fields. Use these fields to indicate which application stores the exchange rates and which stores the group ownership data, respectively. The system populates the drop-down boxes for this information automatically with the available applications. In this case, these options are only presented because the business scenario (i.e., application type) selected in step 2 was for financial consolidations. The ownership application, as an example, would never be presented for any other application type because it is only relevant for consolidation scenarios.

The final selections in Figure 2 are the business rules. We will not cover the scope of what business rules do in this article, but suffice to say, they contain prebuilt business logic for financial consolidations, which you can customize to meet your specific needs.

Step 4. Select the dimensions. When you move to the next step, the system presents you with a few more check boxes, asking you what type of settings you want to copy from the source application you selected in step 3. The most important one is the first one, called Dimensions. If you leave this check box selected, the system creates your new application with the same dimensions as your source application.

If you deselect the Dimensions check box, then you need to specify them manually. In that case, there is really one more step (let’s call it step 4a). Figure 3 shows you the screen where you manually assign dimensions to your application.

As you can see in Figure 3, the middle section of the Admin client now shows you a list of all the dimensions in this AppSet (left box). Select which dimensions you want in your application, and click the right arrow icon to move them to the right box. Inside the boxes, the Type column tells you the dimension type for each dimension.

The only other setting you can apply here is to secure a dimension (indicated by the S column). In Figure 3, the application we created is secured against the category and entity dimensions, restricting the data end users can access. The entity dimension is often secured because you generally want to limit people’s authorizations to their own area of responsibility (e.g., limiting cost centers to only the ones the user is responsible for managing or only allowing store managers to see and change data for their individual stores).

Click Add a New Application in the Action Pane and the system generates all the required objects behind the scenes for you. Although it took several pages to walk through all the details of each option, you can really click through these options and create a new application from scratch in under a minute. Let’s take a look at what happens in SAP NetWeaver BW when you create a new application.

Application Management — Behind the Scenes

The first thing you should know is that more than one InfoProvider is generated in SAP NetWeaver BW. In this process, the system generates the following:

• A transactional/real-time InfoCube
• A MultiProvider (which maps 1:1 to the underlying InfoCube)
• A BEx Query on top of the MultiProvider

Figure 4 depicts the relationship among these objects. It shows how the system reads and writes data to and from the underlying InfoCube. All the SAP NetWeaver BW objects are created under the InfoArea that maps 1:1 to the AppSet you are working in (as discussed in the article “SAP BusinessObjects Planning and Consolidation: Business-Owned Administration: AppSet and Dimension Management”). All these objects also have generated technical names, which means that end users don’t have to think about concepts that are foreign to them, such as technical names.

You may have noticed that in Figure 3, you were not asked for characteristics for dimension assignments, key figures, line item dimensions, or any of the other usual type of information you would need to enter in SAP NetWeaver BW to create an InfoCube. However, the system generates an SAP NetWeaver BW InfoCube automatically. All the other details have been automatically taken care of for the user in the form of built-in algorithms created in SAP BusinessObjects Planning and Consolidation. In Figure 5, you can see that the system created BW Dimensions (not to be confused with Business Planning and Consolidation [BPC] Dimensions) and assigned the characteristics.

Although this is a normal SAP NetWeaver BW InfoCube, you should understand a number of important points about these generated InfoCubes. The first thing is that these InfoCubes can sometimes be transient. The base InfoCube may change to a completely different InfoCube in SAP NetWeaver BW. The MultiProvider is always the same technical object, but the base InfoCube can change.

This can occur for multiple reasons, but an example would be during the optimize process (the action to optimize an application was shown in Figure 1). Because you are automatically determining the ideal data model for the InfoCube (i.e., the characteristics to dimensions assignments), you might find that the most optimal structure changes over time. In that situation, you create a new InfoCube with the ideal structure, copy all the data over to the new InfoCube, tell the MultiProvider to ignore the old InfoCube, and then delete the old InfoCube.

A benefit of having your base InfoCube be transient is that there are no system restrictions on what changes you can make. In SAP NetWeaver BW, you might have encountered some restrictions on adding or removing characteristics or changing dimension assignments when an InfoCube already has data in it. In SAP BusinessObjects Planning and Consolidation, this is never an issue. You can add and remove dimensions from your application whenever you like, and you never have to worry about manually moving any of the data around — the system takes care of it all for you.

You should avoid changing these InfoCubes directly in transaction RSA1 (or any other SAP NetWeaver BW transaction). SAP BusinessObjects Planning and Consolidation stores a large amount of metadata about its applications and the underlying technical objects. Changing the object in transaction RSA1 can lead to undesirable outcomes if you aren’t familiar with any potential implications. Furthermore, the InfoCube is transient anyway, so your changes would likely be lost when the system generates a new InfoCube. As a rule of thumb, we suggest you don’t directly change anything SAP BusinessObjects Planning and Consolidation generates in the back end.

In Figure 4, we showed that all data read from the InfoCube goes through the shared query engine. Although we do not cover the full scope of the shared query engine in this article, it is important to know that it does some post-processing of the data retrieved from SAP NetWeaver BW. For example, the shared query engine handles the fact that the value of balance sheet accounts should not be accumulated over time (standard SAP NetWeaver BW exception aggregation is not used to do this). The shared query engine can also handle sign transformations (e.g., if you want to report revenues and liabilities with a negative sign).

Some other examples of logic in the shared query engine are resolving the value of SAP BusinessObjects Planning and Consolidation calculated members and the handling of time calculations. That means if you try to read the data directly out of the base InfoCube, the MultiProvider, or the generated BEx query, you will likely get different results than if you went through the shared query engine. Therefore, you should not try to compare the results in an SAP BusinessObjects Planning and Consolidation report with the values you retrieve via an SAP NetWeaver BW query on top of the InfoCube, via transaction LISTCUBE, or by using any other traditional method. Integration enhancements are planned in this area for the next release of SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver (currently scheduled for late 2009).

In addition, SAP BusinessObjects uses a single key figure (called SignData in Figure 5). This was mentioned briefly in “SAP BusinessObjects Planning and Consolidation: An Overview of How It Works with SAP NetWeaver BW”, where we also described the concept of a measure. A measure formula is somewhat like a calculated key figure in SAP NetWeaver BW, and they, too, are resolved inside the shared query engine. The use of a single key figure is an example of SAP BusinessObjects Planning and Consolidation valuing simplicity over total flexibility. If multiple key figures were allowed, then it would be critical that the user understand data modeling, and the implications of choosing an account model over a key figure model.

In our experience, we often find that Business Planning and Simulation (BPS) or BW-Integrated Planning (BW-IP) InfoCubes have been created with the account and key figure models combined in the same InfoCube. This is disastrous for performance, reporting, and ongoing maintenance. SAP BusinessObjects is designed to empower business users, who are generally not familiar with such data modeling techniques. Limiting the option to the account model only (via a single key figure), prevents bad InfoCube designs. Although this can have some trade-offs in situations in which multiple key figures are used, the account model does not impose any restrictions on what you can or can’t do. For large data sets with numerous key figures, you can explore other options such as using the SAP NetWeaver BW Accelerator.

What Else Happens When an Application is Created?

The final thing we want to cover in this article is what else, beyond just generating SAP NetWeaver BW InfoProviders and Queries, is happening in the back-end SAP NetWeaver BW system when a new application is created. The following list highlights the major activities that the system generates when creating a new application:

• Data Manager packages. BPC Data Manager sits on top of SAP NetWeaver process chains. The system uses these packages for any batch processing of data, such as extraction, transformation, and loading (ETL) or running scripts or planning functions to change the data.
• Report templates (for the BPC Excel client)
• Directories in the file system are for all objects, such as report templates. Note that in the version for SAP NetWeaver, a true file system is not used because all data and objects are stored in the underlying database.
• Script logic, which is the scripting language used to create planning functions and other custom algorithms to analyze and manipulate data stored in SAP BusinessObjects Planning and Consolidation
• Audit tables. The system can optionally keep record of every change in the InfoCube.
• Business rules (depending on your options)

Many other functions are set up for you as well, including comments, journals, Web admin parameters, work status, and default measure formulas. These functions depend on your configuration options, such as the application type. In addition, the SAP NetWeaver BW objects we described earlier are created.

Although some of the SAP BusinessObjects Planning and Consolidation terms used in this list might be new at this stage, the important thing to understand is that by walking through the four steps we went through earlier, we had to have no knowledge or understanding of these other components or what was going on. Hopefully you can now see why we said that an application is more than just an InfoCube. We also hope you can see just how much complexity was hidden from the user, who only had to understand a few basic terms (which were not technical terms) and walk through the four-step guided process to create all of this. Modifying an application is just as easy as creating one, too.

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.