
In SAP note 1230076 "Generation of ABAP loads: Tips for the analysis", a tool report RSDEPEND is introduced.
It is explained in the note "An ABAP program generally depends on many other repository objects. If an object like this changes (for example, an include or a DDIC type), the load of all dependent programs must be invalidated. The load of these programs is then regenerated with the next use, and valid loads are generated again."
In order to demonstrate the ABAP load invalidation logic, I create a very simple database table ZCRMM_CCTV_CHAL and write a simple report ZTESTLOAD to fetch all its data:
data: lt_table type STANDARD TABLE OF ZCRMM_CCTV_CHAL.
select * INTO TABLE lt_table FROM ZCRMM_CCTV_CHAL.
Execute report RSDEPEND with ZTESTLOAD as program name = ZTESTLOAD.
it returns the result as below. In the first part we see the timestamp of ABAP load and ABAP source are both initial one when I activate the report.
In the second part we see our simple report has many dependencies on system includes like <REPINI> and <SYSINI>.
Those system includes are automatically inserted into the test program I have created, it is not necessary for application developers to manually include them, or else there would be compilation errors:
In the third part "Dependencies of Dictionary Types", we found the depended database table which was initially created on 10.21 in year 2013.
Re-run RSDEPEND report:
The execution result of RSDEPEND report:
The execution result of RSDEPEND report:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
11 | |
9 | |
5 | |
5 | |
4 | |
4 | |
4 | |
3 | |
3 | |
2 |