Source Code Inspector : Check objects according to creation date

[Former Member]

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

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.
3. DATA lo_test_ref TYPEREF TO cl_ci_tests .
5. * Check whether the object is created after mv_credat
6. IF me->is_new_object()NE abap_true .
7. EXIT.
8. ENDIF.
10.   me->modify_insp_chkvar(RECEIVING eo_test_list = lo_test_ref ).
12. * RUN_BEGIN
13.   lo_test_ref->run_begin(
14. EXPORTING
15.       p_no_aunit ='X'
16.       p_no_suppress ='X'
17.       p_oc_ignore ='X').
19. * RUN
20.   lo_test_ref->run( p_object_type = object_type
21.                     p_object_name = object_name
22.                     p_program_name = program_name ).
24. * RUN_END
25.   lo_test_ref->run_end().
27. ENDMETHOD.

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

1. METHOD modify_insp_chkvar.
3. * Returns test list for mv_checkvar(EXTENDED_VARIANT).
4. * Also this method combines BASIC_VARIANT and EXTENDED_VARIANT's test lists
5. * on INSPECTION. Just needed when check results double clicked.
6. * (I could not handle it with MESSAGE event of CL_CI_TEST_ROOT)
7.   DATA lo_check_var TYPE REF TO cl_ci_checkvariant .
8.   DATA lo_check_var_insp TYPE REF TO cl_ci_checkvariant .
9.   DATA lt_var_test_list TYPE sci_tstvar .
11.   FIELD-SYMBOLS : <l_var_entry> TYPE sci_tstval .
13.   CLEAR eo_test_list .
15. * Get reference for EXTENDED_VARIANT - additional checks for new objects
16.   cl_ci_checkvariant=>get_ref(
17.     EXPORTING
18.       p_user = ''
19.       p_name = mv_checkvar
20.     RECEIVING
21.       p_ref = lo_check_var
22.     EXCEPTIONS
23.       chkv_not_exists = 1
24.       missing_parameter = 2
25.       OTHERS = 3 ) .
26.   IF sy-subrc NE 0 .
27.     MESSAGE e001(z_sci_msg) WITH mv_checkvar description . "Check variant &1-&2 does not exist.
28.   ENDIF.
30.   IF lo_check_var->variant IS INITIAL .
31.     lo_check_var->get_info(
32.       EXCEPTIONS
33.         could_not_read_variant = 1
34.         OTHERS                = 2 ) .
35.     IF sy-subrc NE 0 .
36.       EXIT .
37.     ENDIF.
38.   ENDIF.
40. * Get test list of EXTENDED_VARIANT - addional checks for new objects
41.   cl_ci_tests=>get_list(
42.     EXPORTING
43.       p_variant      = lo_check_var->variant
44.     RECEIVING
45.       p_result        = eo_test_list
46.     EXCEPTIONS
47.       invalid_version = 1
48.       OTHERS          = 2 ) .
50.   IF sy-subrc NE 0.
51.     EXIT .
52.   ENDIF.
54. *...
56. 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.
7.     p_result->inspection= p_inspection .
9. LOOP AT p_result->listINTO l_ref_test .
11.       l_ref_test->if_ci_test~inspection = p_inspection .
13. ENDLOOP.
15. ENDIF.
17. ENDENHANCEMENT.
18. *$*$-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. *....