The motivation behind this blog came after a visit to SAP Labs Latin America in Sao Leopoldo – Brazil. We had contact with the SAP expert Heinz Ludwig who introduced us to the Abap Test Cockpit. When asked if SAP was already using the ATC was funny his reaction…
We did not have all the prerequisites to install the ATC (EHP6 and SP3 ABAP), we intend to update the landscape in a near future. But we had the idea to create a similar routine to static code verification. We add to this the requests automatic release when nothing was found, in case of false positive occurred, the request for exemption occurs via email.
This solution is running in our environment about three months and during this period we noticed an improvement in code quality and especially the maturity of team programmers.
ATC is a wonderful tool for quality assurance and automatic verification, merging applications like extended check, code inspector and exemption authorization by workflow.
If your landscape supports ATC, you will not have problems to start using it.
Just take a look on some good blogs:
But if your company still waiting to upgrade to compatible version, do not wait anymore. Automatic quality assurance not is the future – but the present. You can start it with some abap code and little work. The hard work is change the process – and the people’s mind!
Be careful: code quality without testing is a bad code!
Create a BADI for CTS_REQUEST_CHECK.
Create a implementation class. Activate the BADI created.
Configure code inspector variant: transaction code SCI. It is possible to create new checks too. And the best news: their struggle now will be used later when the landscape is compatible with ATC!
Code the method CHECK_BEFORE_RELEASE in the class that was created in the step 2.
How it works: It is informed that the request to be evaluated; its objects must be extracted (programs, classes, functions and others) and the source code of each object as well, using the standard function SVRS_GET_REPS_FROM_OBJECT.
To find the difference between the current version and the previous SVRS_COMPUTE_DELTA_REPS function can also be used.
With the source code extracted, just perform the validations and present the check points founded.
The focus is not present the code itself, but to show how simple it is, the following how to call the extended check and code inspector.
Many possibilities and ideas were emerging, as do the checking only the modified version, or the entire program when it is something more critical.
You can call code inspector like it was called in this thread:
Or you can do only extended check, if you want to do a “soft check”.
wa_flags-x_dat = ‘X’.
wa_flags–x_per = ‘X’.
wa_flags–x_txt = ‘X’.
wa_flags–x_bre = ‘X’.
… “other extended check validations if you want, just use wa_flags strucutre.
LOOP AT me->t_request_obj ASSIGNING <fs_obj>.
o_checker = cl_slin_driver=>get_checker_group( wa_flags ).
v_prog = <fs_obj>–obj_name.
o_ref = cl_slin_driver=>io_result( progname = v_prog
ignore_pseudo_comments = v_comment_flag
call_cntx = v_call_cntx
checker = o_checker
cache_use = v_cache_use ).
o_ref->old_get_result_tables( IMPORTING result = t_result result_stat = t_result_stat ).
This same logic is also performed in a transaction report and in the SE09/SE10 release button. We created authorization objects to secure that only approvers can release requests with points to check with inserting of a justificative.
SE09/SE10 screen asking an exemption on release
The transaction report: “points to do better”
That is all folks!