Use this report GETSU22TRACEDATA to improve the quality of the SU22 authorization default status and the SU22 authorization default values.
Integration
The report collects SU22 authorization trace data from the connected development and test systems in the consolidation system on which the SU22 ATC check runs. It can also return the collected trace data to the development systems. The aim of this data collection is to improve the quality of the authorization default data.
Caution:
The report only now works in systems with SAP NetWeaver releases >= 6.40. It can also only fetch data from connected systems if these have a SAP NetWeaver release >= 6.40.
Background:
Developers are responsible for maintaining the authorization default data of their applications. However, since it is practically impossible to obtain an overview of which authorization objects are checked during an application, the authorization checks performed in internal development, test, and consolidation systems are logged by the kernel (kernel trace). The better an application is tested, the better its trace data.
However, the following problem then occurs: the SU22 ATC check informs developers which authorization default data they still need to maintain. The ATC check is based on the SU22 trace data. However, the ATC check usually runs in a consolidation system, in which experience suggests applications are tested too little to generate usable trace data. This would mean that the authorization default data delivered by SAP was incomplete.
To deal with this problem, start report GETSU22TRACEDATA periodically. It collects SU22 trace data in the system in which the ATC check runs (see below, step 1) by RFC from one or more other systems and then replicates this data back to the original system of an application (see below, step 2). Step 2 is necessary because the SU22 authorization default data can only be maintained in the original system of an application.
Use:
Collect the SU22 trace data in the ATC system:
a) Set up the RFC connections from the ATC system to every connected test and development system. You do not need to set up RFC destinations for test systems that are clients of the ATC system.
b) Create a variant of the report GETSU22TRACEDATA. Start this with all of the RFC connections created in step a). Choose the read direction “Dev./Test System -> ATC Sys.”, the mode “Write Entries Back”, and an output level of your choosing (we recommend “Display Only Errors/Statistics”). Save the variant.
c) Schedule the variant as a periodic background job. It is useful to start this variant once a day.
d) To clean up the collected trace data, start report RSSU22REPAIR as step 2 of the background job. Since this report can have a very long runtime (depending on the number of applications in the system, up to an hour), it makes sense to schedule it at night.
Transfer the collected trace data back from the ATC system to the development systems:
a) Set up an RFC connection from the development system to the associated ATC system.
b) Create a variant of the report GETSU22TRACEDATA. Start it with the RFC connection created in step a). Choose the read direction “ATC System -> Original System”, the mode “Write Entries Back”, and an output level of your choosing (we recommend “Display Only Errors/Statistics”). Save the variant. Since you have chosen the read direction “ATC System -> Original System”, only trace data that belongs to applications that originate in a development system is replicated to this development system.
c) Schedule the variant as a periodic background job. It is useful to start this variant once a day. If possible, schedule the copying back of the trace data shortly after the collecting and cleaning up of the trace data in the ATC system (see 1c and 1d). For example: the data collection from step 1 takes place in the ATC system at 01:00. In this case, you could schedule the replication to the development system for 05:00.
d) To clean up the collected trace data again, start report RSSU22REPAIR as step 2 of the background job. Since this report can have a very long runtime (depending on the number of applications in the system, up to an hour), it makes sense to schedule it at night.
