BEx-Userexits reloaded
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.
Author : Hendrik Brandes
No comments:
Post a Comment