I have always been annoyed by the fact that it is impossible to exclude standard SAP code from the Code Inspector (SCI) results. In my current job (quality manager of all custom code in a 149 SAP systems landscape) it is an absolute necessity to have a code check tool I can trust to deliver only the messages I am interested in. Without the possibility to exclude standard SAP messages, it is a great tool for checking single objects, but all but useless when checking large projects or entire systems.
I have been toying with the idea of checking whether I could tweak the SCI to do my bidding, but Ian Stubbings’ blog on SCI object collectors put me on the right track finally and made me drag my lazy body off the coach and do something! To build this yourself, you first need to build a custom object collector as described in Ian’s blog. I added only one selection parameter (TP_NOSAPINCL, type CHAR1):
Then we need to make three enhancements: two to put the object collector’s new selection field into class memory and one to read that class memory and use it to exclude these irritating messages on standard SAP code. We need two enhancements to set the class memory: one for direct processing and one for parallel/background processing.
First we will build the direct processing enhancements. SAP stores the settings of the object collector in a data cluster. After retrieval of the key to the object collector in class CL_CI_OBJECTSET we create an implicit enhancement at the end of the method to put the information to the class memory.
We use this information in method HANDLE_MESSAGE of CL_CI_TESTS. Here we get the actual value of parameter TP_NOSAPINCL (also in a cluster database) that we specified in our newly created object collector. If this is set to ‘X’, we check whether the current message is for an object that is assigned to a standard SAP package. If so, we leave the method and the message will not be recorded.
The SKIP_MESSAGE method is a bit longer. I have added the code separate from the signature:
And here are the class’ attributes:
This works well when running in the foreground, but when running this in parallel or background, a function is called in a different memory session. Therefore the class memory is lost and needs to be populated in a different spot within the function module call. This time we need to read the object collection key from the cluster database ourselves (see above, method SET_CHECKSET_PARALLEL).
That’s it! This works as long as the Code Inspector can only run one inspection at a time and only one object set can be assigned to an inspection. This also takes care of removing messages from the maintenance view. In fact, it is better than the standard option to exclude maintenance view messages: that option excludes the entire function group, while it might contain custom functions as well, next to the maintenance screens!
I used a function group that has both maintenance views and function modules. Here is the result without the new option:
And here are the results with the new option. These are the messages that are valid for my work:
I am greatly interested in comments, suggestions and improvements! As this is my first blog, please be gentle 🙂 .