Customize your ABAP Object-Factories

After writing my two blogs Factory-Pattern in ABAP OO and Easy implementation of BEx-Userexit-Variables I was asked, how a efficient customizing table for those classes looks like.

A short history: The factory pattern creates instances of objects which should implement a specific interface. These classes have to be customized, so that the code does not change with new classes or requirements. For this, I use a customizing table, which I create in the dictionary.

The simplest way will be, to create a customer-table ( Z-Table ) and make a maintenenance dialog for this. But some features are still missing:

• Only those classes are selectable, which implement the desired interface / at least you can point XYZ in this without any checks.
• There is no documentation hint about the class - you only see the technical name
• You do not have a semantic link to any other objects ( e.g. Company Code, Material or in my last example BEx-Customerexit-Variables )

What to do? Use the existing dictonary features ( and they are also avaiable within a BW ).

In the following I will show, how to build a customizing table for the BEx-Customerexit-Implementation. For your case, you have to change the keyfields of the customizing table and at least the used search-helps and views to run with your concrete scenario.

Create the concrete customizing Table

The delivery and maintenance flags are: Customizing and changes are allowed.

Ok, no rocket sience. Look at the entry helps/check-Tabular:

I marked the check table for our variable - which goes to a view, which selects the avaiable variables (described later) and the search help for our classes.

First Step:  The check table of type ZBIU001_V_BVAR selects only valid entries of the BEx-Variable-Table RSZGLOBV. With this, I can ensure that only variables which are declared as customer-exit can be choosen.

The view is very simple: First select the variables from table RSZGLOBV and do a join with the corresponding text-table RSZELTTXT ( just for the user ;-) ).

Join:

View Fields:

Selections:

With this selection, you can ensure, that only customer-exit variables are chosen.

Next Step: Create a searchhelp, which delivers the correct class - and even this search-help looks after inheritence and abstract classes.

The function-module will be build in the way, classical search-help modules are developed.

FUNCTION zbiu001_sh_exit_classname. *"---------------------------------------------------------------------- *"*"Local Interface: *"  TABLES *"      SHLP_TAB TYPE  SHLP_DESCT *"      RECORD_TAB STRUCTURE  SEAHLPRES *"  CHANGING *"     REFERENCE(SHLP) TYPE  SHLP_DESCR *"     REFERENCE(CALLCONTROL) TYPE  DDSHF4CTRL *"----------------------------------------------------------------------  * EXIT immediately, if you do not want to handle this step   IF callcontrol-step <> 'SELONE' AND      callcontrol-step <> 'SELECT' AND      " AND SO ON      callcontrol-step <> 'DISP'.     EXIT.   ENDIF.    IF callcontrol-step = 'SELONE'. *   PERFORM SELONE .........     EXIT.   ENDIF.   IF callcontrol-step = 'PRESEL'.     EXIT.   ENDIF.  *"---------------------------------------------------------------------- * STEP SELECT    (Select values) *"----------------------------------------------------------------------   IF callcontrol-step = 'SELECT'.     FIELD-SYMBOLS:       <line>     TYPE string.     DATA:       lt_result  TYPE stringtab,       ls_result  TYPE seahlpres.     CLEAR: record_tab. * For this example: the code is here * For real-world scenario: export this coding to a utility-class * BTW: This is an example, how to write a recursive function using two stacks. *____________________________     FIELD-SYMBOLS:       <class>               TYPE string.     DATA:       lt_classes_stack      TYPE stringtab,       lt_subclasses         TYPE stringtab,       lc_abaptype           TYPE REF TO cl_abap_classdescr.     SELECT DISTINCT clsname FROM seometarel INTO TABLE lt_classes_stack      WHERE refclsname = 'ZIF_BIU001_VARIABLE'.  "<= Replace this in other cases with your interface!!!     WHILE lt_classes_stack IS NOT INITIAL.       LOOP AT lt_classes_stack ASSIGNING <class>. * Only those classes, which can be instantiated         lc_abaptype ?= cl_abap_classdescr=>describe_by_name( <class> ).         IF lc_abaptype IS BOUND AND lc_abaptype->is_instantiatable( ) = abap_true.           ls_result-string = <class>.           APPEND ls_result TO record_tab.         ENDIF.         SELECT DISTINCT clsname FROM seometarel APPENDING TABLE lt_subclasses          WHERE refclsname = <class>.       ENDLOOP.       lt_classes_stack = lt_subclasses.       CLEAR: lt_subclasses.     ENDWHILE. *____________________________     callcontrol-step = 'DISP'.     EXIT. "Don't process STEP DISP additionally in this call.   ENDIF.  ENDFUNCTION.

The most important thing is your selection-event. There you have to traverse the class-tree (build up within the table SEOMETAREL) and you will have to check wether a class is instantiatable via CL_ABAP_TYPEDESCR.

Create a "cool" maintenance view

After creating the customizing-table, you will need a view for the maintenance dialog. Why a view? Because the maintenance-views of the DDIC are very powerful and easy to enhance.

The maintenance-view will be build up over your customizing table and the table SEOCLASSTX. Why this? Because I want to have the texts of the class description during the maintenance, so the user/developer can immediatly see, which class he has selected - and he does not have to enter any descriptions.

Join-Definition

View-Fields. Regard: DESCRIPT has the flag "R" for read-only.

Now: Start you table maintenance generator:

Just apply your settings of authorization group and function-group.

The final maintenance view

Start the transacition SM30 and look at your new maintenance view:

Even with great search helps:

Conclusion

I hope, I could show, how easy it is, to build own customizing-dialogs for classes if you are using them in a dynamic-environment.

With this approach, you have the chance, to build applications, which are maintainable and easy to enhance. By using this kind of customizing you are even in the situation to ensure, that only those classes are used, which implements a concrete interface.

Another point: Do you have counted, how many lines of code are necessary to get this result? At least a small function module, which can easy encapsulated, so that it will work for many others too.