Skip to Content

Automatic QA and release request – part 02


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:

http://scn.sap.com/docs/DOC-32628

http://scn.sap.com/docs/DOC-32172

http://scn.sap.com/docs/DOC-31773

http://scn.sap.com/community/abap/testing-and-troubleshooting/blog/2012/12/03/teched-2012-the-brand-new-abap-test-cockpit-a-new-level-of-abap-quality-assurance

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!

1st step.

Create a BADI for CTS_REQUEST_CHECK.

SE19 - CTS_REQUEST_CHECK.jpg

2nd step.

Create a implementation class. Activate the BADI created.

Implementation class.jpg

3rd step.

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!

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

SCI variant.jpg

4th step.

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”.

{code}

  wa_flags-x_dat = ‘X’.
  wa_flagsx_per = ‘X’.
  wa_flagsx_txt = ‘X’.
  wa_flagsx_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

Critical errors.jpg

The transaction report: “points to do better”

Z_ATC.jpg

Errors_result.jpg

That is all folks!

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Jackson Donadel

    Hi Rodrigo nice blog, but I want to start a discussion with this.

     

    Considering a company where developers are not trustworthy, just supposedly, there is a way to block bypassing this checks?

    Something like block debugging this code.

    Something like the program SAPMSYST.

    Thanks

    (0) 
    1. Rodrigo Paisante Post author

      Hi Jackson,

      this is a good question.

      With new debugger, everything is possible… but I suggest you to create  a Z table with modification log to save date/time, request and user who release the request. If this validation flows ok, this table will have the log record. You can retrieve standard table E070 request status. If the request has released status in E070 but no record in your Z table, here is your pirate!

      Best Regards.

      (0) 
      1. Fabio Pagoti

        It’s not very hard to change data from those tables but I agree that a log on a Z table would deal with the worst scenarios. But the idea is really cool so I can not imagine someone trying to avoid this workflow.

        Congratulations for the idea and post Rodrigo.

        (0) 

Leave a Reply