Skip to Content

Summary

This blog is about changing the way of work of Source Code Inspector(tcode:SCI) especially when Transport Organizer integration is activated. Transport Organizer integration can be activated using tcode SE03. Thanks to SAP for this talented and flexible tool.

Problem

In one of our projects we needed to seperate SCI controls according to creation date of objects. We needed this because afore mentioned project is started 12 years ago and as you guess quality and security standarts are changed over time. At sometime integration of SCI/ATC and Tranport  Organizer(SE01) is activated. So developers can not release a request before handling errors given by SCI. But how can you force developer who made just single line of change to a huge program? How can he/she handle all errors given after checks without knowing semantics of this huge program? What if this change should be transported to production system immediately? The solution was to seperate check variants according to creation date of objects .

Also periodic checks can be planned to adduct old objects to new standarts.

In this blog i will try to explain what I did to workaround this issue. To benefit from the solution you should be familiar with adding your own test class to SCI.

You can find information about adding your own test class to SCI at : http://scn.sap.com/community/abap/blog/2006/11/02/code-inspector–how-to-create-a-new-check and http://wiki.scn.sap.com/wiki/download/attachments/3669/CI_NEW_CHECK.pdf?original_fqdn=wiki.sdn.sap.com

Solution summary

First, I created a test class ZCL_SCI_TEST_BYDATE (derived from CL_CI_TEST_ROOT) that has just 2 parameters date (mv_credat) and check variant(mv_checkvar). This class decides if tests in mv_checkvar is required for the object under test by checking creation date . If object is ‘new’ it runs additional tests.

Secondly, I created two SCI check variants : BASIC_VARIANT and EXTENDED_VARIANT. The first one is for old development objects and second one is for additional tests for ‘new’ objects. ‘new’ means that object is created after certain date(ZCL_SCI_TEST_BYDATE->mv_credat). First check variant includes my custom test which is mentioned above (ZCL_SCI_TEST_BYDATE) and EXTENDED_VARIANT is given as mv_checkvar parameter. Also second check variant is complementary for the first one and includes different tests than the first one.

Finally, to enable navigation by double clicking at check results I had to make one simple repair and 2 enhancements.

Step 1 : ZCL_ SCI_TEST_BYDATE class :


Most important method of this class is -normally- run() .

run method checks if object is created after date mv_checkvar, gets test list for EXTENDED_VARIANT and starts new test procedure for new test list.

  1. METHOD run.
  2. DATA lo_test_ref TYPEREF TO cl_ci_tests .
  3. * Check whether the object is created after mv_credat
  4. IF me->is_new_object()NE abap_true .
  5. EXIT.
  6. ENDIF.
  7.   me->modify_insp_chkvar(RECEIVING eo_test_list = lo_test_ref ).
  8. * RUN_BEGIN
  9.   lo_test_ref->run_begin(
  10. EXPORTING
  11.       p_no_aunit =‘X’
  12.       p_no_suppress =‘X’
  13.       p_oc_ignore =‘X’).
  14. * RUN
  15.   lo_test_ref->run( p_object_type = object_type
  16.                     p_object_name = object_name
  17.                     p_program_name = program_name ).
  18. * RUN_END
  19.   lo_test_ref->run_end().
  20. ENDMETHOD.

Another important method is modify_insp_chkvar which returns test list for EXTENDED_VARIANT.

  1. METHOD modify_insp_chkvar.
  2. * Returns test list for mv_checkvar(EXTENDED_VARIANT).
  3. * Also this method combines BASIC_VARIANT and EXTENDED_VARIANT’s test lists
  4. * on INSPECTION. Just needed when check results double clicked.
  5. * (I could not handle it with MESSAGE event of CL_CI_TEST_ROOT)
  6.   DATA lo_check_var TYPE REF TO cl_ci_checkvariant .
  7.   DATA lo_check_var_insp TYPE REF TO cl_ci_checkvariant .
  8.   DATA lt_var_test_list TYPE sci_tstvar .
  9.   FIELD-SYMBOLS : <l_var_entry> TYPE sci_tstval .
  10.   CLEAR eo_test_list .
  11. * Get reference for EXTENDED_VARIANT – additional checks for new objects
  12.   cl_ci_checkvariant=>get_ref(
  13.     EXPORTING
  14.       p_user =
  15.       p_name = mv_checkvar
  16.     RECEIVING
  17.       p_ref = lo_check_var
  18.     EXCEPTIONS
  19.       chkv_not_exists = 1
  20.       missing_parameter = 2
  21.       OTHERS = 3 ) .
  22.   IF sysubrc NE 0 .
  23.     MESSAGE e001(z_sci_msg) WITH mv_checkvar description . “Check variant &1-&2 does not exist.
  24.   ENDIF.
  25.   IF lo_check_var->variant IS INITIAL .
  26.     lo_check_var->get_info(
  27.       EXCEPTIONS
  28.         could_not_read_variant = 1
  29.         OTHERS                = 2 ) .
  30.     IF sysubrc NE 0 .
  31.       EXIT .
  32.     ENDIF.
  33.   ENDIF.
  34. * Get test list of EXTENDED_VARIANT – addional checks for new objects
  35.   cl_ci_tests=>get_list(
  36.     EXPORTING
  37.       p_variant      = lo_check_var->variant
  38.     RECEIVING
  39.       p_result        = eo_test_list
  40.     EXCEPTIONS
  41.       invalid_version = 1
  42.       OTHERS          = 2 ) .
  43.   IF sysubrc NE 0.
  44.     EXIT .
  45.   ENDIF.
  46. *…
  47. ENDMETHOD.

Important points about my custom class definition is ok now. I attached full source code.

If you want to add parameters to your custom test classes look at query_attributes, get_attributes, put_attributes methods of ZCL_SCI_TEST_BYDATE.

To add new test class to SCI test list I opened SCI->Management of tests and chose my new test class and clicked save button.

 

Step 2 : Check variants

As I mentioned before I created 2 checkvariants. Below is BASIC_VARIANT which is valid for all programs.Selected test list in figures below is just an example. Notice that my new test ‘Additional tests for new programs’ is selected. Parameters of new test can be seen in this picture.

Next picture depicts second checkvariant which is valid for objects created after ’01.01.2014’ (mv_date).

PS: SE01 uses SCI checkvariant TRANSPORT as default. But there is a way to change this – thanks to SCI : I changed default checkvariant with my BASIC_VARIANT. To achieve this I changed the SCICHKV_ALTER table’s record which has ‘TRANSPORT’ at CHECKVNAME_DEF field.

Note that AFAIK DEFAULT checkvariant is used by SE80, so it is modifiable too .


Step 3 : Adding check results of custom test class to SCI.

-This step is not related to the main idea, first 2 steps are sufficient to express my idea-

After creation of new test class and checkvariants I had been able to run additional checks for new objects but SCI result list was not navigating to EXTENDED_VARIANT’s test results when I double clicked. As I guess SCI is just aware of BASIC_VARIANT’s test list and can not navigate to unknown test’s results. I should add my additional tests to inspection object’s test list.

I made a single line of repair(CL_CI_INSPECTION->EXECUTE_DIRECT) and enhancement to CL_CI_TESTS->GET_LIST. The aim of these modifications is to fill the ‘inspection’ property of ZCL_SCI_TEST_BYDATE .( ZCL_SCI_TEST_BYDATE has a property named inspection inheriting from CL_CI_TEST_ROOT but it is empty when tests are running. I don’t know if it’s a bug or not ).

PS: CL_CI_TEST_ROOT class has method ‘inform’ and event Message. But I could not be able to pass  my additional check results to SCI result list . I will work on this and if its ok step3 will be useless.

CL_CI_TESTS->GET_LIST enhancement

  1. “””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””$”$\SE:(1) Class CL_CI_TESTS, Method GET_LIST, End                                                                                                          A
  2. *$*$-Start: (1)———————————————————————————$*$*
  3. ENHANCEMENT1  Z_SCI_ENH_IMP2.“active version
  4. *
  5. IF p_inspection ISNOTINITIAL.
  6.     p_result->inspection= p_inspection .
  7. LOOP AT p_result->listINTO l_ref_test .
  8.       l_ref_test->if_ci_test~inspection = p_inspection .
  9. ENDLOOP.
  10. ENDIF.
  11. ENDENHANCEMENT.
  12. *$*$-End:  (1)———————————————————————————$*$*

CL_CI_INSPECTION->execute_direct , repair
  1. *…
  2. call method CL_CI_TESTS=>GET_LIST
  3. exporting
  4.       P_VARIANT      = CHKV->VARIANT
  5.       p_inspection = me “added line
  6. receiving
  7.       P_RESULT        = L_TEST_REF
  8. exceptions
  9.       INVALID_VERSION =1
  10. others=2.
  11. *….
To report this post you need to login first.

6 Comments

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

    1. Tunahan Unal Post author

      Hi Annasaheb,

      Currently it is not possible to check delta code with SCI.

      It would be hard to accomplish this idea because delta code is not always syntactically ‘complete’.

      My method just separates program objects according to their creation date.

      Best regards.

      (0) 
  1. Victor Dalchiele

    Hi Tunahan,

    I did what you posted and some things more but I have a problem:

    When i run the “extended_variant” (called from the “basic_variant”) with this check’s box on:


    1) CL_CI_TEST_FOR_ALL_ENTR_HANA        Search SELECT .. FOR ALL ENTRIES-clauses to be transformed

    2) CL_CI_TEST_ANALYZE_SELECT_HANA      Search problematic SELECT * statements

    Check boxes 1 & 2:

    Capture.PNG

    Note that two checks are HANA.

    The run dump with Nº mensaje: SATC_ABAP_CHECK410 and the are no results 🙁 .

    2.PNG

    Additional note: If I run only one variant with this check box runs OK, but I need the fisrt variant (basic_variant) who filter the old objects.

    I’m trying to solve this problem if someone knows the solution I would appreciate.

    (0) 

Leave a Reply