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 (BTW: I love the new corbu design - well done :wink: )
Check-Interface
Additional, the variable-include has been enhanced (a little bit 😉 😞
*&---------------------------------------------------------------------*
*& Include ZXRSRU01
*&---------------------------------------------------------------------*
DATA:
lcx_exception TYPE REF TO zcx_biu001_execution_failed,
lc_check TYPE REF TO zif_biu001_check,
lc_variable TYPE REF TO zif_biu001_variable.
TRY.
* Special treatment of check in i_step = 3
IF i_step <> 3. "Sorry for this...
* Every variable is encapsulated through an atomic instance
lc_variable = zcl_biu001_var_factory=>get_var_instance( i_vnam ).
IF lc_variable IS BOUND.
lc_variable->initialize(
i_vartyp = i_vartyp
i_iobjnm = i_iobjnm
is_cob_pro = i_s_cob_pro
is_rkb1d = i_s_rkb1d
i_periv = i_periv
).
CASE i_step.
WHEN 0.
e_t_range = lc_variable->authority_check( ).
WHEN 1.
e_t_range = lc_variable->before_variable_screen( ).
WHEN 2.
e_t_range = lc_variable->after_variable_screen( i_t_var_range ).
ENDCASE.
ENDIF.
ELSE.
* Check the variables via a check-instance. If more than one instance is available,
* a collection is automatically used.
lc_check = zcl_biu001_var_factory=>get_check_instance( i_s_rkb1d ).
IF lc_check IS BOUND.
lc_check->value_check( i_t_var_range ).
ENDIF.
ENDIF.
CATCH zcx_biu001_execution_failed INTO lcx_exception.
CALL FUNCTION 'RRMS_MESSAGE_HANDLING'
EXPORTING
i_class = lcx_exception->if_t100_message~t100key-msgid
i_type = rs_c_error
i_number = lcx_exception->if_t100_message~t100key-msgno
i_msgv1 = lcx_exception->if_t100_message~t100key-attr1
i_msgv2 = lcx_exception->if_t100_message~t100key-attr2
i_msgv3 = lcx_exception->if_t100_message~t100key-attr3
i_msgv4 = lcx_exception->if_t100_message~t100key-attr4.
RAISE no_replacement.
ENDTRY.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
I use the described framework intensively and I like the simple usage and the fact, that the original very technical calling has been hidden by two suitable interfaces.
All the coding and documentation will be found within the code-exchange area "BI-Tools": https://cw.sdn.sap.com/cw/groups/bi-tools. Please do not hesitate to join or ask any questions about implementation details or how to install it. I have attached the current nugget to this blog.
Have fun!
- SAP Managed Tags:
14 Comments
