As you may know, BPC 10.0 NW sits on top of BW 7.3. BW 7.3 can run on HANA – SAP’s in-memory database.
Figure 1: Putting SAP BW onto HANA
So, as opposed to running BW on a regular database, we use HANA as its database – easy.
Thus, it’s only logical that BPC 10.0 moves onto HANA as well – since the underlying BW 7.3 system moves onto HANA. With Service Pack 6 of BPC 10.0 NW we will officially “certify” that BPC 10.0 does indeed work on top of BW 7.3 running on HANA. The beautiful part is that you don’t have to re-implement BPC. The application and front-end layers stay the same – your BPC environments, script logic, ABAP code, Business Process Flows, reports etc stay intact without you having to migrate them.
This is what the BPC on HANA stack looks like:
Figure 2: BPC on HANA stack
This stack has some inherent benefits. For example BPC environments are now in-memory optimized:
Figure 3: BPC Planning cube - in-memory optimized
That means that the cube structure is much simpler compared to a conventional BW where cubes have a “snowflaked starschema” with 2 fact-tables (E and F), dimension IDs tables etc.
Figure 4: with HANA we move from a complex cube structure to a simpler schema
An in-memory optimized cube has far fewer tables than a traditional cube:
Figure 5: in-memory optimized BPC cubes have simple table structures
In short, BPC on HANA is like traditional BPC – but on simple, in-memory optimized cubes. And that yields faster performance for loading and reporting.
But this is where the comparison ends… Slow processes running on the application server will not be affected by a switch of the database to HANA. Single threaded code will still be single threaded. This is, unless we push these processes down into HANA to take full advantage of HANA.
Pushing BPC functions into HANA
In order to take full advantage of HANA’s strength – highly parallelize processing on in-memory tables – we will have to shift calculations from the application server into the HANA database.
Figure 6: HANA highly parallelized processing on tables stored in-memory
That means that rather than moving raw data from the database to the application server to calculate results there, we will push calculations down into the HANA engine (similar to a “stored procedure”), execute them highly parallelized in-memory and transfer only the end-results back to the application server.
Figure 7: Moving the work load from the app-server to HANA
The beautiful thing is that SAP will rewrite the internal BPC functions to run on HANA without disrupting your existing BPC implementation. For example, at the EPM labs at SAP Financials you can test-drive a large variety of BPC functionality on HANA including
- Excel and Web reporting
- Business process flows
- Data loading and copying
- Controls and consolidations
- Journal entries
- Books publishing
We didn’t have to rewrite all this content for BPC on HANA. We simply leveraged our existing jens.koerner/blog/2011/07/19/bpc-100-nw-mega-elite-enablement-for-over-100-customers-and-partners-nov-14-18-2011-in-philadelphia exercises and swapped the database out underneath them and put in HANA.
Back to the rewrite of internal BPC functions: this will happen over time. The first big function we tackled is reporting – that is coming in SP6. So, rather than calling the BW MDX engine, we will be calling the HANA TREX engine to execute most of our reports (reports with dimension member formulas, custom measures and on year-to-date applications are still following the traditional BW MDX path - for now).
For BPC on HANA customers we do have a new add-on called HANABPC in addition the regular BPC add-on CPMBPC:
Figure 8: BW on HANA with the BPC add-on and the HANABPC add-on
This add-on is installed at BPC on HANA customers only and contains the new HANA enabled BPC functions - such as the report acceleration we deliver in SP6.
Figure 9: The new HANABPC addin with HANA optimized functions in the BW backend
So what does this all mean for performance? As we discussed in the first part, there are some inherent benefits of putting BPC on top of a BW on HANA. The graph below shows the performance lab results for a report with 500,000 rows selected from a BPC cube with 1 billion records along a dimension with 1 million master data members. The blue bar is the original result on BPC on Oracle. The red bar shows the runtime of the same report on BPC on HANA – but without pushing the report execution into the HANA TREX engine. The purple bar is the same report executed on BPC on HANA where the execution is pushed into HANA via the new add-on HANABPC.
Figure 10: inherent benefits of HANA in red, optimized results in purple
As you can see putting BPC on HANA makes the 500,000 row report run about 1.7 times faster compared to an Oracle DB. But the real performance gain is achieved when we push the execution from the BW appserver down to HANA’s TREX engine:
That makes the backend processing of the data selection and aggregation for this large report 21x faster!
Over time, more and more BPC functions such as write-back, distribution, currency conversion, consolidations etc are planned to be pushed into the HANA engine.
Benefits of BPC on HANA
So, why should you go to BPC on HANA?
First of all: it’s faster. Performance is a big topic for users and slow response times lead to un-productive users in the best case. Worst case users get so frustrated that they stop using the system and start building their own spreadsheets and “shadow”-IT – rendering your IT investments useless. The performance topic also grows in importance as data volumes not only grow but explode. So, you want to be on a platform built to handle “big data”. You want to be on HANA.
Secondly, HANA is the platform of the future. New features such as automated variance analysis or sophisticated scenario planning are considered for BPC on HANA – so we can take advantage of the blazing speed and enable scenarios that are not possible on conventional databases. So, BPC on HANA gears you up for the future.
More and more BPC functions will be accelerated and if you don’t move to BPC on HANA you will miss out.
Thirdly - Mobility: Mobile users are impatient users. Desktop or laptop users might be willing to wait several minutes for a complex report to refresh, but a mobile user won’t. After a couple of seconds, mobile users will navigate away and check their emails or latest sports scores. If your company is going mobile, then you want to be on BPC on HANA.