The motivation behind thisblogcame aftera visit toSAPLabsLatin America in SaoLeopoldo-Brazil. We hadcontact with the SAP expertHeinzLudwigwhointroduced us to theAbapTestCockpit. When askedifSAPwas alreadyusing theATCwasfunnyhis reaction...
We did not have alltheprerequisitesto install theATC (EHP6 and SP3 ABAP), we intend toupdate thelandscapein anear future. But we hadthe idea to createa similar routinetostaticcode verification. We addto this therequests automatic releasewhen nothingwasfound, in case of false positiveoccurred, the request forexemptionoccursvia 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:
http://scn.sap.com/docs/DOC-32628
http://scn.sap.com/docs/DOC-32172
http://scn.sap.com/docs/DOC-31773
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:codequalitywithouttestingis abad code!
1st step.
Create a BADI for CTS_REQUEST_CHECK.
2nd step.
Create a implementation class. Activate the BADI created.
3rd step.
Configure code inspector variant: transaction code SCI. It is possible to create new checks too. And the bestnews: their struggle nowwill be usedlaterwhen thelandscapeiscompatible withATC!
http://wiki.sdn.sap.com/wiki/display/Snippets/Code+Inspector+Check
http://scn.sap.com/community/abap/blog/2006/11/02/code-inspector--how-to-create-a-new-check
4th step.
Code the method CHECK_BEFORE_RELEASE in the class that was created in the step 2.
How it works: It isinformedthattherequestto be evaluated; its objectsmust beextracted(programs, classes, functions and others) and the source codeof each objectas well,using thestandard functionSVRS_GET_REPS_FROM_OBJECT.
Tofind the differencebetween the current versionand thepreviousSVRS_COMPUTE_DELTA_REPSfunctioncan alsobe used.
With thesource codeextracted, just perform thevalidationsand present thecheckpoints founded.
The focusis notpresentthe codeitself, but to showhow simple it is, the following how to calltheextended checkandcodeinspector.
Manypossibilities andideaswere emerging, asdo the checkingonlythemodified version, ortheentire programwhen it issomething morecritical.
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".
{code}
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 ).
...
ENDLOOP.
{code}
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!