The example below are based on my need to hold and transfer two fields from LIKP. It is easy to expand to hold other table structures or single fields.
The datastore could be used to replace the usage of MEMORY ID, which are not very readable / maintanable.
A (very) short introduction for those who are not familiar with the singleton design pattern. The singleton design pattern ensures that only one instance of the class is created. The class contains its own constructor, and in this method logic is placed that ensures the creation of only one instance.
And now for the fun part. I have documented the code(!), so it should be readable with just screenshots.
The class for the data store:
And the O_DATA_STORE attribute:
The constructor for the class is the GET_OBJECT method.
And two simple PUT and GET methods for the LIKP structure:
Use of class
The following is the test program that shows the datastore in use.
First the main program:
The next level in the call stack:
And the last level of the call stack:
At this point the LIKP-VBELN contains the number 2. This show that our data store object are kept in memory the whole way through the call stack.
Please note that if you leave the call stack (i.e. start another report), then you will loose the reference to the object.
With this datastore class you can now avoid using MEMORY ID to store and move variables trough the call stack.
After the initial build of the class I have enhanced it further, and changed the GET-methods with a return parameter to evaluate if the field has been stored.
I also added a RESET-method. This method marks the field as unstored.
This has the advantage of being able to check if the field have been initiated. And also to reset the field after it have been retrieved/used.
METHOD put_berot. v_berot = i_berot. v_berot_initiated = abap_true. ENDMETHOD.
METHOD reset_berot. v_berot = ''. v_berot_initiated = abap_false. ENDMETHOD.
METHOD get_berot. e_berot = v_berot. r_berot_initiated = v_berot_initiated. ENDMETHOD.