Technical Articles
Configuration for ATC / Code Inspector check before releasing transport request
Overview:
Many of us would like to have the functionality of executing ATC / Code Inspector checks before releasing the transport request / task. In addition, some of us might have gone through the below blogs to achieve this requirement.
Both the blogs given above provide us with custom solution to perform this task.
Good news is SAP has provided this functionality via SAP Note: “2495410 – Object checks during task release. “
Problem:
Once we implement this note, the common question / issue that we have is to know the check variant name that executes upon release of the TR. Moreover, most of us would like to configure or control this check variant.
One more thing that we would like to control is to perform check on either task level or request level.
Solution:
We will go through each problem one by one and try to provide solution for the questions.
1) Control to perform check on either task level or request level.
Post implementation of note: 2495410, an additional option is available in Global customizing (Transport Organizer). Here we can select to perform check on Request / Task / Task and Request.
To access this setting, go to tcode SE03 and under “Administration” folder click on “Global Customizing (Transport Organizer)”
2) Configure ATC execution on release of TR.
Post implementation of object check note, Code inspector executes upon release of TR. However, we wish to execute ATC along with code inspector.
This check is configurable via tcode ATC ( Table: TRCHECK contains detail for all the checks present in system).
Open tcode ATC and under folder “Setup”, click on “Configure ATC”.
Refer to link for more details
After this configuration, both ATC and Code inspector will be checked upon release of TR.
3) Configuring check variants to execute upon release of transport request.
As per note: 1465965, ATC has default check variant as “DEFAULT” and code inspector default check variant is “TRANSPORT” for releasing TR.
Table: SCICHKV_ALTER replaces the default check variants provided by SAP.
Table: SCICHKV_ALTER is delivered by note: 1465965.
Maintain this table with the above entries and you can control the check variant that should be executed upon release of TR.
Note: Entries maintained in table will always replace the check variants as given in the table.
Even on manual execution of ATC and Code Inspector this check will be replaced.
Conclusion:
Better to check error before you release transport request.
Hope this is helpful, let me know your view and suggestion in the comments below.
Thanks for sharing, Rameez!
I'm however not sure if using SM30 to directly edit table TRCHECK is advisable - when I try, I get the warning message "Do not make any changes (SAP data)". Furthermore, this isn't even necessary as you can make the change in transaction ATC where you have a dropdown to select the behaviour you want:
In addition, either the ATC- or the Code Inspector checks should be executed upon task or transport release but not both (I'm fairly certain that I read that somewhere but can't find it now - but, as the checks done are the same, it doesn't make much sense to run them twice anyway).
As an aside: are you aware of Olga Dolinskaja's series about using a central ATC-system and checks?
Cheers
Baerbel
Thank You Bärbel Winkler for giving feedback. Yes you are correct, update table TRCHECK with SM30 is not the correct approach. I'll update adapt the changes in the blog.
https://help.sap.com/viewer/ba879a6e2ea04d9bb94c7ccd7cdac446/7.51.4/en-US/40c14df0a883467bb90ef5a70cee7cc2.html
I've debugged FM: TR_RELEASE_REQUEST to understand the behavior, here are my findings.
So you are correct, check should be activated only for task or request level. Otherwise we end up checking same object twice.
I would prefer to activate check on task level because once task is released and request reports error then we have to create one more task for corrections of the reported errors.
Thanks
Rameez Khan
Thanks for updating your blog post, Rameez!
One clarification however: my comment regarding that only one check should be done applies to running either the ATC- or the Code Inspector checks. Both make use of the same check-variant definition so the executed checks are the same, but the way they get displayed is different. And, SCI-checks are not stored whereas ATC-checks are kept for a certain amount of time and can be looked at again.
Your comment regarding running checks either on task- or transport-release is nonetheless valid. When we recently activated ATC-checks via a central system, we at first did the checks for both but that really just doubled the effort and result list. So we quickly switched to just "upon task release".
Thanks for the clearification..
I would just like to correct one point, when the TR is released, different check variants is executed for both ATC and Code Inspector.
I don’t have my system right now but the FM: TR_RELEASE_REQUEST has a subroutine with name “execute_check” ( Something similar, I am not able to recollect subroutine name ) where after the select on TRCHECK table there is a loop within which for CASE = SLIN an method is called to execute Code Inspector where check variant TRANSPORT is hard coded.
Hence in point 3, I have mentioned SAP note: 1465965 which gives option to customize and replace the TRANSPORT check variant.
But yes I agree with you, rather than executing both ATC and code inspector we should activate only one of them with only one check variant.
hi Rameez,
Is there a way that we can trigger the ATC checks when a developer clicks on the 'syntax check' ‘Activate’ in the editor?
Thank You.
Joe.
Hello Joe,
As far my understanding goes there is no way to perform ATC on "syntax check". And honestly I would love to keep it that way 🙂 . Syntax check is performed on activation of code also and it will leave developers frustrated if ATC is executed on activation of every piece of code.
Cheers
Rameez
Thanks Rameez. I came across this blog where we get the functionality, using an Eclipse plugin.
https://blogs.sap.com/2018/08/20/abap-continuous-integration-plugin-now-with-plug-and-play/
Cool.!! Thanks for sharing.
Hi Rameez,
Thanks for sharing this blog. Is there a way to differentiate old and new code in the system?
We have a bunch of legacy code which would definitely fail a lot of the checks, so we'd like apply a more relaxed check variant.
On the other hand we'd like to apply a much stricter variant to newly created code.
Any ideas would be much appreciated.
Hi Michael,
depending on your NW-version you might be able to work with the baseline concept described in Olga Dolinskaja's blog post:
Remote Code Analysis in ATC – Working with Baseline to suppress findings in old legacy code
We actually had to wait until we had a central ATC-system up and running before we could make the switch to preventing transport-release when priority 1 & 2 findings were encountered. I've written a blog series about our process and here is the link to the summary post.
Hope this helps!
Cheers
Bärbel
Hello Michael,
Like Barbel said, you can refer to Olga’s blog to suppress findings of old legacy code in the system.
The catch is your NW version.
However if there is any object that is bothering you, then you can work with exemptions too.
An ATC exemption deactivates an ATC findings.
Check here for more details.
Olga's blog for Working with exemptions.
Hope this helps.
Rameez Khan
Thank you for details on ATC settings Rameez. Is there a way to trigger ATC for implcit enhancement points?