NEWS AND BLOG

In this blog, I will discuss In-memory planning in BW on HANA, also known as the Planning Application Kit (PAK). It was released about 2 years ago to improve the response time for planning applications together with SAP BW on HANA, it enables businesses to achieve better budgets and forecasts through faster planning and simulation.

Before we have a closer look at the Planning Application Kit (PAK), let’s understand the difference between in-memory planning and classical planning solutions. A classical planning solution is delivered using SAP BW Integrated Planning (BW-IP) on a non-HANA database and while this has been the mainstay for many BW based planning applications in the past, the BW on HANA capability fundamentally changes what can be delivered for business planning.

The Database Layer is the layer where data resides and is moved into the Application Layer where business logic is executed. The Application Layer is further divided into two sub layers - Orchestration Layer and Calculation Layer, the Orchestration Layer decides what has to be executed and when. The reason for this is that when the planning application is started the Orchestration Layer knows the name of the planning function, query and when to trigger these whereas the Calculation Layer actually executes the query. If you execute a planning function in a classical approach, the Orchestration Layer reads the definition of the planning function, builds up the variable selection and then passes on the job to the Calculation Layer that actually does the calculation.

Figure 1

In the figure above, the width of the arrows describe the volume of data transferred. You can see that the biggest data flow is between the calculation part and the Database Layer because every piece of data you want to calculate has to be read from the database and transported into the Application Layer. The Calculation Layer handles the different types of calculations such as aggregating, disaggregating data, copying, deleting and revaluating data. This layer then calculates the new results and finally saves the data back to the Database Layer. There is only a small amount of communication between the Orchestration Layer and the Presentation Layer.

In Memory Planning on HANA (Planning Application Kit) With In-memory planning on HANA all steps, data read, calculations and write-back, are done in HANA completely, the components remain the same – Database Layer, Application Layer and User Interface Layer (Figure 2). The main difference is that the Calculation Layer is moved from the Application Layer down into the Database Layer. This means if you view it from the top of the system it looks very similar, we have the Presentation Layer with the user interfaces, we again have an Application Layer where the Orchestration Layer handles what planning functions should be executed, and what query should be started. But now we don’t do the calculation in the Application Layer but move it down to the Database Layer to SAP HANA.

Figure 2

The biggest advantage of this approach is that it reduces the heavy flow of data. This is because the system does not spend time transporting large datasets back and forth from the database to the application tier for time consuming calculations or algorithms. The data resides and stays within the HANA Layer and also uses the better calculation performance of the HANA server, which is much faster than the ABAP application server.

Now, let’s have a look at the following scenarios where we can see the difference between these two approaches.

In Figure 3, assume that a business planner wants to change the FY 2014 plan for the UK from 350 GBP to 400 GBP.

Figure 3

Key assumptions of the data model include:

52 weeks per year 400 branches for which you need to plan

If this plan is executed based on the BW-IP architecture in Figure 4, the operations occur as follows:

1. Determine the delta between the old record and new record > +50 2. Disaggregate the delta (in the application server) to: • different weeks i.e. 52 weeks in 2014 • different branches i.e. 400 • 20,800 combinations and values

3. Send 20,800 values to the database to save (from the application server to the database server)

All of the above logic will take a few minutes to execute in BW-IP.

Figure4

Now let’s look at the same planning cycle based on Planning Application Kit in Figure 4, with the SAP HANA based approach. The operations occur as follows:

1. Determine the delta between the old record and new record > +50 2. Send one value i.e. +50 to the HANA database with instruction to disaggregate 3. Disaggregate the delta (in the database engine) to: • different weeks i.e. 52 weeks in 2014 • different branches i.e. 400 • 20,800 combinations and values 4. Create and Save 20,800 values to the database

In this case, with Planning Application Kit enabled, it will take only few seconds to execute.

This means that now the user can quickly forecast, budget and run more simulations of forecast before finalizing the numbers, it will help them to yield better forecasts and improve business productivity. With Planning Application Kit, users can also plan at a greater level of granularity which was not possible with the traditional planning approach. For example, users can easily plan at Customer and Stock-keeping unit level for profitability without having any performance issues.

Deployment options for planning with SAP BW on HANA Let’s have a look at how planning can be modelled in the BW system in today’s landscape.

There are three ways of doing this, two ways of representing the classical approach plus with a new Planning Application Kit which is in-memory planning, a new approach.

In Figure 5 below these options are explored in detail.

Figure 5

Option A – This is the traditional planning approach with classical database, SAP BW with integrated planning and user interfaces like BEx Analyzer, BEx web or Business Objects Analysis for Office as an alternative excel front end. These user interfaces can be used for BW-IP and the PAK as well.

Option B – Here only the classical database is replaced with the HANA database. So first SAP HANA database installation and then database migration is required. BW-IP and front end just stays exactly the same. It is somewhat a classical approach where all the planning calculations are still done in the ABAP Layer. Performance wise, this approach is pretty similar to the case where BW Accelerator is used except for the fact that readings are little bit fast because the Orchestration Layer is in the indexed table and also writing back to HANA is little bit faster. But it is very similar to an approach where we use BWA for BW-IP implementation.

Option C – This is a new approach where deep in-memory integration is used for planning. If you view it from the front end, everything still stays the same. Same frontend i.e. BEx Analyzer or Analysis for Office is used but now we see a new application called ABAP Planning Application Kit instead of BW-IP. This is basically the Orchestration Layer that we have been talking about beforehand and now all the performance intensive parts are moved down to the HANA, the planning engine, calculation engine, the delta buffer and so on.

Now, let’s assume you have a customer that has an already existing classical BW-IP implementation. Only database migration is required if customer want to move from classical BW-IP to classical BW-IP on HANA database (option A to B). But if customer wants to move from classical BW-IP on HANA database to Planning Application Kit (option B to C), it is fairly simple. You don’t have to re-model or re-do your system, all you have to do is set some switches or toggle switch the system. Basically it is the parameter which need to be changed in the RS Admin table (3 parameters). But important thing is that you can just switch over from a BW-IP implementation to the PAK and as well you can go back again.

Among these three switches in the RS Admin, the first one is system wide which you can either make the system run as a BW-IP or as a Planning Application Kit with full in-memory integration. The second switch allows you to set the individual cubes to run with BW-IP model or with PAK model, the third switch is for the user. The idea behind this user switch is that for example if an administrator suspects that there are problems with PAK, he could just do performance measurements and see the difference in run time by switching from PAK to BW-IP for their own user only to do the test, then switch it back to PAK.

Now the most important thing, and this also explains why this switch works in both the directions. In PAK we use exactly the same customising object as in BW-IP i.e. we still use queries, planning functions, aggregations levels, filters, characteristic relationships and so on. That means you can even build a model in BW-IP and just switch over to PAK. It works because the difference is not in the object we use but the difference is in where we execute the object. This means the Orchestration Layer in BW IP and PAK are nearly the same, it’s just about where the calculation layer sits. That’s why you can easily switch from BW-IP project to PAK and even go back if you want to. You can use exactly the same front ends and it will never know whether the planning functions are executed in HANA or ABAP in BW-IP.

By Jennifer Millard

Jennifer is AgilityWorks' resident Growth Hacker, working tirelessly with each business unit to bring you the latest and greatest technology and software innovations on the market. In her free time Jennifer is a keen cyclist, although she seems to spend more time falling off the bike than riding it.