Code Inspector - Custom Object Collectors

[IanStubbings]

I have christopher.solomonto largely thank for this blog. You may wonder why since it has nothing to do with HCM P&F at all, in which Chris is an undisputed expert, but it was simply because I'd noticed that he had released a whole plethora of blogs recently via a tweet by jarret.pazahanick. Chris had also mentioned me in one of them - HCM Processes & Forms: Adobe or WDA? Why not Adobe AND WDA!?!?! to be precise. 'Nice' I thought. 'Very good of him.  Shame I wrote that blog well over 2 years ago though. I'd better get active again on SCN!'

So here we go...here's a recent issue that has played directly into blog territory.

The Problem

Code Inspector has many great features and rich selection options to enable us to build up our object set that we wish to inspect. Even allowing us to upload our own list of objects or retrieve a list from runtime analysis etc.with the more advanced Object Collectors tab. Pretty powerful stuff.

BUT.. one thing appears to be missing from all object set collectors  - a date range.

Maybe this is on purpose but we certainly have a requirement, probably not too dissimilar to some of you, in that we would like to periodically inspect code but only pick up the latest ‘release’ i.e. a country rollout or wider programme of work.  Mostly this could - and arguably should be - facilitated by the correct use of packages. I refer to tobias.trappexcellent series of blogs on the Package Concept for this.  However, if your development is not split up like this and tends to reside in large development class style 'buckets', you may be faced with multiple releases of code in the same packages with the only possible way to determine release 2 form release 1 being in the creation date (and sometimes this is not a given either if code is cut 'n' pasted).

Therefore, this led me to see how I could construct my own object collector in Code Inspector. 

The Solution

After some initial investigations with /SCF/ based function modules, I happened upon the CL_CI_COLLECTOR_* classes, the CL_CI_COLLECTOR_ROOT and CL_CI_COLLECTOR_TRDIR_PROGS ones in particular and also the interface IF_CI_COLLECTOR.

So I set upon creating my own ZCL_CI_COLLECTOR_DATE_RANGE class by copying the CL_CI_COLLECTOR_TRDIR_PROGS class which relates to the 'Programs from Catalog of Report Sources' collector. Then I proceeded to try to understand the methods within it. Sometimes this is a pretty daunting process within SAP but in this case they are pretty simple to understand.

The methods are all inherited from CL_CI_COLLECTOR_ROOT and I have redefined all of them apart from the IF_CI_COLLECTOR~DISPLAY_DOCUMENTATION and CONSTRUCTOR methods. IF_CI_COLLECTOR~DISPLAY_DOCUMENTATION does not need to be redefinted as this al taken care of in the *ROOT implementation. how to create the relevant documentation entry is dealt with later in the blog. For the CONSTRUCTOR this is created, rather than redefined.

In order, the methods perform the following functions:

IF_CI_COLLECTOR~COLLECT

This is the real doing method. This is where the population of the object list is carried out. As mentioned, I am using the CL_CI_COLLECTOR_TRDIR_PROGS class as base. It's a pretty comprehensive method but easy enough to add my own requirements into. No doubt over time I'll refine them some more as we test more thoroughly. I suspect we will add in a way to remove table maintenance dialogs for example.

IF_CI_COLLECTOR~QUERY_ATTRIBUTES

The second most important method of the class, this is where the query popup is specificed. The real work is carried out in the *ROOT class but here we can effectively add attributes to specify the screen to be shown.

fill_att is the macro declared above with the attibutes being selection screen element, name and type.  In the highlighted one, the one I added, this is a date selection option (type 'S'). In the other attributes you can see the types as 'G' - group and 'C' is checkbox.

This then results in the screen below.

I have removed some of the standard attributes found in CL_CI_COLLECTOR_TRDIR_PROGS to streamline the selections a bit but most are still present.

IF_CI_COLLECTOR~DISPLAY_DOCUMENTATION

Does what is says on the tin!  When the user presses the blue info button next to the collector title, the standard ABAP help documentation is displayed. For this, navigate to transaction SE61 and enter the values below - substituting your class for mine, obviously...

IF_CI_COLLECTOR~GET_ATTRIBUTES

IF_CI_COLLECTOR~PUT_ATTRIBUTES

These methods can be dealt with together as they work in conjunction with one another. Basically, when you call up the object collector screen, you may see the 'selection made' icon (highlighted below). This means that the selections you have made last time have been kept, This is made possible by the two aforementioned methods saving and retrieving values.

CONSTRUCTOR

Creating the constructor, I basically took the code from the CL_CI_COLLECTOR_TRDIR_PROGS constructor and cut and pasted it. Then made a minor addition to the title text element.

Ok, so that's' great. We now how our new custom object collector! But it doesn't appear in our object collector dropdown :sad: .  This is enabled very easily though via the Management of Object Collectors option available via the main screen of SCI. :smile:

This then displays the following sceen where you can now select the new object collector, save..

...accept the 'Yes' option of the popup option...

... and bingo! Your custom object collector is now in the popup list and ready to test out.

As it happens, I completed all of this development on the SCN preview 7.02 system - which was great as it means that anyone reading this can do the same.  Then I tried to implement it on a 7.00 system and found out that the CL_CI_OBJECTSET class, referenced multiple times within the IF_CI_COLLECTOR~COLLECT method, is subtly different between the versions. Perhaps the subject for another blog if I receive any interest?!

In the meantime,  I hope you find this of use.  I am certain it will really help us out for fine tuning the quality stats that we'll be feeding into CCLM...