Technical Articles
Remote Code Analysis in ATC – One central check system for multiple systems on various releases
This is the first blog of the blog series about Remote Code Analysis in ABAP Test Cockpit (ATC).
See also blogs:
ATC Introduction
For those of you, who are using Code Inspector (SCI) and are not familiar with ABAP Test Cockpit (ATC) yet, it is SAP’s central quality assurance infrastructure for static functional, performance and security code checks, which bundles together the well-known and widely used quality tools like syntax check, SLIN, ABAP Unit, security checks and is extensible for your custom checks. ATC reuses Code Inspector checks and significantly improves the code quality by offering the uniform quality criteria for the whole development landscape and establishing new quality assurance processes (quality gates, exemptions, mass regression tests) to minimize errors in productive systems. Beyond this ATC is the toolset of choice to achieve the smooth migration of ABAP code to SAP HANA and SAP S/4HANA by means of special SAP HANA and SAP S/4HANA checks.
A very good general overview about ATC is in the blog ABAP Test Cockpit – an Introduction to SAP’s new ABAP Quality Assurance Tool. ATC is also integrated in the ABAP Development Tools in Eclipse (ABAP Test Cockpit for Developers in Eclipse).
Limitations
Imagine you have older systems (SAP_BASIS >= 7.00) with your own custom code base and would like to execute the latest security checks and SAP S/4HANA readiness checks for your custom code in order to get compliant to the increased corporate security requirements and prepare your code for the SAP S/4HANA migration.
One problem is, the ATC is only available with SAP_BASIS 7.02 therefore it isn’t present in your older systems at all. Another problem is, to apply uniform quality criteria for all your systems, the same checks must be in every system you want to check, that is not the case in heterogeneous landscapes with SAP_BASIS 7.02, 7.40, 750 and so on: every release has different checks. Besides this, the security checks are only available for SAP_BASIS 7.02 and the newest checks, e.g. for SAP S/4HANA readiness are only available with the SAP NetWeaver AS for ABAP 7.51 innovation package. Therefore it looks like you cannot apply the checks at all.
In fact, the way to tackle this problem is not easy: you need to upgrade the whole system landscape to the latest SAP release and support package level and run ATC with the latest checks on each upgraded system. It means on the one side a big administration overhead, on the other side the upgrade might neither be intended currently at your company nor possible at all. As a consequence, the compliance with the increased corporate security requirements cannot be verified and your custom code cannot be prepared for the SAP S/4HANA.
Solution – Remote Code Analysis in ATC
So, how to apply the newest checks to all your systems in SAP landscape without having to upgrade each of them?
Starting with the SAP NetWeaver AS ABAP 7.51 innovation package SAP customers and partners can perform remote code analysis in ATC which allows to analyze remotely with the latest checks custom code even in older systems using only one system for ATC (SAP_BASIS >= 7.51).
You would need to set up one centralized SAP NetWeaver AS ABAP 7.51 or 7.52 (SAP_BASIS only) system as ATC check system and run ATC with the latest checks centrally in one system checking multiple systems in your landscape. You don’t need to upgrade your whole system landscape and can apply the latest checks.
For the problematic use case from above it means, by setting up one central ATC check system using remote code analysis, you can apply the latest security checks and SAP S/4HANA readiness checks for your whole system landscape.
Setup
All you need to do is to install and configure one ATC central check system: pure SAP Basis System (SAP_BASIS >=7.51) within your SAP system landscape. ATC check variant is maintained only in the ATC central check system and must be RFC-enabled.
During ATC execution the central check system accesses remotely the systems in your landscape through so-called Remote stubs using RFC connection. Remote stubs serve as interface between ATC central check system and checked systems and return a model from custom code which needs to be checked.
See the blog Remote Code Analysis in ATC – Technical Setup Step by Step for more details.
PLEASE NOTE: not all central ATC checks can be run against all releases in your system landscape. As an example, ATC checks for ABAP CDS don’t make sense on older releases. You have to check carefully whether the checks used will work against the release.
Advantages
The advantages of using ATC remote code analysis are obvious:
- Small impact on existing system landscape: no upgrade to the latest SAP release necessary
- The central check system can be installed independently with low effort (no upgrade, no test for business processes)
- One ATC central system can be used to check multiple SAP systems
- Latest checks can be applied by upgrading the central check system only.
- One quality standard for the whole system landscape possible, independent of uses releases in the development systems
- All new checks will be implemented by SAP only in new releases
- Administrative tasks only in the central system, e.g. maintain check variant
- Centralized handling of exemptions
- Baseline concept in case you want to suppress the findings from old legacy code
Hi Olga,
We are planning to setup Central ATC system and checking on sizing part. We will be connecting around 50 systems to central ATC system. Would you be able to guide us on the size of the systems in terms of memory /CPU/Apps needed to set this up.
Regards
Hi Kavita,
the sizing recommendation for the central ATC check system is provided in the blog https://blogs.sap.com/2016/12/13/remote-code-analysis-in-atc-technical-setup-step-by-step/ in the chapter "Technical Requirements". The sizing of the checked systems is irrelevant for remote scans with ATC.
Kind Regards,
Olga.
Thanks Olga!
Hello Olga
We have procured a Central Check system and set up ATC and CVA checks to run through it. The functionality works well when our Managed systems is S/4 HANA. There are few tool failures but that we had overcome after implementing relevant notes.
However, the behaviour is completely different when our Managed system is Netweaver (SAP_Basis 750 SP19 or less). Most of the checks configured over Central check variant are not usable. We observe an error that a particular check is not a "Psuedo enabled check". For example - we had enabled below checks for our ECC system (SAP Basis 750 SP19) on Central check system.
But when connected with ECC box - we receive an error that below checks are not Pseudo enabled.
============================================================================
1. Abap Dictionary Checks --> References to generated SQL views of CDS View in ABAP development objects
2. Abap Dictionary Checks --> References to generated SQL views of CDS View in dictionary objects
3. Security Checks --> DDIC: DB Tables (Logging Check)
4. General Checks --> BAPI Consistency Check
5. Core Data Services (CDS) --> Syntax Check/Generation --> Complexity of CDS Views
6. Core Data Services (CDS) --> Syntax Check/Generation --> Syntax Check for DCL Sources
7. Core Data Services (CDS) --> Syntax Check/Generation --> Status Check for DCL Sources
8. Core Data Services (CDS) --> Syntax Check/Generation --> CDS Access Control Attributes of CDS Views
9. Abap Dictionary Checks --> DDIC/CDS: Check Activation
10. Abap Dictionary Checks --> DDIC/CDS: Check for partly active object
11. Core Data Services (CDS) --> General Checks --> Annotation Check for Data Definations
12. Core Data Services (CDS) --> General Checks --> Referenced objects in CDS
13. Core Data Services (CDS) --> Syntax Check/Generation --> Syntax Check for CDS Metadata Extensions
14. Proxy Checks --> Proxy Checks
15. Core Data Services (CDS) --> General Checks --> SADL Runtime Checks
16. User Interfaces --> Analyse 'SAP Scripts' Documents
17. Dynamic Test --> ABAP Unit
18. User Interfaces --> Web Dynpro Component - Conventions
============================================================================
As you see, we have ended up removing a lot of checks that are required but since its not supported, the project teams shy away from using Central check system for their ATC and CVA runs.
Isn't this over shadowing the benefit of Central check system and not upgrading the Managed system to latest release?
Regards
Anuj
Hi Anuj,
thank you very much for your detailed description and feedback. We have already recognized that while assigning checks to a check variant, customers don't have information whether the checks assigned to the variant will be compatible with a specific release in a checked system, and the compatibility of checks can currently only be verified by defining a new run series, what is too late. This issue is already in our development backlog.
Thank you again.
Kind Regards,
Olga.
Hi Olga
Thank you for your response. Indeed, that would be great to know before hand whether a check is compatible or not when this functionality is made available.
My concern is more around the benefits a Central check system shall provide to run the checks that are not available because of lower available release on Managed system. However, we don't seem to be enjoying that benefit because ir-respective a check is configured locally or centrally, we won't be able to run those checks.
Regards
Anuj
Hi Olga,
I have question around ATC authorization. As per the ATC security guide the RFC users needs to be Dialog users. We have a concern from Security team that these users needs to be reset every 90 days as per the Security Policy for Dialog users. As we have 50+ Dev systems where we want to use ATC, we will have to get the Ids reset every 90 days and update the config.
Do you have any recommendation on this concern ?
Regards
Kavita
Hi Kavita,
ATC using a reference check system needs to be set up with a dialog user in order to be able to request exemptions. The exemption dialog which is displayed, comes from the central check system.
Regarding security risks, I would recommend to set up the role so that debugging is not possible. In the past, there have been some security gaps when the caller was able to debug user interfaces remotely. Today, it should not be possible any more to leave the session but it is better to protect this by removing the authorization for S_DEVELOP DEBUG.
When using ABAP Developer Tools, you don't need a UI user. This could also be an option.
Best Regards,
Axel
Kavita Mane
Hi Kavita,
we set this up via trusted RFC-connections. That way, the developers are defined as "Dialog Users" but have "password deactivated". So they cannot and don't need to login to the system. They also basically just have the roles needed for the trusted RFC access and what is needed to request exemptions.
As long as we don't forget to add new developers in the central ATC-system this arrangement works very well.
Cheers
Bärbel
Thanks Olga for your response,
Do you meam we can setup trusted RFC with communcation user(non-diolag) and it will work?.
Regards
Kavita
Olga?
Hi Kavita,
this is how a typical user is set up in our central ATC-system:
Because the password is deactivated it doesn't matter that the user type is "Dialog". The user will not be able to login and a password is not needed.
Hope this helps!
Cheers
Bärbel
Team, Is there any possibility we could block just Priority 1 instead of both ( Priority 1 and 2) on a Netweaver system?
All S/4 HANA has this possibility but we are looking the same behaviour on NW too.
Priority
Hello Barbel,
I am unable to change global check variant in ATC for Basis version 755. Below warning comes when trying to save the config and it again takes the default variant. Could you assist on this issue.
Regards
Kavita
Hi Kavita,
I don't think that you need to update the setting in the central ATC system. It still shows "DEFAULT" in our system. I set up dedicated check variants in the central system which are then used as remote check variants from the satellite systems. We don't have any objects in the central system which might need to be checked, so the setting for the default variant in the central system doesn't much matter.
Hope this helps
Cheers
Bärbel
Hello Barbel,
Thanks or yor response, we want to do local ATC check in some of the satellite systems which are on Basis 755 and we want to set the custome variant while we run local ATC. Not sure why I am unable to change the settings, is there anywhere else global variant is set apart from tcode ATC ?
Regards
Kavita
Kavita Mane
Hi Kavita,
just to clarify: you want to do local ATC checks in a 7.55 satellite system?
You can simply set those up as additional check variants either in SCI or ATC in that system and then use the "run with" option to pick that check variant instead of using whatever you have defined as the default variant, which presumably is set up to do the checks in the central system. You can also define local ATC-checks using these check variants defined in the system.
For each system, you can only have one global check variant defined - this can then either be a locally defined check variant or point at a variant in the central system. Which is why you get the warning message to avoid accidental overwrites.
Does that help?
Cheers
Bärbel
Yes Barbel, we have few systems in our landscape which are on Basis version 755 and we want to setup local ATC as our central ATC system is on Basis 7.52.
We can certainly use the option "run with" and choose the variant , however I was looking to set global variant so that ABAP team can directly run ATC with default custom variant. We have updated the global variant in our Central ATC and other satellite systems but unable to change in systems which are on Basis 755 version so was looking for some assistance there.
Thanks and Regards
Kavita
Bärbel Winkler --Could you please assist me on above query.
Thanks and Regards
Kavita Mane
Kavita Mane
Hi Kavita,
there isn't much I can help with - you will have to set up different and properly named check variants one for local and the other for central execution. User will have to decide which one to use as you can only have one check variant called DEFAULT in a system. Also, a satellite system can only have one connection to a central check system, there is no option to have two.
Cheers
Bärbel
Thanks Barbel for your response.
Do you mean for Basis version 7.55, local variant will always be Default and we can not change it in the settings.
Regards
Kavita
I don't really understand what problem you are having. And because I don't have a 7.55 system available I cannot check it myself.
The message you get is just a warning because the change will take immediate effect within the system. You can still proceed to see what happens and if you do it at a time when not many users will be running ATC-checks, nobody will be impacted. If you don't like the result/effect, just switch it back to what it was before.
Cheers
Bärbel
Hello Barbel,
Sorry if some confusion with the issue details. Below are steps that i follow.
Step1: Change the global variant to Z_ABAP_ATC.
Step 2: Save
Step 3 : come out of transaction ATC and again open ATC tcode, global variant again go back to original.
You should be able to get over the warning with simply hitting Enter once or twice and then save. At least that's how it usually works.
Hello Barbel,
I tried but its still not working. Looks like it is picking the value from below tabs.
Kavita Mane
Hi Kavita,
the check variant displayed in your last screenshot is fairly random, it doesn't have a bearing on which variant you want to pick elsewhere. Just make sure that you saved the variant as "global" and not a local check variant. You can tell the difference via the icon:
If you keep having issues, it might be better to open a ticket with SAP support.
Cheers
Bärbel
Thank Barbel for your response. I will check and raise the case to SAP if needed.
Hi Olga,
We are doing customer assessment but as customer in SAP_BASIS 701 where ATC transaction not available and we can't do the remote code analysis also. SO, please provide me the solution how could we run ATC with variants FUNCTIONAL_DB, PERFORMANCE_DB and S4HANA_READINESS_REMOTE to check SOH and S4H violation.
Thanks,
Soumen Sasmal
HCLTech.
Hi Soumen,
you can check your SAP_BASIS 7.01 system using remote ATC if you set up the central ATC system as described in the https://blogs.sap.com/2016/12/13/remote-code-analysis-in-atc-technical-setup-step-by-step/ blog. The S4HANA_READINESS_REMOTE check variant is sufficient to detect in the custom code of your systems the SAP S/4HANA and SAP HANA related issues.
Kind Regards,
Olga.
Hi Olga,
Thanks for your information. In our customer they do not have any system where we can run remote ATC check. So, could you please let us know how we could find SAP S/4HANA and SAP HANA related issues with SAP BASIS 7.01.
Thanks,
Soumen Sasmal
HCLTech.
Hi Soumen,
if your customer has a SAP NetWeaver 7.50 system, there is also the old approach based on SAP_BASIS 7.50 using Custom Code Migration Worklist, which we actually don't recommend anymore (see also the https://blogs.sap.com/2019/06/25/custom-code-adaptation-for-sap-s4hana-faq/#_Toc470164251 Maybe it could help in this case.
The recommendation is still to set up a central ATC check system (or better Custom Code Migration app in SAP BTP ABAP environment) or consider using our SAP support services, which can execute S/4HANA readiness check for the customer.
Kind Regards,
Olga.
Hi Olga,
Thanks for your confirmation.
I need one more clarity on S4HANA_READINESS_REMOTE ATC variant and Simplification DB results (SYCM), In case in customer system we can run S4HANA_READINESS_REMOTE then also do we really need to run Simplification DB(SYCM) also, please confirm.
Thanks,
Soumen Sasmal
HCLTech
Hi Soumen,
if you have the central ATC system to execute the remote ATC scan with the S4HANA_READINESS_REMOTE check variant, then you don't need to run SYCM, the SYCM was the old approach (see my previous reply).
Kind Regards,
Olga.