Tag: ABAP test cockpit

ATC: managing your complete custom code base

This blog will explain you the ATC tool to manage your complete custom code base. The name ATC is bit misleading: officially the name is ABAP Test Cockpit, but the tool has nothing to do with test management. It is a code profiling tool.

This blog will answer questions like:

  • How do I scan my complete custom ABAP code base for issues?
  • Can I scan custom ABAP code for a complete project?
  • What is my state of quality of my complete ABAP code base?
  • The SCI SAP code inspector is nice, but how can I enforce it?
  • How can I use ATC in the peer review process?
  • How can I prevent an ABAP workbench from being released if the coding is not ok?
  • Does the ATC tool replace a peer review?
  • How do I organize the implementation of the ATC tool in my organization?
  • How is ATC used in S4HANA migration?

Setting up the ATC tool

Setting up the ATC is quite simple. Just launch transaction code ATC:

Then choose the Configure ATC entry on the screen.

The ATC tool runs on top of the SAP code inspector (SCI). This must be setup first. Choose the variant you have created here as Global Check Variant.

To enable peer review set ATC exemptions to Yes.

If you want to integrate ATC with transport system: set the behavior on Release to either information or error. Be aware that if you set this setting to Error, the transport mechanism will run the ATC tool and will completely block release and transport if any prio 1 or 2 item is found! Only when the issues are solved or exempted, the transport will be released.

This is a great feature for enforcing code standards, but do not switch it on after you have some experience with the ATC tool and your developers are used to the process. Switching it on should also be clearly communicated to basis team and all consultants working on the system. They should be aware of the block coming when releasing transport in SE10 (the description of the block is bit cryptic):

Running the ATC tool

The ATC tool can be run in two different modes:

  • Globally by development lead for complete custom code base
  • Locally by developer for one or more of his objects
Running ATC tool globally

To run the ATC tool on all custom code you need to select the Schedule Runs in the ATC tool menu.

Before you can run the tool, you have to create a Run variant. In the setup of this variant it is very important to select the right packages. For custom code only put in Z* in the package selection. If you have projects doing development in separate packages, it is possible to setup a dedicated project variant for that Z project package only.

If you have chosen to use the exemptions and allow pragma’s to be used by the developers, do check the help text in Handling of pragma’s carefully before making a selection.

After the variant has been created, you can now select is and press the Schedule button:

In the next screen before hitting execute, please make sure you have checked the number of processes versus your system hardware. The default value of 10 is pretty aggressive and is assuming a large development system. Use transaction SM50 to check the amount of dialog processes on your system. Don’t fill in more than half the amount of DIA processes than your system has. If you do you might find an angry basis admin at your desk asking you why you are completely filling up your system….

After the executing starts a batch job is triggered, which will fire off as many dialog processes as you have indicated. The amount of time the job takes depends on:

  • Amount of Z code in your system and selected in your variant
  • Amount of processes chosen and infrastructure power you have
  • Using HANA or not (complete code base scanning on HANA runs amazingly fast: full code base of 1000 Z objects with 10 parallel processes can finish under 10 minutes. Running same on slow non-HANA system can run over 8 hours in the night.)

You can use the ATC run monitor to see if your run has finished:

Result of ATC run

When the run is finished go to the Manage Results entry in the ATC menu.

Here you can see the results and the statistics of the results of your run.

If you are working in an agile devops environment this overview screen is very nice. If you run the ATC tool daily or weekly, this can immediately provide you with the needed code quality KPI statistics for the ongoing sprint.

If you select the run results you get a list sorted by priority. Selecting one of the findings will give you the details of the finding (code positing, explanation of reason of the finding):

Double clicking on the object name will immediately jump you to the code program point where the finding is found.

Running the ATC tool locally

The other option is to run the ATC tool locally. In each editor you can call Program/Check/ABAP test cockpit to run the ATC for you specific program.

If you work in Eclipse, you can also run ATC by selecting Run/Run as/Abap test cockpit.

Fixing ATC issues

The easiest way of fixing ATC is simply taking away the root cause. In some cases this simply isn’t possible. Reason can be: you have to select data without full key and ATC is detecting this as error. If agreed upon, you can use the corresponding pragma to suppress the finding in the results. Best practice here is to add a comment line why the pragma was used.

Another sample program:

REPORT zpragma.

DATA: zgs_mara TYPE mara.

* need all for demo, suppress with pragma
SELECT MATNR FROM mara INTO zgs_mara. "#EC CI_NOWHERE
ENDSELECT.

The corresponding ATC result looks like this:

As you can see the error for having no selection clauses is not shown. It is suppressed with the #EC CI_NOWHERE pragma.

The ATC is still throwing issues: there is no check on SY-SUBRC. If needed the ATC tool suggests to use the #EC CI_SUBRC pragma.

Practical use of pragma’s

If you want to allow the pragma’s or not is up to you. The ATC result list can be configured to simply ignore the pragma’s. Best practice is to allow the use of pragma’s, but to demand comment line with explanation. Some pragma’s (like the previous example of not checking sy-subrc) you might suggest not to use at all.

Apply OSS note 3088590 – ATC: Offer default option to handle pseudocomments and pragmas to set default options for pragma handling.

Use of exemptions

If the issues in ATC cannot be solved by changing the code or using the pragma, the last resort it to request an exemption.

This can be done on the detailed screen of the ATC finding:

Upon requesting the system will ask you to fill out why the exemption is needed:

The approver need to be configured in the ATC overview screen. Only the exempters in that list will be shown here.

Unfortunately the ATC tool forces you now to enter a fixed name here. You cannot send the exemption to the group of approvers.

Judging the exemption

If the admin allows to setup mail on your development system you are lucky and get a mail (if configured in the ATC main configuration screen). If not, you either have to check regularly or ask the developers to tell you if they have submitted and exemption.

In the ATC main screen select the Exemption Browser select the exemptions for which you are the approver:

You get a list of items for you to approve, reject or return to the requester.

Again here: if you don’t have mail system, send a signal to the requester that you did an action.

Dealing with old ABAP code

If you have to perform a change to ABAP code that is created before you implemented the ATC tool, the tool might highlight a lot of issues that are in the old section of the code. Should you fix these issues as well? This depends on the size of the coding and the organizational agreements you make. Typically if the coding is very small (user exit with 20 lines) it is common just to fix it. If the coding is large, best practice is to ignore the findings of the ‘old’ code: it is simply too dangerous and too much work to fix it. Or you can work with the baseline option (see this dedicated blog).

ATC tool versus peer review

The ATC tool does not replace a peer review. It is a tool to speed up the peer review, since the tool takes away the burden of the more technical checks like naming conventions, checks of use of SY-SUBRC, are hard coded text replaced by text symbols etc.

Peer review tasks that cannot be done by the ATC tool:

  • Judgement if the development itself makes any sense
  • Judging use of comment lines (sufficient?)
  • Judging if the coding is structured in readable way: future maintenance can be done easily
  • Correct use of pragma’s
  • ….

Implementation of the ATC tool in your organization

The ATC tool can be implemented in every organization.

Steps to do:

  1. Organize your code standards: have them documented and approved. This is the basis for the setup of the SCI variant you want to run in the ATC tool.
  2. Deploy the SCI tool in your developer community and make sure they understand and run the tool consistently. This is also the time you can fine tune the outcomes of the SCI tool.
  3. Now setup the ATC tool without Exemptions and without transport block. First run the tool globally only yourself to see and understand the ATC tool results and statistics. This will get you a feeling on how long the tool runs on your system and how many exceptions it will report.
  4. Consider if you want to use the pragma’s fully, partially or not.
  5. Set up the Exemption users and organizational agreements (like dealing with old code).
  6. Start to communicate the use of the ATC tool to your developers. If you didn’t think about the pragma’s and the exemption process you will very soon receive many questions from the developers.
  7. If the ATC process with exemptions is running stable, if you want you can now turn on the transport block to avoid any bad code from being released.

From step 1 to step 7 can take several months depending on the speed you can organize, agree and communicate the usage of the standards and tools. Don’t rush it without having the proper communication and organization.

Reorganization of ATC data

If you have large custom code base and run ATC often, the results table SATC_RT_RUN_EXE might get large and your system admin might complain to you about it. If this is the case you can schedule clean up program SATC_AC_REORG_REPOSITORY on weekly basis.

Running ATC central for more systems or against older versions: remote ATC

If you want to run ACT centrally for more development systems, or against an older SAP version not yet enabled for ATC: please read this blog on remote ATC.

ATC settings logging

The ATC setting changes are not logged. The logging is needed if you have a large crew of ABAP developers and apply the rules strictly (for example if you use the option to give an Error on transport release with ATC). To achieve this, switch on table logging for table TRCHECK.

Scope of ATC

ATC is capable of analyzing ABAP code.

For analyzing Smartforms, please make sure you have implemented the OSS notes listed in note 2715684 – Smartforms are not being checked by ATC.

For analyzing Adobe forms, please make sure you have implemented the OSS notes listed in note 2617401 – ATC: Enable ATC Checks for Adobe Forms.

It cannot analyze AMDP code. See OSS note 3086517 – AMDP method not checked by ATC.

S4HANA custom code migration

The ATC tool is a cornerstone tool in the S4HANA custom code migration. For more information, read this dedicated blog.

Running ATC on standard SAP or addon

For running ATC on standard SAP or on an addon, follow the instructions in this blog.

Running ATC on a transport

Running ATC on a transport is explained in OSS note 3250073 – How to perform ATC check of transport request.

ATC explanation notes

ATC explanation notes:

ATC bug fix OSS notes

ATC bug fix OSS notes: