ABAP Test Cockpit table(s) with large volume of data

[Former Member]

Hello,

We have implemented ABAP Test Cockpit in our complex landscape. We have a large custom code base because of which the Mass quality check run in the Master system generates a huge list of ATC findings. Most of these findings are related to the Legacy code (older than 2013) and resolving them cannot happen along with the current and planned project developments, change requests etc. The plan is to resolve these ATC findings gradually.

For this interim period, the periodic Mass quality check run generates the same set of findings for the custom code base and stores it for future reference. This causes redundancy in data only with a new 'Display Id' and the volumes of data is increasing significantly.

Moreover in the ATC satellite systems, with each execution of ATC on an ABAP object the findings are stored redundantly in the tables again with a new display id. So the data volumes keeps increasing with every project, incident fix, change request etc.

One table which can be a bottleneck in terms of performance and storage is 'SATC_AC_RESULTVT'. Is there any way that data within this table can be purged or preferably archived? I can take the route of a custom program to do the job but I would like the to know if there is a standard way?

I would request ATC solution experts to suggest ideas/best practices etc.

Thanks,

Jigar V

[former_member183804]

Hello Jigar,

the table SATC_AC_RESULTVT contains one record per finding per result. At present the data model does not allow to share the details of a finding among several results. It is planned for a future release to improve the data model to share a finding amongst several results. But for shipped releases storing findings per result is a matter of facts.

At present findings contain weak references into the code repository. For example the details of a finding contain the include name and the line number. As soon the referred code gets change this weak reference is broken. Therefore the records stored in SATC_AC_RESULTVT are NO candidates for long term archiving. Consequently ATC offers no archiving but a garbage collection feature.

Each result and thus the referred findings have a validity date. In the result viewer one can use the menu "ATC Result\Display Header Information" to access the validity date of particular result. As soon as the validity date has been exceed the result can be purged by garbage collection. There are implicit triggers for garbage collection like: result transfer/ replication or display of findings. And there is also an explicit garbage collection report SATC_AC_CLEANUP that can be scheduled. In most cases the implicit trigger are sufficient and there is no need schedule this report. Besides the garbage collection by validity date it is also possible to delete results in transaction ATC / topic “Result Management”. Please note it shall also possible to execute such an explicit deletion in batch.

The lifespan of mass runs scheduled in transaction ATC can be configured. The default 120 days possibly is too high, to fit to the context of system sizing and check run frequency. In any case reducing the lifespan will also reduce the resource need in terms of database space. Just reducing the lifespan will however not impact already existing results. But these results can be purged in transaction ATC / Result Management as mentioned already.

In case you are looking for a long term persistency for e.g. reporting use cases the ATC result repository is not suitable. For data mining and reporting use case the Custom Code tooling in the Solution Manager offers according features.

Hope this helps

Klaus