Title
Transfer of unmaintained check indicators from other systems

Purpose
This report improves the quality of SU22 check indicators andauthorization defaults. It is not delivered to customers.

Integration
The report collects SU22 trace data in the consolidation system on whichSU22 ToDo is running, and from connected development and test systems.The report can also bring the collected trace data back to developmentsystems. The goal of this data collection is to improve the quality ofthe check indicators and the authorization default values.

Caution:
The report only now works in systems with Basis releases >= 6.40. It canalso only fetch data from connected systems if these have a Basisrelease >= 6.40.

Background:
Developers are responsible for maintaining the check indicators andauthorization default values for their own transactions. As it is,however, practically impossible to obtain an overview of whichauthorization objects are checked during a transaction, theauthorization checks performed in the internal development, test andconsolidation systems are logged by the kernel (Kernel trace). Thebetter a transaction is tested, the better the trace data is too.
The following problem now occurs: Developers are informed by SU22 ToDowhich check indicators and authorization default values must still bemaintained. In doing this, the ToDo is based on the SU22 trace data.However, as the ToDo usually runs in a consolidation system, in which,from experience, transactions are tested too litte in order to produceusable trace data, the check indicators and authorization default valuesthat SAP delivers are also incomplete.
In order to deal with this problem, the report GETSU22TRACEDATA shouldperiodically be run. It fetches SU22 trace data using RFC from one ormore other systems into the ToDo System (see below, Step 1), and thenalso replicates this data back to the original system (see below, Step2). Step 2 is necessary because the SU22 check indicators andauthorization default values can only be maintained in a transaction'soriginal system.

Implementation:
Collect the SU22 trace data in the ToDo system:
Set up RFC connections from the ToDo system to every connected test anddevelopment system.
Create a variant of the report GETSU22TRACEDATA. This should be startedwith all of the RFC connections created in step a). Now choose the readdirection "Dev./Test syst.->ToDo Syst.", the mode "Write Entries Back"and an output level of your choice (recommended: "Only DisplayErrors/Statistics"). Save the variant.
Schedule the variant as a periodic background job. It is sensible to runthe variant once a day.
In order to clean up the trace data collected in this way, you shouldstart the report RSSU22REPAIR.as the second stepof the background job. As this report can run for a long time (dependingon the number of transactions in the system, up to an hour), it makessense to schedule it, to run at night, for example.
Transfer back of the collected trace data from the ToDo systemto the development systems:
Set up an RFC connection from the development system to the ToDo system.
Create a variant of the report GETSU22TRACEDATA. Start it with the RFCconnection created in step a). Next choose the read direction "ToDoSyst.->Original syst.", the mode "Write Entries Back" and an outputlevel of your choice (recommended: "Only display Errors/Statistics").Save the variant. As you have chosen the read direction "ToDo Syst.->Original Syst." only trace data that belongs to transactions that havethe property of originality in that development system are replicated tothe development system.
Schedule the variant as a background job. It is sensible to schedule thevariant once a day. If possible, the trace data should be copied backshortly after the trace data has been collected and cleaned up in theToDo system (see 1c+d). Example: The data collection in Step 1 takesplace in the ToDo system during the night at 1 a.m. In this case, youcould schedule replication into the development system for 5 a.m.
In order to clean up the tracedata collected in this way again, youshould start the report RSSU22REPAIR as the
second step of the background job. As this report can run for a long
time (depending on the number of transactions in the system, up to anhour, it makes sense to schedule it at night, for example.

Features