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 😉 ).
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.
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.
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:
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.