Setting up a central ATC-system: Part 6 – accumulated FAQs
Since going live with our central ATC-system in October 2018 (for a summary, please see the existing articles in this series) I’ve kept updating our list of internal FAQs to have one place for our developers to hopefully find answers to questions they might have about the ABAP Test Cockpit. A recent comment on one of my blog posts by Nicolaas Jacobus van Schalkwyk made me wonder if our FAQs might perhaps be of interest for others, so here they are, slightly modified for publication.
What do the acronyms ATC and SCI stand for?
Short answer: ATC = ABAP Testcockpit and SCI = SAP Code Inspector
- Both tools can be used to check ABAP code for problematic content and the ATC makes use of the underpinnings provided by the SCI like for example the check variants.
What is a check variant?
Short answer: A check-variant defines the checks to be run on ABAP code.
- Global checks are defined by ATC admins and everybody can define check variants for her/his own user. They can contain various types of checks to ensure that ABAP code adheres to the defined standards and doesn’t contain problematic and/or unwanted code.
Why do we have a central ATC system?
There are several reasons for a central ATC-system:
- It avoids duplication of effort both with initial customizing and ongoing maintenance
- Available ATC-checks depend on SAP-release of the development system
- S/4HANA readiness checks are not yet available in our development systems
- The baseline concept makes it possible to only check new code and thereby avoid long lists of findings
- Enhancement can be checked
- Checks are possible on task-release and not only on transport-release
- For more information about a central ATC-system, please check Olga Dolinskaja’s blog post in SAP Community: Remote Code Analysis in ATC – One central check system for multiple systems on various releases
Do I ever need to login to the central ATC system?
Short answer: No. But, your user needs to be known in the ATC system.
- The connection between the central ATC system and the satellite systems is established via trusted-RFC. Because of this, your user needs to be known in the central ATC system and needs to have relevant authorisations in all systems.
- Should you run into issues which seem to be authorisation related please capture the content of SU53 and send it to the helpdesk mentioning ATC (or ABAP Testcockpit) in the subjectline.
Which check-variant can I use before releasing my transport?
Short answer: So far CENTRAL_TRANSPORT_RELEASE has been defined.
- This check-variant will be used once you release your task/transport
- It is also defined as the default check-variant and will be used whenever an ATC-check is run (unless you specifically select another variant via “ATC with ….”)
- More centrally defined check-variants will be made available for other scenarios (like for example checking for S/4HANA readiness)
Which checks are included in the central check variant?
Short answer: quite a few!
- Many of the checks already used in the Default check variant have been included.
- Performance checks
- Analysis of WHERE Condition for SELECT
- Analysis of WHERE Condition in UPDATE and DELETE
- Search problematic SELECT * statements
- Search SELECT .. FOR ALL ENTRIES-clauses to be transformed
- Search SELECT statement with DELETE statement
- Search DB Operations in loops across modularization units
- EXIT or no statement in SELECT…ENDSELECT loop
- Instance Creation of BAdIs
- Security Checks
- Critical Statements
- Dynamic and Client-Specific Accesses with INSERT, UPDATE, MODIFY, DELETE (Note: these will be flagged even for pre-existing code!)
- Robust Programming
- Search problematic statements for result of SELECT/OPEN CURSOR without ORDER BY
- Unsecure use of FOR ALL ENTRIES
What is meant by “baseline”?
Short answer: The “baseline” includes check-results for existing code.
- In mid-August 2018 checks were run for all ABAP-objects in Z-packages in the development systems at that time
- The results of these runs were added to the baseline
- If programs are checked again later – perhaps due to additional changes – any findings already in the baseline will no longer be shown in the results
- For more information about the baseline concept, check out Olga Dolinsakaja’s blog post in the SAP Community: Remote Code Analysis in ATC – Working with Baseline to suppress findings in old legacy code
Is the extended syntax check (SLIN) included in the central ATC-checks?
Short answer: Not at the moment
- We looked into this but only after the baseline results had already been defined for the development systems. Because they are therefore not included in the baseline, they could make the result lists fairly large with findings for old code not touched by the latest changes.
- In addition, there seem to be checks in SLIN for which the message priority cannot be tweaked. This could result in blocking the release of impacted transport once blocking has been activated.
- Should the baselines be recreated at a later point in time, we may then include the SLIN-checks and will then also add them to the central ATC-checks.
- Recommendation: make it a habit to execute the extended syntax check (SLIN) before releasing the transport and fix any reported issues.
How to avoid surprises during task/transport release?
Short answer: do not wait with the ATC-checks until task-release
- Make it a habit to execute the ATC-checks via check variant CENTRAL_TRANSPORT_RELEASE throughout your development to catch problematic findings early on
- Also execute the extended syntax-check (SLIN) to catch things like missing text-elements
- Whenever possible eliminate findings by updating the impacted code
- Only when this is not feasible make use of a pseudo comment or request an exemption
Why can I no longer ignore some errors and warnings upon transport-release?
Short answer: Some ABAP-code can have negative impact on the system
- When we moved to HANA-DB in November 2017 it was already announced that we will eventually move to preventing the release of transports if they are considered a potential risk
- Apart from only looking at HANA-DB specific issues, we also added some checks for generally considered critical code like hard updates to SAP tables
- Only priority 1 and 2 findings will prevent the release of a task/transport
- Priority 3 findings are provided as information only – it can be worthwhile to check them to improve your code
Why is a statement reported even though it shows a pseudo-comment for code inspector?
Short answer: The pseudo-comment may not be placed correctly
- It seems that some pseudo-comments were put below the impacted statement (e.g. in the line below the period) instead of next to it.
- SAP-Help explains where a pseudo-comment needs to be placed to be recognized.
- If you get priority 1 messages for statements with such a misplaced pseudo-comments and if you are actually changing the object, please move the comment into a line already used by the statement instead of requesting an exemption!
Why are there findings for code I didn’t touch?
Short answer: Some checks were not included in the baseline on purpose
- Direct updates to SAP-tables – these have always been problematic and should have been avoided. If a direct update cannot be easily corrected, request an exemption for it stating the reason why there is no other option. That way, we’ll at least build up some documentation for these cases.
Why do some SELECT-statements using FOR ALL ENTRIES prevent the release of my transport?
Short answer: due to some issues in production caused by FOR ALL ENTRIES being used without checking if the referenced internal table contains any entries, this check’s priority was changed from “3” (information) to “2” (warning).
- To avoid this finding, please add a check in your code to ensure that the internal table contains at least 1 item before the SELECT is executed.
- Alternatively – and if you know for certain that there’ll always be items in the itab – you can add “#EC CI_FAE_LINES_ENSURED in one of the lines of the SELECT-statement to document that you verified this.
Do we already have checks active relevant for S/4HANA?
Short answer: as of right now (November 12, 2019) the answer is “No”. This will however change sometime in the future when we’ll start to add S/4HANA relevant checks to the default check variant used during transport release.
- At least some of these additional checks will then prevent the release of transports in order to avoid making identified issues worse.
- The check will apply to both new and existing code.
Is there additional information available for the displayed list of findings?
Short answer: Yes, more information can be displayed
- By clicking the “+-icon” you can get some more information displayed
- The include name, line of code and username for last change then get added to the output
What do I do when I cannot release a task?
Short answer: The best option is to correct the code mentioned in the finding
- Try to correct the impacted code to no longer get the finding
- Check the message which goes along with the finding. If it mentions an escape-command (“#EC CI_ ….”) you can add that to the statement. Please also add a short “why comment”.
- You can also request an exemption for the finding. If granted by the ATC Approver(s), you will be able to then release your task/transport
- For more information about the exemption process, please check out Olga Dolinskaja’s blog post in the SAP Community: Remote Code Analysis in ATC – Working with Exemptions
What should the exemption be requested for?
Short answer: usually the specific finding
- Default is what the F1-help suggests: Always limit the scope of your exemptions as much as you can (finding + message)
- Exemption requests casting too wide a net will be rejected by the approver(s)!
Who do I pick as the Approver of an exemption request?
Short answer: ATC_APPROVER
- Even though there may be a choice of names as an approver of your exemption, always select user ATC_Approver from the drop down list
- Selecting ATC_Approver will ensure that the notification about a new exemption request will go out immediately to a distribution list and not just a specific person who may or may not be in the office
Where can I learn more about ATC checks via a central system?
Short Answer: in Olga Dolinskaja’s blog posts in the the SAP Community
- Remote Code Analysis in ATC – One central check system for multiple systems on various releases
- Remote Code Analysis in ATC – Technical Setup step by step
- Remote Code Analysis in ATC – Working with Baseline to suppress findings in old legacy code
- Remote Code Analysis in ATC for Developers
- Remote Code Analysis in ATC – Working with Exemptions
- Remote Code Analysis in ATC – Scanning customer extensions
- Remote Code Analysis in ATC – Working efficiently with ATC Result List
- Remote Code Analysis in ATC – FAQ
And if you are interested in how we went about setting this up, these articles contain the (hi)story:
- Setting up a central ATC-system – the long, long winding road edition
- Setting up a central ATC-system – Part 1: Setting the stage
- Setting up a central ATC-system – Part 2: Preparing the systems
- Setting up a central ATC-system – Part 3: Tweaking the settings to our liking
- Setting up a central ATC-system – Part 4: The final stretch
- Setting up a central ATC-system – Part 5: Keeping an eye on things (January 2019)
Is there a list for open issues?
Short answer: Yes, sort of
- We are aware that the ATC-related notification emails could contain more information, like for example the reason given by the ATC-approver in case an exemption is rejected. A question regarding this has been created in the SAP Community but it may take time to get a solution.
Is there a risk that transports only containing translations get blocked when one of the impacted underlying objects shows priority 1 or 2 findings?
Short answer: No
- We thought that this risk existed but luckily were proven wrong once we went live with “blocking on error”.
- The SAP community question related to this in SAP-community contains the details and what we found once we tested this (namely that it works!)
Why do I get a tool failure error with priority 1 and cannot release my transport?
Option #1: possibly your SAP-user is not yet known or its validity has expired in the central ATC-system
- Check the error message you get for the tool failure and open the nodes to see the details. It’ll show the actual error as the last information.
- If there’s no helpful information, please ask a colleague who has developer access to the system and who doesn’t have this issue when handling ATC-checks, to run the check (or release the transport) for you.
- If it works for your colleague, please let us know
- If this doesn’t work either, please create a ticket for the helpdesk, mentioning “ATC-check issue” in the title, providing the error-message in the description and ask the helpdesk to send it to the SAP development team
Option #2: You tried to check a program or release a transport sometime over the weekend
- The check system is suspended over the weekend and cannot be accessed.
- Should there be issues outside the weekend, please let us know.
Hope these help! Please share suggestions for additional questions & answers in the comments!