When migrating to SAP BusinessObjects Planning and Consolidation (formerly SAP Business Planning and Consolidation [SAP BPC]), it is first important to understand the application’s architecture. This gives you an understanding of what type of hardware and environment you need to deploy SAP BusinessObjects Planning and Consolidation. Additionally, understanding the architecture is important if you are looking to upgrade from Release 5.1 of the version for the Microsoft platform or migrate from the version for the Microsoft platform to the version for SAP NetWeaver.

Architecture of SAP BusinessObjects Planning and Consolidation, Version for the Microsoft Platform

As you may know, two different SAP BusinessObjects Planning and Consolidation products are available:

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

The SAP BusinessObjects Planning and Consolidation, version for the Microsoft platform is built completely on top of Microsoft’s BI platform.

Figure 1 represents the architecture for SAP BusinessObjects Planning and Consolidation, version for the Microsoft platform. At a high level, the architecture contains three tiers. The first tier is the data tier (at the bottom of Figure 1), which represents where the system stores data. Within the Microsoft BI platform, the data tier represents Microsoft SQL Server and Microsoft Analysis Services (MSAS). Microsoft SQL Server provides the relational data storage while Microsoft Analysis Services provides the multi-dimensional data storage (i.e., the OLAP server). All transactional and master data (dimension members) is stored within this data tier. In addition, a file share stores unstructured files. For example, when a user saves a Microsoft Excel report, it is saved to the file share.

Figure 1

Architecture of SAP BusinessObjects Planning and Consolidation, version for the Microsoft platform

The next tier of the architecture is the Microsoft IIS and .NET Application Server tier. This tier has the following three types of services:

• Platform services: Provides interaction to the data tier
  
  
• Application services: Performs business logic or transforms the data or files
  
  
• Web services: Allow the clients to connect to the application services

We’ll examine a scenario to demonstrate how these services interact. This scenario just illustrates one of the many ways the Microsoft IIS and .NET Application Server tier works. Assume that you open a report in SAP BusinessObjects Planning and Consolidation to display a profit and loss statement. You open the SAP BusinessObjects Planning and Consolidation Excel client and set the desired filters in your current view. The Excel client then requests this data from the Microsoft IIS and .NET Application Server tier.

The Web services then make a request to the application services, which in turn ask for the requested financial statement data from the platform services. The platform services go to the data tier, retrieve this financial data, and return it to the application services. The application services perform any required business logic, such as calculating any figures required for the report. Once the data is sufficiently transformed so it can display a proper financial statement, it is sent back to the Web services tier, which then returns it to the SAP BusinessObjects Planning and Consolidation Excel client for display.

The last tier of the architecture is the client tier. This tier includes the end user or power user clients that you can use to interact with SAP BusinessObjects Planning and Consolidation. The different client applications available are:

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 a straightforward manner, which empowers business users to administer the system themselves.

Microsoft Office clients: Most end users primarily run SAP BusinessObjects Planning and Consolidation through Microsoft Excel. However, you can also use both Microsoft Word and Microsoft PowerPoint to interact with the application as well.

Web: A zero-footprint client option is also available for users who don’t need all the functionality that Microsoft Excel provides. In some documents, the Web client is called a zero-footprint client or thin client. Thin clients are like Web-based application Gmail, from Google ¾ they don’t require end users to install any software.

Others: SAP BusinessObjects Planning and Consolidation Server Manager is a client application that runs on the .NET application server and configures the system and connectivity details. In addition, there are other clients available depending if you are on the version for the Microsoft platform or the version for SAP NetWeaver, that perform other limited functions.

Architecture of SAP BusinessObjects Planning and Consolidation, Version for SAP NetWeaver

Since the acquisition of Outlooksoft, companies that use SAP systems have been asking for an application that runs on their existing infrastructure. Therefore, SAP built SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, on top of the SAP NetWeaver platform.

At a high level, the architecture contains four tiers (Figure 2). The first tier (at the bottom of the diagram) is the database tier, which represents where data is stored. The primary difference between the Microsoft version and the SAP NetWeaver version in this tier is that you can store data in any database that SAP NetWeaver supports. You aren’t limited to deploying only to Microsoft SQL Server. In addition, files are no longer stored in a separate file service location, but are stored within the database itself, and there is no separate OLAP storage system.

Figure 2

Architecture of SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver

The second tier of the architecture is the SAP NetWeaver BW (Application Server for ABAP) tier. This tier covers most of the application logic that was within the Microsoft IIS and .NET Application Server tier in the Microsoft platform. In addition, it also encompasses the SAP NetWeaver BW OLAP Engine for calculations and data aggregation. Technically, SAP BusinessObjects Planning and Consolidation is deployed as an add-on to this tier. SAP BusinessObjects Planning and Consolidation includes a few different object types on the Application Server for ABAP:

• ABAP Data Dictionary objects (DDIC): Describe the code and objects that SAP delivers and are installed on your SAP NetWeaver system during the application installation process
  
  
• SAP NetWeaver BW objects
  
  
• Dynamically generated SAP BusinessObjects Planning and Consolidation tables

The third tier of the architecture is the Microsoft IIS and .NET Application Server tier. Within the version for SAP NetWeaver, this tier only performs a few services, such as XML conversion and hosting Web services. Compared to the version for the Microsoft platform, this tier needs significantly less hardware because the majority of the processing resides in the SAP NetWeaver BW (Application Server for ABAP) tier.

The final tier of the architecture is the client tier. This tier includes the end-user or power-user clients that you can use to interact with the SAP BusinessObjects Planning and Consolidation. It is similar to the client tier as described in the version for the Microsoft platform.

Overall, you can see that the concepts in the version for SAP NetWeaver are similar to the version for the Microsoft platform. However, the key difference in this architecture is that most application services have been moved out of the .NET server into the SAP NetWeaver BW platform. Additionally, the version for Microsoft platform replicates data into Microsoft Analysis Services for the OLAP Engine in the data tier, but within the version for SAP NetWeaver, the application uses the SAP NetWeaver BW OLAP Engine as the calculation engine.

Implementation Requirements

When implementing SAP BusinessObjects Planning and Consolidation, the first step is to understand the prerequisites on each tier of the architecture. The version for the Microsoft platform and the version for SAP NetWeaver each have different requirements. Figure 3 shows the requirements for the version for the Microsoft platform, and Figure 4 shows the requirements for the version for SAP NetWeaver. For brevity, we will just go through the details of the version for SAP NetWeaver.

Figure 3

Prerequisites for SAP BusinessObjects Planning and Consolidation, version for the Microsoft platform

Figure 4

Prerequisites for SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver

We can start with the database tier. On this tier, the requirements for databases are the same requirements for your existing SAP NetWeaver landscape. This means that the application works on any database SAP NetWeaver supports. There are no additional prerequisites for the SAP NetWeaver BW (Application Server for ABAP) tier. The main requirement is that your SAP NetWeaver BW 7.0 system has Enhancement Package 1 applied (although we recommend also applying the latest Support Packages).

Most of the prerequisites you need to consider are on the Microsoft IIS and .NET Application Server tier. On this tier, there are numerous prerequisites from Microsoft that need to be applied to this server, as shown in Figure 4. However, it is important to read the installation guide carefully to get the most up-to-date information, and ensure you have met all these prerequisites before beginning the installation.

Finally, on the client tier, the main requirements are for Windows Versions (XP or Vista) and Microsoft Office versions 2003 or 2007 (Microsoft Vista support is undergoing testing at the time the article was written, and therefore was omitted from Figure 4). There are also some additional prerequisites for the client, as listed in Figure 4.

How the Application Uses SAP NetWeaver BW

From a business user viewpoint, a planning system must be flexible because planning processes within organizations change frequently. SAP NetWeaver BW data models are mostly static, and changes to the data models require getting the IT department or consultants involved. For frequently changing planning processes, this situation creates a bottleneck for the business. SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver is designed for flexible modeling, allowing business users to make changes themselves. This means less reliance on having to go to IT, giving ownership of the system to the business.

For example, within the dimension management capabilities of the application, business users are able to create dimensions (referred to as characteristics within SAP NetWeaver BW), hierarchies, properties, master data, etc. This allows for scenarios such as planning ad-hoc dimension members (or master data). Technical names aren’t used within the application and business users can add or remove dimension properties without needing any technical knowledge of how to administrate an SAP NetWeaver BW system.

Figure 5 shows the complexity of maintaining an Enterprise Data Warehouse (EDW) with SAP NetWeaver BW versus managing flexibly modeled applications with SAP BusinessObjects Planning and Consolidation. The complexity exposed to the user of the system is markedly less on the SAP BusinessObjects Planning and Consolidation side. However, this is not to say that one approach is better than the other. Rather, the approach you would take for building an EDW is not necessarily the same approach you would want to take for a performance management application such as SAP BusinessObjects Planning and Consolidation.

Figure 5

SAP NetWeaver BW and SAP BusinessObjects Planning and Consolidation data management

Additionally, within planning, a common requirement is to source data from another system so it can be referenced during the planning process. Within SAP NetWeaver BW, the user would either have to enter these new numbers into a planning layout manually, or would have to involve IT. Within SAP BusinessObjects Planning and Consolidation Data Manager, the user can load flat files to the InfoCube directly from the Excel client as shown in Figure 5.

The Application Namespace

We described how planning users have the flexibility to model their own applications (InfoCubes) within SAP BusinessObjects Planning and Consolidation. Most SAP IT departments would not want end users or power users to have that level of access in the EDW because users modifying and adding data and objects would introduce risk for data and system integrity. However, having to rely on IT to make every change the business needs is not a viable solution either, as the time it takes to get the required changes to be implemented in the system is too long. What typically happens then is that the business users continue to manage processes in a method they can control, which usually means keeping everything in spreadsheets. SAP is solving this problem by introducing the concept of the BusinessObjects Planning and Consolidation Namespace.

At a high level, you can view this namespace as a separate area within SAP NetWeaver BW that is like a playground for SAP BusinessObjects Planning and Consolidation administrators. They can perform all their modeling needs in this namespace, but they can never leave their playground. Therefore, these users cannot affect the EDW’s integrity, but they can meet all of their business needs. Because all the data is stored in a single SAP NetWeaver BW system, once the plans are complete and locked down, the business can work with IT to easily bring this information back into the EDW if needed.

Migrating to the 7.0 Version for SAP NetWeaver

Migrating from SAP BusinessObjects Planning and Consolidation 5.1, version for the Microsoft platform to the SAP BusinessObjects Planning and Consolidation 7.0, version for SAP NetWeaver involves a series of migration tools that automate a significant portion of the migration. However, while some components will be migrated completely, other components will require some manual work, and other specific components do not migrate at all. At a high level, the migration tool involves migrating all master data, transactional data, and data models. The major pieces that do not migrate include Data Manager packages as well as Script Logic code. As part of the migration, you would therefore need to rework these two components for example.

Organizations that wish to stay on the version for the Microsoft platform may continue to do so, and upgrade to the successor release (7.0, version for the Microsoft platform). This successor release is an evolutionary release from version 5.1, and therefore an upgrade is a fairly straightforward process. SAP is continuing to invest in both the version for the Microsoft platform and the version for SAP NetWeaver going forward, so customers are completely free to pick whichever platform best meets their requirements.

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.

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.