See how to customize an ABAP Test Cockpit (ATC) check variant, to transport it, and to set up ATC reports. You can understand the techniques needed to determine if an error should be corrected or ignored and learn to manage the mass results of ATC reports runs.
Key Concept
SAP NetWeaver ABAP Test Cockpit (ATC) is a freely available tool for static quality checks of ABAP programs. It offers full as well as partial automated quality checks based on SAP’s best practices of ABAP programming. In its free version, ATC is a blend of Code Inspector, syntax checks, and extended check tools. On the top of the combination of these tools, ATC is also integrated within the development workbench and offers reporting, exemption workflow, and transport block features. ATC checks are classified into categories such as performance, security, and programming. These checks are predefined rules present in the ATC check variant, which is nothing but the Code Inspector check variant. This variant can be customized based on a project or the SAP landscape requirements.
The SAP NetWeaver ABAP Test Cockpit (ATC) verifies the quality of ABAP objects in multiple areas and assigns priorities to these different categories of checks based on their impact. These checks are customizable and transportable. ATC is an SAP NetWeaver feature and is available from enhancement package 2 for SAP NetWeaver 7.0 with Support Package Stack 12.
This is part 2 of my three-article series on ATC. Part 1 focused on step-by-step details of the ATC setup and usage scenarios along with insight from my experiences. In this part, I cover customization of an ATC check variant, its transport, and ATC reporting, along with the feature for mass deletion of ATC results. The execution and analysis of ATC reports play important roles in deciding whether a given error should be rectified or ignored.
See the sidebar “Tips on Techniques for Customization of the ATC Check Variant” for details on when and how to initiate a check variant customization as well as how to evolve it.
Tips on Techniques for Customization of an ATC Check Variant
An ATC check variant is a set of rules that is categorized in multiple areas, including general checks, performance checks, security checks, syntax checks, robust programming, programming conventions, search functions, application checks, user interfaces, and usability checks.
The different check variant categories have priority 1, 2, and 3 errors. Priority 1 and 2 errors are critical and demand rectification for the smooth functioning of the production environment. Priority 3 errors pose a low risk, so they can be ignored if the project schedule doesn’t allow their rectification.
The decision on customization of an ATC check variant is important for achieving the quality goals of an SAP program. Knowing what to customize requires some experience of analysis on ATC reports for the given SAP project and production environment. It is an evolving journey in a given project.
Some of the checks can be customized right from the start of the project. For example, you can prohibit performance checks on a SELECT query for very large database tables in production by putting an ATC check on their use in a SELECT query. ATC shows these errors and you can then do the necessary rectification. Also, in the case of ATC transport block functionality, such programs are never allowed for transport, thus preventing performance issues later in production.
A few other checks that you can customize are from the programming guideline and manual code review check list. Every project generally follows an ABAP programming guideline, which is a list of standards. A tailored version from these programming guidelines is commonly referred to as the code review checklist across projects. Guidelines and checks, which can be moved in ATC check variant customization, can be opted for during customization setup right from the start of that project.
For some other checks, a project can use an SAP standard check variant initially and do a manual analysis of ATC execution reports. If these errors are ignored repeatedly, then those checks that cause these errors can be relaxed in a check variant via customization. For example, driver programs may give lots of errors although they may not need rectification. Cloning of SAP standard programs may also give many errors that are beyond the scope of the project team to rectify. Once such checks are relaxed in the ATC setup, they should be added to the manual code review check list of that project by its quality leads. This step ensures that future custom code in such programs will not be left unattended from the quality review and necessary rectification of similar errors, if any.
A combination of the above techniques leads to a set of rules for the customization of an ATC check variant. Assuming that an ATC check variant once set up would serve until the end of project is not right. During the entire build phase of any project, the ATC check variant evolves and undergoes changes based on the above mentioned situations. During the testing phase when testing bugs in ABAP programs are rectified and run through ATC checks, customization of ATC checks may undergo a round of changes. The testing phase generally has a tight schedule for its successful closure and has multiple cycles in the case of implementation projects. So not only would ATC run frequency increase during this phase but also some of the low-priority errors could also be relaxed via changes in ATC check variant customization. These decisions are commonly governed by the testing lead, quality team, and project manager of that project.
ATC Check Variant Customization and Transport
A Code Inspector check variant is used in the ATC setup. The SAP standard check variant is called DEFAULT. There is scope for customizing the check variant. This customization is based on programming standards and the code review process in a given project.
Note
For SAP HANA migration, ATC has two special check variants in SAP NetWeaver 7.40, namely, FUNCTIONAL_DB and PERFORMANCE_DB. These two check variants perform static checks on ABAP programs necessary for SAP HANA migration. These check variants are beyond the scope of this article.
1. To customize the check variant as per project requirements, execute transaction code SCI. The same path can be reached via ATC transaction Quality Governance section > Manage Check Variant. Click the Manage Check Variants node to go to Figure 1.
Figure 1
Code Inspector home screen with the DEFAULT check variant
2. Figure 1 shows the SCI Code Inspector transaction. Enter the value as DEFAULT in the Check Variant Name field. Click the copy icon so that a custom check variant can be created from the SAP standard one. By doing so, all the values of the DEFAULT check variant are passed into the custom check variant. It is generally followed as a best practice so that most of the SAP standard checks are retained even in a custom variant.
3. In the pop-up screen shown in Figure 2, enter the name of a custom check variant with its description.
Figure 2
Custom check variant copied from the DEFAULT check variant
4. A small icon appears before the variant name for the local/global toggle flag of the variant. By default, it is a local flag. Click this icon so that the custom variant becomes global as shown in Figure 3.
Figure 3
Global flag for a custom check variant
Due to this global flag, a check variant is available to all users. In the case of a local flag, it is available and managed locally by the user who created it. This flag controls the person responsible for the attribute of the check variant. Click the continue icon.
5. The custom check variant appears in the Check Variant block after its creation. Now, it is copied from the SAP standard DEFAULT variant. It can be edited further as per specific requirements. To do so, click the change icon as shown in Figure 4.
Figure 4
Global flag for a custom check variant
6. In the next screen, the check variant with all the customization options appears as shown in Figure 5. There are multiple categories based upon which ATC performs checks on ABAP programs such as performance, security, and syntax checks.
Figure 5
Custom check variant
7. For example, you can search for a pseudo comment in the ABAP programs explicitly by using the search function of the ATC check variant. To do so, click the yellow arrow next to Search Functs. > Search of ABAP Tokens as shown in Figure 6. When you use a pseudo comment you programmatically suppress ATC errors without their analysis. These errors may be critical for a smooth production operation and in that case would need rectification.
Based on recommendations of technical experts, use of pseudo comments should be avoided. An alternate way of suppressing errors is using exemption approval workflow within ATC. Outside the system, errors can be evaluated manually and a decision can be made to ignore them if they are low-risk errors. Hence, in this example, the setup on search of such pseudo comments via an ATC run is shown. Whether to ignore pseudo comments manually outside of ATC or via exemption approval within ATC is the sole decision of the project authority. Our intent in this step is to find the pseudo comment and to get it as part of the ATC errors output.
Figure 6
Search ABAP tokens
8. In the pop-up screen that appears, enter the value in the search string and select the Comments and Literals check boxes as shown in Figure 7. Literals are direct values of numeric or character types that are assigned to variables in ABAP programming. I am selecting Comments and Literals so that the string mentioned in Search String is searched in these categories. Click the continue icon to proceed further.
Figure 7
Search token value entered
9. In the next pop-up screen (Figure 8), select Single Value and click the continue icon. You choose Single Value because there is one search string entered in the above step, which is “##EC_CL_*.
Figure 8
Include the selection for the Single Value pop-up
10. Now select the check box next to the Search of ABAP Tokens option. Click the save icon as shown in Figure 9. A message then appears as shown in Figure 10 at the bottom panel. An interesting point to note is that neither a development package nor a transport request is prompted. The check variant is saved without these options. Therefore, it is only available in this system.
Figure 9
Select the check box option
11. To have the same custom check variant in a quality system, you can either create the check variant manually following the above steps or use the Transportable option. To use the Transportable option, check the Transportable check box as shown in Figure 10 and click the save icon.
Figure 10
Transportable option of the ATC check variant
12. In the next pop-up screen, the system prompts you for a development package (not shown). Provide the custom development package used in the project and click the continue icon. It can be found from the Search Help of this field by pressing F4.
The system prompts you further for a workbench transport request. Provide the workbench transport request as shown in Figure 11 and click the continue icon. The workbench transport request number is automatically generated by the system. ATC administrators create their own transport requests by clicking the create icon from the popup in Figure 11. The system generates a transport request with the number. An ATC admin can provide the description and use this request in this step.
Figure 11
Transportable option of the ATC check variant
Other required customization can be done in the ATC check variant in a similar way.
ATC Reporting
ATC report execution happens manually or by a background scheduled job, as described in part 1 of this article series, for local and central ATC setups. Report result viewing and its use for both local and central run reports are leveraged via transaction code SE80 in the development system.
In the case of a central run, this is the same development system whose Remote Function Call (RFC) connection is mentioned in the ATC setup. Via a trusted RFC, the report results are distributed in this development system. In the case of a local run, the results are automatically available after you execute transaction code SE80 in the same system.
Note
Reporting is the crux of all the features of ATC. Report fetching and its manual review play an important role in deciding whether errors should be rectified or ignored. Production-critical errors should be planned for rectification while the errors having a low impact on production functionality can be ignored.
13. To view the ATC report results, log in to the development system. Go to transaction SE80.
14. There is a button in transaction SE80 for the ATC Result Browser. The button doesn’t appear by default. To have it appear, follow menu path Utilities > Settings > Workbench (General) tab. Select the ATC Result Browser check box as shown in Figure 12. Click the continue icon.
Figure 12
Utilities menu settings
15. Now, the ATC Result Browser button appears in the Object Navigator screen. Clicking this button opens the results listing of local and central runs in the bottom panel (Figure 13). The local run is represented by the development system (D), and the central run is represented by the quality system (Q).
Figure 13
The Object Navigator screen with the ATC Result Browser
16. In Figure 13, expand the D and Q nodes to show the runs that have happened for these systems as shown in Figure 14. These are the two systems for which ATC setup was carried out: local setup in the development (D) system and central run in the quality (Q) system. These setups are explained in detail in part 1 of this series.
The count of priority 1, 2, and 3 errors also appears along with the run as shown in Figure 14. Priority 1 and 2 errors are recommended for rectification. Priority 1 means high priority, 2 means medium, and 3 is a lower priority error category. They are standard SAP based on the rules set up in the Code Inspector check variant.
Transaction code SE80 offers reporting of these errors based on systems and users. These reports can be downloaded from this place for further analysis.
Figure 14
System-wise ATC run details
17. To know the basics of a run such as the execution date or the check variant name, right-click the run name in the left bottom panel and these brief details appear in a pop-up screen (not shown).
To see all the details of programs with ATC errors, double-click the run name in the left panel. The details appear on the right side of the window as shown in Figure 15. By default, the system tries to show the ATC errors of a logged-in user. In this example, there are no errors reported on logged-in user SMUSER. Click the Clear Filter button to remove this default filter criterion.
Figure 15
The ATC result screen view
18. After the system removes the filter criterion, all the ATC errors of that run appear on the screen as shown in Figure 16.
Figure 16
All ATC errors
19. The result appears with the default screen layout of columns. To change the layout, click the Change Layout… button as shown in Figure 17.
Figure 17
Change the layout option
20. A popup appears after you select the Change Layout… option in Figure 17. In that popup, select the columns of interest and add them by clicking the left arrow icon to move them into the Displayed Columns section shown in Figure 18. In this case, all the fields are already shown in the Displayed Columns side. Change the order of columns by using the move up and down arrows in the Displayed Columns section. Once all the columns are selected as shown in Figure 18, click the save icon to save this layout for future use.
Figure 18
Save the report output layout
21. In the next screen, add the name of the layout and select the Default setting check box as shown in Figure 19. Click the enter icon to continue. This means whenever a user opens a report in this system, this new layout is automatically used by the system for output.
Figure 19
Custom layout as the default layout option
22. Once the custom layout is saved, the report outcome changes to this new layout. This report can be downloaded in Microsoft Excel for further analysis with the option of Export > Spreadsheet shown in Figure 20.
Figure 20
Spreadsheet download option
Note
This analysis of errors can be on multiple areas, including priority, status, developer, or message-type errors. Analysis is important so that the errors can be reviewed by developers. Based on the review, errors can be either rectified or ignored. The ignored errors should be accompanied with a strong technical or business justification as to why they should be ignored. This justification should be reviewed and approved by the technical lead or quality leads.
The frequency of ATC results analysis is generally based on the frequency of report runs. During the build phase, most implementation projects follow a weekly run of ATC reports for the entire development portfolio. After each run, the quality or technical lead can download the report results in Excel followed by its manual analysis. This analysis is carried out by each involved developer for his or her development objects. This analysis should highlight if the concerned developer will either rectify the error with mention of a deadline or opt to ignore it with a reason. These errors are tracked by the Identity column value for a given error. The Identity column acts as unique number for each error. The entire analysis should be reviewed and approved by the quality or technical lead.
When the ATC exemption process is used, ignoring errors is carried out by the exemption workflow. This ATC exemption workflow will be explained in detail in part 3 of this article series. When no exemption process is used, ignoring errors is completely manual and driven by results analysis in Excel sheets as mentioned above.
After this process, the quality or technical lead can publish the weekly status on SAP project quality. The summary of this status can highlight total ATC errors reported versus the errors ignored or exempted versus the errors opted for rectification. A periodic trend of these errors should be drawn to show the technical quality health of the SAP project over a period of time. If SAP Solution Manager Custom Code Lifecycle Management (CCLM) functionality is implemented, then this trend is projected graphically in its Quality section.
Mass Deletion of ATC Results]
Another important aspect of reporting is to manage results. In case there is an explicit requirement to remove the errors log (for example, error logs of an unintended or demo ATC run), a facility is offered in the ATC transaction for mass deletion of results.
Note
In the initial phase of the project when ATC is set up, multiple trial runs are conducted manually as well as via background jobs. These are local runs within the development system as well as central runs from the quality or ATC master systems. Once the trials are successful, the trial error logs require deletion so that ATC reports have only that data that needs to undergo analysis for decision making. In such a situation, mass deletion of ATC results is a handy feature.
Even during the customization of an ATC check variant, mass deletion of results can be leveraged if required (e.g., changes to the check variant setup to avoid errors from cloned SAP programs or driver programs). An ATC run before such a change would result in many errors, although after the check variant changes, those errors would be gone. The intermediate ATC errors before such changes can be deleted if it is demanded by the project governance and quality teams.
For the routine project ATC errors, there is a life span in days set as part of ATC setup. This is described in part 1 of this article series. Those errors are automatically deleted by the system once the life of a given ATC run error is over as per their setup value of life span days. In case the project explicitly wants to delete such error logs before their life is over, then mass deletion of results can be used. This is not observed commonly due to audit requirements, although it can be enacted based on the direction of the project governance team with a genuine justification.
23. Go to transaction ATC using admin access and select the Runs > Manage Results option. In the selection screen that opens, provide the date range whose results are required for deletion. Enter other relevant inputs, if any. Click the execute icon as shown in Figure 21.
Figure 21
Manage the results selection screen
24. The next screen lists the run results. Select the result that needs deletion. Click the Delete button as shown in Figure 22. The system prompts a popup for a confirmation for deletion (not shown). Once you confirm, the results are deleted from the system. In this way, mass selection and deletion can happen in one go.
Figure 22
ATC results deletion option
Sapna N. Modi
Sapna N. Modi has 13+ years of experience in the software industry including SAP software in the areas of solution architecture, consulting, presales, and project management. Sapna has multiple SAP and non-SAP certifications. She is an integral part of the team in setting up the SAP Solution Manager practice at L&T Infotech (www.lntinfotech.com) and has participated in consulting and advisory roles for multiple projects. She has global exposure with experience in the US, Canada, Denmark, Sweden, Germany, the Netherlands, and Kuwait. She is instrumental in and is dedicated to an extreme automation initiative of SAP projects across verticals at L&T Infotech (LTI). Her goal is to accomplish automation-driven efficient operations and to formulate an automation platform for optimized TCO for customers as well as for her organization. Her focus is on innovation to leverage SAP products and non-SAP products involving Robotic Process Automation (RPA), Artificial Intelligence (AI), and Machine Learning (ML) to help customers standardize their portfolio so that it is simplified, automation ready, and able to easily migrate to the SAP S/4HANA platform.
You may contact the author at sapna.modi@lntinfotech.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.
