Framework for Customer Exit OLAP Variables

[sander_vanwilligen]

Customer Exit OLAP Variables require ABAP coding which often can be found in a single INCLUDE program ZXRSRU01 as part of legacy Enhancement RSR00001 (a.k.a. Customer Exit EXIT_SAPLRRS0_001). Usually the INCLUDE program becomes bigger and bigger. Moreover, various people and/or project teams are working in the same place. You can imagine that it is dangerous because one programming or transport sequence mistake can destabilize the entire system. The solution is encapsulation of the coding of individual variables and you will need a framework to realize it.

In this blog I would like to discuss the latest enhancement technology to be used. Moreover, I will present an alternative approach for implementing a framework and the advantages it can offer you.

Please refer to my document Implementing Framework for Customer Exit OLAP Variables for a detailed step-by-step instruction for implementing the framework.

New Enhancement Spot

In SAP BW release 7.3 a new Enhancement Spot RSROA_VARIABLES_EXIT for Customer Exit OLAP Variables was introduced. It contains BAdI RSROA_VARIABLES_EXIT_BADI which can be impemented multiple times using an appropriate filter. It also contains a default implementation SMOD_EXIT_CALL to call program ZXRSRU01 as part of legacy Enhancement RSR00001.

I can recommend reading blog New BAdI RSROA_VARIABLES_EXIT_BADI (7.3) for more detailed information. Although it is a big improvement, I would like to suggest a more sophisticated approach to take the encapsulation to the next level.

Framework

My alternative approach indirectly uses standard SAP’s new BAdI RSROA_VARIABLES_EXIT_BADI. Instead of implementing this BAdI for every new variable, I introduce an intermediate layer: a new custom Enhancement Spot YBW_OLAP_VAR with 4 BAdIs (corresponding to the processing steps). The following 4 BAdI Definitions are available:

• YBW_OLAP_VAR_BEFORE_POPUP - OLAP Customer Exit Variables - Before Popup (i_step = 1);
• YBW_OLAP_VAR_AFTER_POPUP - OLAP Customer Exit Variables - After Popup (i_step = 2);
• YBW_OLAP_VAR_VALIDATION - OLAP Customer Exit Variables - Validation (i_step = 3);
• YBW_OLAP_VAR_AUTHORIZATION - OLAP Customer Exit Variables - Authorization (i_step = 0).

Only once BAdI RSROA_VARIABLES_EXIT_BADI will be implemented in a generic way. Here the respective BAdI implementation will be called dynamically according to the processing step and filter on variable name (except processing step 3 where I propose to filter on query name).

Rationale

The main reason for implementing such a framework is achieving a safer system that is much better/easier to manage and support. The main advantages are in my opinion:

• Every BAdI implementation is independent of all others, the encapsulated pieces of coding (residing in their own implementing class) can be maintained and transported independently and therefore eliminating risks which can destabilize the system;
• The BAdI implementation is filtered on variable name (except processing step 3 where I propose to filter on query name), only one BAdI implementation will be processed every time;
• The BAdI implementations are grouped by processing step (i.e. before pop-up, after pop-up, etc.) which increases transparency;
• There is no need anymore to program a filter on variable name (CASE I_VNAM. etc.) and the processing step (e.g. IF I_STEP = 1.) in a nested way, the framework is taking care of that and contains appropriate error handling;
• The Enhancement Spot technology is the latest and way forward technology for enhancing the system, it's using ABAP-OO programming technology and can optionally (not mandatory) be combined with the Switch Framework, you can find more information in the blog Simplify & structure your Enhancements by using Switchable Kernel BAdIs.

Migration

Most likely you are not working in an empty greenfield SAP BW system and you might find a considerable implemention effort in INCLUDE program ZXRSRU01 and/or any preceding framework (e.g. using Function Modules). If you decide to switch over to a new way-of-working, you will not be able to migrate all existing content in one go. Usually you will migrate gradually using a “phase in, phase out” approach. In other words, the legacy implementation and the new implementation have to live together in the same system for the time being.

This is possible but one “hidden” aspect will pop up as soon as you will create your first new implementation. The standard SAP BAdI implementation SMOD_EXIT_CALL will not be called anymore. This implementation is used to call INCLUDE program ZXRSRU01 as part of Enhancement RSR00001. Since this implementation is flagged as a “default implementation”, it will not be called as soon as any normal implementation is found.

The solution is creating another RSROA_VARIABLES_EXIT_BADI implementation which replaces the SMOD_EXIT_CALL implementation. It must be an exact copy of the standard SAP implementation so that it will call the legacy implementation in the same way.

You can find more information in blog Coexistence of BAdI RSROA_VARIABLES_EXIT_BADI and Customer-Exit EXIT_SAPLRRS0_001.

Conclusion

In this blog we discussed a new way of implementing Customer Exit OLAP Variables. The framework consists of an intermediate layer: a custom Enhancement Spot and 4 BAdIs which correspond to the processing step. The respective BAdI will be called dynamically using a single generic implementation of standard SAP BAdI RSROA_VARIABLES_EXIT_BADI. After an overview of the advantages of such an approach, we discussed the topic migration that is applicable in almost all cases.

If you are interested to know all about it, please refer to my document Implementing Framework for Customer Exit OLAP Variables. Here I will share with you detailed technical instructions how to implement such a framework.