Next step: in transaction PFCG create a new role (for example Z_CUSTOM_CODE_APP). Add catalog SAP_BASIS_TCR_T as a launchpad catalog:
Save and activate the role. Assign the users to the role.
In transaction /IWFND/MAINT_SERVICE add the following services (and activate them):
code migration projects
of SAP S/4HANA custom code check findings
code scoping by request entry points
code scoping by packages
In transaction SICF activate the following nodes:
The core activation actions are now done.
Start transaction /UI2/FLP to start the FIORI launchpad. You will not find the tile. Change the homepage and add the following tile from the catalog:
Before starting, make also sure that in ATC setup the RFC object providers are setup:
You can name the ID, description and group ID the same if you want. Make sure to use RFC destination none.
Creating a project in the app
Now you can start creating a project in the app. Click on the + symbol to add a project;
In the destination fill out the system you have put into the ATC object provider configuration. Than save the project and let it run. In the background the full ATC check is now carried out. This can take some time. You can refresh the project to see the status:
Scoping the results
In the scope block you can exclude packages by clicking on the Change scope button:
Packages that might be excluded:
Z packages from SAP
Z packages from 3rd party tools
Analyzing the results
When the run is done, you can now analyze the results on the Analysis tab:
A bit below on the Analysis tab is the burn down chart:
For the burn down chart you need to run the custom code run again on several days. Check for tool issues and solve them. Solving tool issues makes the amount of issues go up as you can see on the sample screen above.
Important here is that you have to press the Analyze Findings button to go into the detailed analysis overview:
On the top are the graphical overviews. In the bottom is the detailed list:
You can use the download to excel button for further processing.
During the custom code clean up you can redo the same project, by rerunning the analysis. Or you can decide to run a new project.
In the previous blogs we have explain how to run ATC from central system to remote system. This will enable you to for example run the ATC against an older release, which doesn’t have the ATC tool capability.
But there is one other common issue with older systems: you have lots of existing legacy Z code. If you want to clean up or start with new guidelines the ATC is initially not helpful since it will give you lots of errors.
This blog will explain the concept of baselining the current Z code with an initial run to give you a clean start.
Questions that will be answered in this blog are:
How to setup the ATC baseline?
How to run the ATC baseline?
What are the known limitations of the ATC baseline functionality?
Setting the baseline
To set the baseline, first run a full ATC remote check. This will give many issues. In the ATC results screen select the run and press the button Baseline to mark the current results as baseline.
You can choose that the current results are simply suppressed, are treated as exemptions or are treated as low priority.
If you run ATC tool again, please make sure in your run variant that you now select the consider baseline tickbox:
If you don’t change any coding in the remote system the next run of ATC should give you a clean run with no issues (in case you have chosen suppression).
ATC after baseline
In the remote system we now do 2 coding changes:
We had before the baseline a bad program called ZCRAP1. To this program we do a change.
We created a new program called ZCRAP2.
Now we run the ATC tool again with the baseline to ignore the baselined findings.
The ATC tool now finds issues in both the changed and the newly created program.
The unfortunate thing is that for the old program, it does not look at the newly added lines, but it looks at ALL the issued in the analyzed code (also the existing).
This might lead to some surprise if you add 1 line to a 1000 line existing bad code: this will give lots of errors. It is up to you to decide to fix the existing errors or just exempt the existing ones.
In the blog on readiness check 2.0 we explained how you can perform analysis on your system as preparation for the S4HANA upgrade. This blog will explain how to run detailed analysis on your custom code as preparation for S4HANA upgrade. Pre-condition is that you have installed 7.52 netweaver system and done the configuration for remote ATC as described in this blog.
Questions that will be answered in this blog are:
What do I need to do in order to set up the remote S4HANA readiness check in ATC?
How to run the remote S4HANA readiness check?
How to handle the results of the remote S4HANA readiness check?
How to set up remote ATC for S4HANA readiness check?
To run the remote ATC for S4HANA readiness check you must install a netweaver 7.52 system and configure the remote ATC. Instructions can be found in this blog.
In the SAP code inspector (for details see this blog) you can now find the S4HANA readiness variants:
How to run the S4HANA readiness in ATC?
To run the S4HANA readiness variant create in the ATC tool (for all details see this blog) a special S4HANA readiness run series:
In this run it is important to put your analysis system object provider into the variant!
Now start the ATC run and be patient. The run might take a few hours pending on your system size and Z code base sizing.
You can monitor the progress in the ATC run monitor:
You can also see here if any tool issues were reported. If tool issues are present, click on the underlined number and see if you can solve them. Most issues are SAP bugs and you need to apply an OSS note. Before creating new message for SAP make sure you have applied all recent notes for the S4HANA readiness check (2436688 – Recommended SAP Notes for using S/4HANA custom code checks in ATC) and all the remote ATC notes as explained in the remote ATC blog.
How to handle the results?
If the ATC run is finished you can look at the results in the central system:
The results consist of a code point where a potential issue is. If you click on the code point you jump to the analyzed systems code.
There is also a note number which explains what you need to check.
Now basically 3 things can happen:
You can fix the issue directly: nice, the next run the issue is gone.
You read from the OSS note the function has changed or is no longer present in S4HANA. Read the OSS note for alternatives or check with your functional consultant on functional alternatives. Example of change is the way output and pricing is done. You know now it will be changed, but you cannot prepare in the current system. Use the list as input for project management for work estimation.
You read from the OSS note the potential issue and conclude it is not relevant for your situation. Example is material number length handling. If you use material numbers properly this is not relevant for you, but the tool will generate massive amounts of alerts. But maybe in some cases you need to intervene.
To distribute the results, apply OSS note 2499684. This enables you to download the ATC results into xls spread sheet. From here it is easier to follow up if action is needed for long list (like material number length) or not.
If you have done your first round of check, you want to rerun. But some notes you might have detected as not relevant and you want to exclude them.
To do this copy the SCI S4HANAREADINESS variant to your own variant. Then change the SCI variant to exclude the OSS notes you don’t want to see any more:
Now rerun the ATC with the new variant. The list you get will be smaller. Repeat this iterations as long as needed.
Don't change the originally SAP delivered SCI variants. New features and bug fixes by SAP will update this variant. If you have an updated SAP variant, simply copy it again to your Z variant and redo the exclusion of OSS notes.
S4HANA 1809 update and beyond
If you previously installed remote ATC for a 1709 check and want to run now for S4HANA 1809 or higher version, there are a few update steps to follow.
First of all you need a 7.52 or higher system. This might already be big stumbling block if you don’t have this. In past blogs and notes you might find it works for 7.51 as well, but this will have severe limitations. For example the S4HANA Readiness only works properly on 7.52.
Note 2270689 is a HUGE OSS note. It takes 15 to 20 minutes to download and will result into a time-out dump is you have standard 10 minutes set. Ask basis team to set rdisp/max_wprun_time and rdisp/scheduler/prio_high/max_runtime to 30 minutes for you to able to download this note.
Per checked system you will need an RFC connection from the central system to the checked system.
To initialize the remote check per checked system you must run program RS_ABAP_INIT_ANALYSIS:
Also run this program in the central system!
Configuring the central system
Start transaction ATC and goto the setup menu to set the system role:
Select here the second option to make it a central system:
Then goto the menu for setting up the object providers:
First create a group:
The fill the RFC Object providers:
The vital element here is the RFC connection that you have created from the central system to the local system.
Make sure in the central system by testing in SM59: the connection is properly working. Also make sure that the user in the checked system has sufficient RFC rights to execute the remote ATC checks.
Setup the SCI variant for remote execution
In the central system set up the SCI variant for remote execution.
Be aware here one of the major limitations: you can only select the check which SAP has enabled for RFC based check:
Remote ATC run execution
In the central system now define the ATC to run:
The check variant has to be defined in the central system
The variant runs against the selected object provider you have just defined
After the first run you must likely will get check tool failures:
Read the failures carefully and solve them one by one.
The end result is the same as with the local system. By clicking on the code you will jump from central to checked system.
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:
DATA: zgs_mara TYPE mara.
* need all for demo, suppress with pragma
SELECT MATNR FROM mara INTO zgs_mara. "#EC CI_NOWHERE
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.
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:
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.
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.
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.
Consider if you want to use the pragma’s fully, partially or not.
Set up the Exemption users and organizational agreements (like dealing with old code).
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.
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.
S4HANA custom code migration
The ATC tool is a conernerstone tool in the S4HANA custom code migration. For more information, read this dedicated blog.