Author : Hendrik Brandes
After the initial release of the BI-Tools framework for BEx-Exitvariables in Easy implementation of BEx-Userexit-Variables I got a lot of useful comments and suggestions. And finally, I realized, that I omit a detailed discussion and implementation of the I_STEP 3 ( check after variable-screen ).
Please read first my first blog, because there are a lot more informations about the process and the variable implemenation. This blog talks mostly about experiences and refactoring.
Existing experiences
I have talked to some people, which are using this framework and I have seen some other implementations based on BADI or function modules.
When introducing the object-oriented approach, you can obtain some advantages:
- Traceability: Every Variable is clearly defined and can be relocated very fast ( without scanning a lot of ABAP coding)
- Self-documenting Implementation: The variable-interface has been defined for an easy use and not for encapsulating the technical customer-exit interface
- Reusablitiy: Reduce variable code by inheritance and specify only the necessary code within your concrete variable
- Stability: If one of the variables has a failure, just this coding is not usable. If you have another approach like includes or big function-groups, this is not guaranteed by default.
- Testability: Using ABAPUnit with ABAP OO-Bex-Variables is very easy and efficient.
The usage of the BEx-Variables framework has also shown, that an object-oriented approach is easier than plain function modules, if a clear interface is used. I found one example, where even young developers without a lot of development knowledge implemented BEx-Variables.
Why reloaded?
The original implementation has two problems:
The I_STEP = 3 has been implemented as "normal" variable instance and so it has not been very much possiblities to configure and implement this for special queries/infoproviders. This leads to the situation, that all coding has been implemented in one variable-class which handled a lot of different use-cases (and this has not been the original idea of "Separations of concerns").
A spelling mistaked has been slipped into the naming of the methods - so this could lead into a misunderstanded usage when implementing authority-variables.
So, I enhanced the existing solution and perform a small but effective refactoring. The actual code is checked into code-exchange and can be installed via SAPLink.
Refactoring
Instead of having one interface, which implement all steps, I decided to split the existing variable-interface into two interfaces:
The existing variable interface - without step 3 ( and renaming method for i_step = 0)
A new check-interface handling I_STEP = 3
A short look into the UML-structure:
As you may notice there is another new class called "ZCL_BIU001_CHECK_COLLECTION". This has been necessary, because a check can be resolved through a infoprovider assignment or a special query. Within the new customizing it is possible, to define checks based upon those two criterias. Not enough: these parameters could be configured as pattern-based parameters, so you can specify a special check for a class of queries / infoproviders.
Details
In the following, I will show the main changes.
Variable-Interface
Check-Interface
Additional, the variable-include has been enhanced (a little bit ;-) ):
Customizing
The customizing has been changed, so that there are two customizing tables: One for the variables and one for the checks.
I would suggest to use them together in one view-cluster. And if you defined the views, think about the DDIC capabilities like search-helps, maintenance-views, foreign-keys. Through the usage of ABAP Interfaces, it is possible, to check at customizing time, if a class implements the correct interface!
Conclusion
Author use the described framework intensively and like the simple usage and the fact, that the original very technical calling has been hidden by two suitable interfaces.
