Best Practices on Migrating Business Add Ins (BAdIs) to SAP Business Planning and Consolidation 10.x version for Netweaver on HANA
The migration of custom built ABAP based BAdIs from a SAP Business Planning and Consolidation 10.0 version for Netweaver (BPC 10 NW) with a non-HANA enabled database to a BPC 10/10.1 NW with a HANA enabled database is, in general, is straight
forward and easy to accomplish. The migrated BAdI in the HANA environment will function as it had been while in the original non-HANA environment.
For a comprehensive general guide focusing on BAdI migration (that is not BPC specific) which provides a detailed overview of the available tools and guidance on how to use them in the context of a transition to SAP HANA, please view the guide found at: http://www.saphana.com/docs/DOC-4120 “Considerations for Custom ABAP Code When Migrating to SAP HANA – Best Practices and Recommendations”
Additional considerations to be aware of when migration to HANA for a BPC/HANA project:
Deploying with the optimized Write-Back option enabled:
If the new BPC/HANA application is deployed with the optimized Write-Back option (available since BPC 10 NW SP11, see Note 1902743 “Write-back Optim. for Planning and Consolidation 10 on HANA”) then by design of the current optimized Write-Back process the following three BAdI types should no longer be used: Write-back BAdI, Work status BAdI, nor the Validation BAdI. See Note 1902743 section “How to Activate” for details on this limitation.
The write back optimization uses a series of tables (MDX Virtual table) and HANA functions (transactions to synchronize data between native HANA DB and BW cube) to allow fast write back capabilities. Note: adding additional BAdIs implementations along with the optimized write back feature is not recommended when using HANA based disaggregation and/or allocation features in your BPC model. If using additional BAdIs under these conditions, some generated disaggregated and/or allocated results may not travel through the standard ABAP write back process and therefore may not trigger the execution of the additional BAdI logic. This situation may lead to confusion as to which data has been subject to the additional BAdI processes and therefore this practice should be avoided if at all possible.
Deploying without the optimized Write-Back option enabled:
With the introduction of a HANA enabled environment, additional calculation modeling opportunities are available from within HANA and may be considered to replace the original BAdI functionality to enhance overall functionality and/or performance. Using a HANA based stored procedure instead of a BAdI makes sense when significant data volumes are involved. For thoses business cases where only a few (or hundreds) of records are involved, a BAdI may still be the most likely best option for optimal performance. HANA based stored procedures may be created to execute a variety of calculations directly in HANA, providing enhanced performance capability when compared to a BAdI executed in the system’s application layer (i.e.: the “ABAP layer”). HANA based stored procedures typically lead to higher performance when compared to traditional BAdI execution by eliminating I/O traffic between system layers and performing calculation logic directly at the source of the data records.
As of SP11, Custom Logic type BAdIs (called via script logic) which may have been used to perform allocations may no longer be required. Calculation of allocation scripts (starting with the key word “*RUNALLOCATION” and ending with “*ENDALLOCATION”) which had been executed in the ABAP layer are now executed directly in the HANA layer (see Note 1903167 – “Allocation optimize for Planning and Consolidation 10.0 NW”). Elimination of the custom logic BAdI and replacement with a simple Script Logic allocation program is now recommended.
Additional tools to be considered when evaluation BAdI migration or re-development:
A new utility framework which can help you to create and tune Hana store procedures is available. SAP HANA can greatly improve the performance of data processing, but in order to make full use of HANA and allow application developers to free themselves from complex SQL statements and focus on the business logic SAP created a Calculation Flow Framework in the HANA BPC component. This framework allows the developer to expose “calculation nodes” and generate the HANA codes dynamically and then execute the logic. Currently only BPC disaggregation and allocation can be used with this framework. Please see note 1910359 – “Monitor and trace disaggregation and allocation in BPC Hana” for details.
I invite all readers to leave comments or share their relevant experiences.