If you convert ECC to S4HANA you need to execute custom code adjustments for both HANA database migration and for functional application changes. This can be read in this blog and this blog.
If you only want to migrate an existing database to HANA for a netweaver ABAP stack (either standalone or for SAP ECC), you will also need to adjust custom code.
Questions that will be answered in this blog are:
Which custom code ABAP changes to I need to perform mandatory for a HANA database migration?
Which custom code ABAP changes are highly recommended to perform for a HANA database migration?
Which other tools should I use to help to smoothen the HANA database migration?
Mandatory custom ABAP changes for HANA database migration
There are mandatory ABAP changes to be made for HANA database migration. The main ones are:
Native SQL statements
Use of Database hints
Search in pool and cluster tables
Use of ADBC interface
Search for problematic statements without ORDER BY
The first few will not appear too much and are relatively easy to fix.
The last one: the statements without ORDER BY needs some explanation. Some current custom code might work properly with the current database, since some database will present the data to the ABAP application server in a specific sorted way. When migration to HANA database the HANA database might present the same records to the ABAP application server, but in a different sorting or in a random order. This might lead to issues in further handling in custom code. The solution is to analyze the code and to add explicit sorting as per need of the custom program. To scan the usage in live system, see below chapter on SRTCM.
All these changes can be detected with the SCI variant FUNCTIONAL_DB:
Run this SCI variant via the ATC tool on your custom code:
Wait for the run to finish and go to the results. The best overview is when you click the Statistics View button:
Clicking on an item will drill down to the details.
Performance related coding changes for HANA database migration
The second set of custom code changes is from the performance side. For this set you need to run the ATC tool with SCI variant PERFORMANCE_DB:
The PERFORMANCE_DB variant has 2 main parts: mandatory fixes, good to fix.
The mandatory fix is the unsecure use of SELECT FOR ALL ENTRIES. If this is not properly checked, it might blow up the system:
What happens here? If in the current database the SELECT FOR ALL ENTRIES for whatever reason is not giving results this might be running fine. But on HANA the entire table is read in this case. To scan the usage in live system, see below chapter on SRTCM.
The other part is the performance best practices for HANA:
This ATC run can yield a very long working list:
Where to start? Since even the priority 1 and 2 can yield a very long list.
Use the SQLM and SWLT tools. These tools will help you to prioritize the ATC run result from the PERFORMANCE_DB variant. SQLM will take statistics data from production. You start with the heavy used programs. SWLT will combine the heavy use with the ATC run. The output is the heavy used program which can be improved.
SRTCM tool
The SRTCM tool is specifically designed to scan for 2 main issues: Empty table in FOR ALL ENTRIES clause and Missing ORDER BY or SORT after SELECT. The tool is run on a productive system and will list the actual usage in a productive system.
To switch on start transaction SRTCM and press the Activate Globally button.
Let the tool run, and later Display Results from either running system or snapshot:
Show results;
Clicking on the line will jump to the direct code point.
SAP solution manager offers a custom code decommissioning cockpit tool. This tool you can use to delete unused custom code. Unused code does not need to be migrated, which will save you effort.
Clean ABAP is the ABAP variant of the clean code principles. All background on clean ABAP code can be read in this blog.
This blog will explain how to upload the ABAP coding for the Clean ABAP ATC variant in your system and activate it.
Load ABAP Git code
To load the ATC variant code for clean ABAP you first need to install the ABAP Git code. Follow the instructions in this blog to do so. Simplest is the offline variant.
Select the button Code and choose the option Download ZIP.
Upload the package
Now start the ABAP git that you loaded in your first step. Choose the option New Offline:
Give the repository a name and select a package:
Then push the button Create Offline Repo.
Now select Import Zip:
Import the file you downloaded in step 2 from the code pal site.
Next step is the Pull zip:
You might get a screen with differences. Do not select anything there, only press Ok.
Then wait until all the Y objects are pulled into the system. This might take 5 to 10 minutes.
Activating the SCI checks
Now start transaction SCI. Select menu option Code Inspector, Management of, Tests. Select all the newly load Y checks for Clean ABAP code:
Important now: Save them!
Now you can create a global SCI variant:
Select all the Clean code ABAP checks and save the variant:
You might get weird issues upon saving for other items, like for example missing CL_CI_CATEGORY_TOP. In that case, go to transaction SE16 -> look for table SCITESTS -> and look for CL_CI_CATEGORY_TOP if there is no entry. Enter the table SCITESTS and click "Create Entry", add CL_CI_CATEGORY_TOP entry and save.
Test and usage
Take a program you want check. Then select menu option Program, Check, ABAP Test Cockpit with….:
Select the ZCLEAN_ABAP SCI check we created above. Run the checks.
Results:
Tip: click on the blue line to jump to the Clean Code site exactly explaining about the issue.
Clean ABAP Eclipse plug-in: ABAP cleaner
To speed up clean ABAP in practice, you can install the clean ABAP cleaner plug-in. Read this blog on how to do this.
Custom code can use standard SAP code and SAP objects. Some of these objects might technically exist, but are in an unreleased status. This might mean SAP will not give support on them, or might remove them in a future upgrade.
Also when you want to move to the BTP ABAP cloud, you cannot use the unreleased code.
Questions that will be answered in this blog are:
How can I scan my custom code for use of unreleased standard SAP objects?
SCI and ATC are very powerful code scanning tools (see blog and blog). Unfortunately you cannot apply it to standard SAP and add-ons.
Analyzing standard SAP code is the responsibility of SAP, and they take good and secure code (since they provide good code, it is weird they don’t allow everybody to scan their code…). Unfortunately a lot of add-on providers do not.
The blog will explain how to scan code of standard SAP and mainly on add-ons.
Questions that will be answered are:
What is the background on not being able to scan standard SAP and add-on code?
Can I truly scan the code of a new OSS note 7 days?
How can I work around these restrictions and still scan the code of an add-on?
Background
The background of not being able to scan standard SAP code is explained in OSS note 1986391 – Using SLIN/SCI to check SAP standard objects. This note also explains you can scan OSS notes and transports for 7 days. After that time it is no longer possible. Unfortunately this rule also applies to add-ons.
Why run SCI on add-ons?
Why would you want to scan add-ons? Add-ons come with various quality levels. Ranging from very well written with much attention to performance and security. Some add-ons are full of performance issues and full of security leaks. Some are even allowing full dynamic read SELECT and UPDATE statement without any authorization check. This is heaven for a hacker!
The below method is meant for scanning these poor add-ons using the SCI tool for performance, robust coding and security.
When you run the SCI tool on an add-on by selecting package or development object, you get the message that it does not contain any objects:
This is because your selection is first scanned for standard SAP and add-on objects. These are removed. So the result set is empty.
Goto transaction SE24 and select class CL_CI_OBJECTSET. Now select method BUILD_TADIRSET and display the code:
Put a break-point as statement if ENABLE_CI ne ‘X’.
Now start the SCI tool again. If the debugger stops at this statement, use debug and replace to change the content of ENABLE_CI to ‘X’. Now the skipping of SAP and add-on objects is not done. SCI will scan the code. It will still not use SLIN. But these are minor checks.
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):
Component
External
Technical Name
Custom
code migration projects
SYCM_APS_C_PROJECT_CDS
Analysis
of SAP S/4HANA custom code check findings
SYCM_APS_C_ATC_FIND_ALP_CDS
Custom
code scoping by request entry points
SYCM_APS_C_SCP_BY_EP_CDS
Custom
code scoping by packages
SYCM_APS_C_SCP_BY_PK_CDS
In transaction SICF activate the following nodes:
NW_APS_CCM_PRJ
NW_APS_EXT_LIB
NW_APS_LIB
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 tick box:
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.
More important, you need to run the ATC a few times, after every main clean up round. 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.
Step 2 is to update the simplification content to version 1809. You have to download the content from SAP software site and upload it in your ATC 7.52 system. For this step follow the instructions from OSS note 2241080 – SAP S/4HANA: Content for checking customer specific code.
Short summary of these steps in this note: download the most up-to-date simplification database:
In the 7.52 central ATC system use tcode SYCM to upload this file.
Now you are good to go for the S4HANA 1809 readiness check for custom code.
For S4HANA 1909, S4HANA 2020 and S4HANA 2021 the notes have different numbers:
By using a Netweaver 7.52 server (or newer) you can use that server a central ATC server for running the ATC. For explanation on ATC itself, please check this blog.
Questions that will be answered in this blog are:
What are reasons for running remote ATC checks?
How to set up remote ATC checks?
Which limitations does remote ATC checks have?
Reasons for running remote ATC checks
There are several reasons why you might want to do this:
Run ATC against an old 7.00/7.01/7.02 system, where ATC is not delivered by SAP
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.
This looks like a simple action, but it is not. It will pull in dependent OSS notes. One of these notes is the key OSS note 2270689 – Remote Analysis (for source system). This note contains references to the notes to apply.
Notes referred to in note 2270689 can be HUGE OSS notes. It can take 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:
Important here:
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.
End result
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:
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.
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.
