Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at firstname.lastname@example.org.
Calling the Code Inspector
Last month we examined the Code Inspector Framework, which should have given you a good foundation on the components of a Code Inspector inspection process. Lets look then this month on using the Code Inspector day to day to help us write better code.
This blog will focus on the code inspector prior to EhP2 for SAP NetWeaver 7.0 support package stack 12 (SAP Basis 7.02, SAP Kernel 7.20) and EhP3 for SAP NetWeaver 7.0 support package stack 5 (SAP Basis 7.31, SAP Kernel 7.20). The reason I bring this to your attention is because after the above, we now have a NEW solution for quality management called the ABAP TEST COCKPIT. The ABAP Test Cockpit is a new ABAP check toolset which allows you to run static checks and unit tests for your ABAP programs. In order to ensure a smooth migration and comparable check results throughout your company, the ABAP Test Cockpit is compatible with SAP’s Code Inspector. This means you can reuse your custom Code Inspector checks and variants in the ABAP Test Cockpit.
Back to our Blog…..
When you are working on a program, function module, or class, you typically call the ABAP Syntax Check directly from the editor iteratively as we code. But wouldn’t it also be nice to have the performance or security checks of the Code Inspector at your disposal while coding? As of Web AS 6.10, you can call the Code Inspector for the object you are working on from the menu of the ABAP Workbench (SE80), the ABAP Editor (SE38), the Function Builder (SE37), or the Class Builder (SE24). When called from these workbench transactions, the Code Inspector automatically applies the DEFAULT check variant to the examined objects and the inspection results are not persisted.
Select <Object>=>Check =>Code Inspector where <Object> represents a “Program,” “Function module,” or “Class.”
Check Variants That Come with the Code Inspector
The Code Inspector comes with a variety of individual checks that you can combine into check variants. You can transport global check variants through the system landscape like any other transportable SAP object.
The Code Inspector comes with a few global check variants, the two most important of which are:
DEFAULT: Every inspection started from the ABAP Workbench uses the DEFAULT check variant, which is very extensive. This check variant contains the normal and extended ABAP Syntax Checks, as well as additional performance checks and security checks. You can also check workbench objects with a different combination of checks by defining your own local DEFAULT check variant, which will then override the global one. You create a local DEFAULT check variant either with transaction SCI or from the result screen of a workbench inspection.
PERFORMANCE_CHECKLIST_XL: This check variant includes a basic set of checks for performance analysis, such as “Analysis of the WHERE clause for SELECT, UPDATE, and DELETE.” It comprises the most important performance checks to help you identify poorly coded SQL WHERE clauses or statements.
Calling the Code Inspector for Several Objects
To check many objects at the same time, you use the Code Inspector to create object sets, add individual checks to check variants, and combine an object set and a check variant to an inspection. Each instance of these elements can be either global or local.
Creating an Object Set
In order to check more than one object, you define an object set. For example, suppose you want to check all ABAP object classes for user “HA92974”. You could follow these steps:
1) Call the Code Inspector using transaction SCI.
2) On the initial screen, enter a name for the object set and click the “Create” button, which takes you to the Object Set selection screen.
3) In the “Object Assignment” area of the “Select Object Set” tab, enter the SAP user name “HA92974” in the “Person responsible” field — not to be confused with the “Person Responsible” field at the top of the screen, which is the name of the person responsible for the object set itself which is “E71800017” in the screen below.
4) In the “Object Selection” area in the lower area of the screen, enter an asterisk (“*”) in the “Class/Interface” field. The asterisk ensures that all classes assigned to the user “HA92974” will be included. If you enter “ZCL_SV*” instead, only classes that start with “ZCL_SV” are selected.
5) Save the object set by clicking the “Save” button in the standard toolbar.
Once you have created and saved an object set, you can then tailor your object selections further. For instance in the Object Assignment section you could use the additional Package, or SAP Component options to include or exclude single packages or components. Note that these options are linked by AND operations. Be careful NOT to choose entries that define a set without an intersection. For example, if I choose user HA92974 and SAP Component “FIN” and this user has no objects in that component, then the resulting Object Set will be empty.
Creating an object set from scratch is typically the first method you learn. Once you become familiar with using the Code Inspector, other methods of creating object sets offer added power and flexibility. You access these additional methods via the following tabs on the object set screen:
Edit Object Set: You can combine object sets and filter them based on the attributes “Object Type,” “Object Name,” “Package,” and “Responsible.” Use this option when you want to create an object set that consists of some combination of two other object sets.
Object Set from Result: You can create a new object set containing objects that triggered messages in aprevious inspection. Again, you can filter the set based on the attributes “Object Type,” “Object Name,” “Package,” and “Responsible,” and also by a single check, its message codes, and message priority (“Error,” “Warning,” or “Information”). Use this option if you want to determine your result set in several steps — in other words, use any objects that raise issues in a first inspection as the object set for a subsequent inspection.
Object Set from Request: You can also extract object sets from transport requests/tasks and filter them based on the attributes “Object Type,” “Object Name,” “Package,” and “Responsible.” If there are program like objects in the request, the new object set will contain only their associated main programs (programs, classes, or function groups instead of includes, methods, or function modules). Use this option when you want to check the objects in a transport request. For example, you might want to ensure that only objects adhering to your security rules are transported into your production system.
Obj. Collectors: You can use generic collectors to create an object set. You can do this by loading the objects from files or from object lists of programs, such as Where-Used List, Coverage Analyzer, or Runtime Analysis. Then in the Set Filter screen area you can filter them.
WARNING – A daily background job prevents the Code Inspector from accumulating too much data. Inspections and object sets have an automatically generated deletion date of 50 days ahead, which means that the inspection or object set will be deleted after 50 days. Inspections that have not yet been executed, as well as object sets included in those inspections, are excluded. To keep your object sets or inspections for a longer time, simply change the deletion date. You can change the deletion date individually for individual inspections and object sets.
Creating a Check Variant
After creating an object set, the next step is to decide which checks you want to execute on those objects. The Code Inspector always uses check variants, which are compilations of individual checks, instead of single checks only. The standard check variants we examined earlier (DEFAULT, PERFORMANCE_CHECKLIST_XL), that come with the Code Inspector may be sufficient at first, but if your like me, sooner or later you will want to create your own check variants for more flexibility. Creating a check variant is easy. You select checks from a tree that contains all active check categories with their respective active individual checks.
Follow these steps to create a new check variant:
1) In transaction SCI, enter a suitable name for the check variant and click the “Create” button.
2) To add a check to your check variant, select the checkbox next to the check. To see information about a check, click the “Information” button next to the checkbox.
3) Some checks require USER Parameters. You can see this by the icon next to the check. You can set one or more parameters to further define the check attributes. These attributes can be input parameters or can activate a sub-check (a component of a single check that can generate a message). Click the arrow to display a popup where you can set the parameters.
4) To save the check variant, click the “Save” button on the standard toolbar.
Creating and Executing an Inspection
OK, so finally we get to the crux of what this has been leading up too. I hope you are still with me, cause all of the prior work has lead us here. If you are still here…. You now understand how to create an object set and a check variant. Next, you want to apply the individual checks of the check variant to the objects in the object set. This process happens during the inspection run. So you will need to combine a single object or an object set with a check variant to define the test task that performs the inspection.
Remember that inspections can be anonymous or named. Anonymous inspections are useful for ad-hoc queries with only a few objects where you do not need the results to be persisted. A named inspection is stored persistently with its results. It can handle object sets containing any number of objects. You can also run a named inspection outside working hours by scheduling it in a background job. For our purpose here, we will create a NAMED inspection.
Follow these steps to create and run a named inspection:
1) In the Code Inspector (transaction SCI), enter a name for the inspection and click the “Create” button.
2) Combine an object set, a single object, or objects from a request with an existing check variant.
3) You can run the named inspection in one of two ways…. You just click the execute button to start the inspection immediately… or you can click the other execute button with 3 …. after it to display the “Execution Options” pop-up screen. Here you can further control how and when the inspection is run. This includes selecting a server group for large object sets, so they can be run in parallel across the app servers for performance. This would be done as a Batch job and to schedule the inspection in a background job, click the “In Background” radio button.
4) Execute the inspection!!
The Inspection Results
When an inspection run completes successfully, the inspection screen displays a status message across the bottom of the screen. Press the “Results” button on the “Inspection” screen to display the results. The Code Inspector displays the results of the inspection in an easy-to-read hierarchical tree format. See the example below and make note that we have 3 colors to consider. An entry in the red column (the left column) indicates an error message. An entry in the yellow column (the middle column) indicates a warning message. An entry in the green column (the right column) indicates an information message.
Each message contains the name of the examined object and a short explanation of why the message was raised. If the examined object is a Report, Include, Function Module, Class…etc., you also see the source code position of the statement that caused the message. Double-clicking the message text takes you to the ABAP Workbench, where you can display and edit the object. For further explanation, press the “Information” button next to the message.
You now have created and object set to be examined, the Check variant that has all the relevant CODE checks you would like to employ and ran a NAMED inspection and examined the results. Not bad for a days work!
The Code Inspector comes with a set of built-in checks that are organized into functional categories. In the final installment of this Blog series I will you introduce you to the most important checks in these categories To help you get the most out of the Code Inspector right away!