Buried in the deepest layers of your Web Application Server and thought – and hoped! – forgotten by mankind lie unspeakable terrors.
Eons ago, they roamed the Earth as gods, but now they sleep and dream. These are the Old Ones, of whom the crazy Arab Abdul Al’Hazred wrote:
- That is not dead, which may eternal lie
- Yet with strange eons, even Death may die.
I have been a scholar for most of my life, and my musings have led me to research many dark secrets of SAP technologies. But now – with my latest studies of the Necronomicon, the legendary black book written by said crazy Arab – I must have stirred something. Whatever has brought me to the attention of the Old Ones, they are onto me, and soon my days will be over.
But before they find me, I want to pass onto you the secrets at which I have had the briefest glimps, just quick enough to keep most of my sanity yet long enough to loose all hope and faith in the Universe being a place for humankind.
Global Interfaces of Function Modules
Did you ever wonder about the flag if you look at the Attributes-tabstrip of a function module in the function builder of the ABAP workbench? Or did you ever wonder about a comment “Global interface” of a function module:
FUNCTION Z_TST. *"---------------------------------------------------------------------- *"*"Global interface: *"----------------------------------------------------------------------
If you check the longtext you will get following explanation:
“Global interface ID
If you select this field, the system declares the interface parameters in the function group globally. This means that, within the function group, you can access the function parameters in subroutines, as well as PBO and PAI modules. Unlike other global data, the contents of the global parameters of a function module are known only from the time of the call until you leave the module.
You must ensure that no other global field exists with the same name. If several function modules within a function group possess global interfaces, you must define parameters with the same name identically.”
Let me summarize: We can create function modules whose parameters are global variables that are accessible within the whole function group!
This technique was applied to develop generic ALV display module that can display internal tables of TYPE ANY TABLE. The reason is that we have to access this internal table in different includes of the function group – for instance in PBO/PAI, in local classes and so on. If you want to know how this works just look at the parameter t_outtab of the function module REUSE_ALV_GRID_DISPLAY.
Summoning Global Interfaces
Luckily summoning the ‘Old Ones’ is difficult: Usually you can’t activate the Global-flag of the function builder. But I’m quite sure that everybody who wants to create a global interface will soon know to do it without changing transparent tables or usage automatic generation of function modules.
To create a function module search one with global interface within the transparent table ENLFDIR (perhaps REUSE_ALV_GRID_DISPLAY) and copy this function module within your function group. But it is common sense that summoning the evil is really a bad idea…
Why Global Interfaces are a Bad
I’m sure any experienced developer will find the idea of global interfaces awkward. One reason may be that there is no other common programming language having that feature. Of course intuition can be misleading but here it is not.
The first reason is that it is difficult to add function modules to function groups that contain a function module with a global interface. You will earn syntax errors that will lead you maybe in wrong directions.
The second reason is that global interfaces lead to bad programming style: Either every parameter in your function module is global or every parameter is local. As a consequence the number of global variables increases even it is not necessary.
The third reason is that this approach is not flexible. Just consider the case that you encapsulated a SAP control into a function group to perform generic display operations. If you implement this control as a amodal dynpro you will have problems to change the content that is displayed. If it would be possible to store the content to display in a global variable within the top-include we can easily change it by adding another function module that changes this global content and triggers a refresh operation. But even if we have a CHANGING or TABLES parameter bound to a global parameter of a function module it is dangerous to change it because it would affect the calling function.
In fact it would be interesting to discuss the last aspect in detail but I don’t want to do it. Even if we would be able to find a working solution it would too hard to understand and I’m convinced that we should avoid all unnecessary problems even if we could master them. The reason is simple: Perhaps a collegue who has to maintain our programs doesn’t know the ancient technique of global interfaces. Another reason is that global interfaces are a unnecessary special case and I’m sure everyone who is new in ABAP programming will find a better solution.
How to Avoid Global Interfaces
If we write a GUI program using dynpros either as report of function group we have to use global variables and it is a best practice to store them in a top-include. Everybody will first look at the top-include to search for global variables or constants. So why should we do something else?
The simplest solution is to assign the parameter to a global field symbol:
\ IF t_outtab IS SUPPLIED. \ ASSIGN t_outtab to <g_sel_items>. \ ELSE. \ UNASSIGN <g_sel_items>. \ ENDIF. \
Now I present a solution avoiding global interfaces by using ABAP Objects. Just create a new empty internal table to which the content of t_outtab will be copied afterwards:
\ CREATE DATA lr_table LIKE t_outtab. \
Then we can assign the reference to a field symbol that is defined in the top-include of the function group:
\ ASSIGN lt_table->* TO <g_sel_items>. \
Now you can copy the content and use the field symbol to access the generic table.
In this weblog you learned
- an obolete but still used ABAP programming technique and
- a method to avoid this technique.