The SAP NetWeaver ABAP Test Cockpit (ATC) enables the control of the quality of the ABAP portfolio so that it is secure, safe, and compliant with SAP best practices. The intent is to ensure the safety of the production system from any unseen downtime or performance issues due to custom programs. ATC is an SAP NetWeaver feature available from enhancement package 2 for SAP NetWeaver 7.0 with Support Package Stack 12.
This is part 3 of my three-article series on ATC. Part 1 covers details of the ATC setup, usage scenarios, and insight from my experiences. Part 2 covers customization of an ATC check variant and its transport, ATC reporting, and the feature of mass deletion for ATC results. In this part, I explain the transport-block and exemption-workflow features in depth.
Automatic Transport-Block Scenario
In ATC, you can automatically block a transport request if it contains a program with ATC errors. To do so, follow the steps outlined in the next section.
1. In the development system, go to transaction code ATC by using admin access. Click Setup > Configure ATC and go into change mode by clicking the edit (pencil) icon, which takes you to Figure 1. After this setup, ATC checks transports moving out of the development system.
Transport-block setup option
2. In the ATC setup screen in Figure 1 there is an option to block the transport requests. These transports are the ones that have ABAP objects with ATC errors in them. To proceed, go to the Behavior on Release drop-down menu shown in the Transport Tool Integration section in Figure 1. Select the Block on any error (priority 1 and 2) drop-down option. This means the release of a transport request is blocked from transporting objects that have priority 1 or 2 ATC errors.
When the transport-block option is selected as shown in Figure 1, in the next drop-down select the option Code Inspector Behavior on Release with the value Disable “Code Inspector” as test driver, as shown in Figure 2. This is the preferred combination of values for the transport-block scenario.
Transport-block option with the Code Inspector setting
3. An additional setting is required in the global transport settings of the system to implement the transport-block scenario in the ATC setup. For that, go to transaction code SE03. Follow menu path Transport Organizer Tools > Administration > Global Customizing (Transport Organizer). That takes you to Figure 3.
Setting for checking options on transport release
4. Select the Globally Activated radio button under the Check Objects when Request Released section as shown in Figure 3. Click the save icon to save this setting. This is a mandatory setting for the ATC transport-block scenario to work.
(Note: The ATC automatic transport-block scenario works well even in the case of a project setup when Change Request Management [ChaRM] is active. In this case, ChaRM must have been implemented via Solution Manager for those managed systems to have this ATC transport-block scenario active. However, the ATC transport block doesn’t work for the transport of copies. A large-scale implementation project, which generally uses transports of copies, is not able to leverage the automatic or manual blocking options for transporting copies. ATC functionality is available only for transport requests.)
5. Now you can test the transport-block scenario. To do so, in the development system go to transaction code SE09 as shown in Figure 4. Give the user name for the user-specific transport check. Select the appropriate Request Type check box(es) (e.g., in this case, Customizing Requests and Workbench Requests). Click the Display button.
Transaction code SE09 for transports
6. For the given user, the transport requests are shown on the next screen in Figure 5. Select the transport request that requires release. First release its task by clicking the release directly truck icon. Then select the transport of this task and click the release directly truck icon as shown in Figure 5.
7. A pop-up appears for the objects of the requests that have ATC run issues, as shown in Figure 6. This pop-up shows that objects have errors and hence the transport can’t be released. Click the Display button to see the error details.
ATC transport block pop-up with error
8. The error summary table opens as shown in Figure 7. Click the continue icon to continue.
ATC errors in transport objects
9. As there are errors, the transport is not released. The system allows release once all the objects under the transport are rectified either by ABAP code changes or by pseudo-comments.
See the section “Applicability of the Automatic ATC Transport-Block Scenario” at the end of this article for scenarios showing the applicability of a transport-block scenario in different kinds of SAP projects.
Manual Transport-Block Scenario
In the case of a manual transport-block scenario, no additional setting is required in the development system. It works based on the local setup of basic ATC configuration. It is mentioned in detail in “Local Setup in the Development System” in part 1 of this article series.
10. To perform a manual transport-block scenario, execute step 5. In the next screen, select the transport task that requires an ATC check. Click the Check Objects button as shown in Figure 8.
Manual ATC check on transport objects
11. An ATC check is performed on the objects of the transport request and the results are shown in the pop-up in Figure 9. As there are ATC errors reported, the technical lead or quality lead can opt to stop the release of the transport request. In this case, this blocking of the transport request is manual and it is up to the technical lead or quality lead to either hold or allow the transport release.
ATC results screen
There is a provision for approval workflow in ATC features. This workflow is for ATC errors exemptions by technical leads or managers. There can be genuine reasons why ATC errors in the programs cannot be removed. In such cases, program rectification or use of pseudo-comments for ATC errors may not be required.
In such situations, the program quality team can either allow the manual ignoring of such errors during manual review of the ATC errors or these errors can be ignored via the system using exemption workflows.
In this workflow, once an ATC error is approved by the predefined approver, then the ATC run is scheduled for those programs. In this case, those approved errors don’t appear in the error list. On the contrary, if an ATC error is rejected by an approver then that error continues to be part of the ATC errors’ list.
To enable the exemption workflow in the system (either for local development system errors or for central quality or test system errors), enable the exemption option in the ATC setup. Select the appropriate ATC results to be used in the exemption workflow (either local or central). For this, follow menu path ATC transaction > Configure ATC option. These settings are present under the Exemption section. For the central results exemption workflow, information about the master system (system ID and Remote Function Call [RFC]) are mandatory in this setup. Details of these steps are explained in part 1 of this series.
12. Once the prerequisite steps are done, then you can maintain the list of approvers in the ATC setup. This article discusses workflow specific to local results (the development system). In the development system, go to transaction code ATC using admin access. Click the Maintain Approvers node under Exemptions.
13. That takes you to a pop-up for maintaining a list of approvers as shown in Figure 10. Press search help (F4) in the Approver column on a new line.
List of approvers
14. From the search help pop-up, find the approver so that it can be added to list. In this example, enter the search term and click the start search checkmark icon as shown in Figure 11.
Find the exemption approvers
15. The results appear (Figure 12). Select the User Name and click the continue icon.
The approver user is displayed after the search
16. The user is added to the list of approvers. Press Enter and the system adds the other details, such as Name and Authority Check information. Click the continue icon as shown in Figure 13. This adds an approver to the exemption workflow feature.
An approver is added to the list
17. To test this workflow on a program, go to transaction code SE38. Give the name of the program you want to test for an ATC quality check (in this case, ZSOLMAN_INCLIST, as shown in Figure 14).
SE38 transaction with test program name
18. Click the Program menu item in Figure 14 and then click the Check > ABAP Test Cockpit (ATC) option.
19. In the results screen, all the ATC errors for this program are shown. You can see in Figure 15 that there are many priority 2 and 3 errors. Double-click one of the errors, which opens the error Details screen at the bottom (Figure 16).
ATC results screen
ATC error detail screen
20. To apply an exemption for this error, click the Apply for an Exemption link at the bottom of the screen as shown in Figure 16. There are other details such as error Check Title, Check Message, and Line Number where the error occurred in the program. It also mentions a pseudo-comment, which if inserted into a program at the end of the mentioned line number suppresses this ATC error.
A regular comment in an ABAP program is used to write an informative statement on what that part of the code is doing, whereas a pseudo-comment is used for suppressing an ABAP program error without any review or rectification. A pseudo-comment is bypassed by ATC checks. However, the use of a pseudo-comment is not recommended by SAP technical experts. Rather SAP encourages the development team to either rectify the ABAP program, manually ignore it based on the right justification, or ignore it based on ATC exemption workflow functionality.
21. An exemption pop-up opens. Change the exemption restriction values if required in this screen. Click the Continue button as shown in Figure 17.
ATC errors request exemption window
22. In the next screen, to select the approver, click the search help icon (or F4 help) as shown in Figure 18.
Approver selection in the request exemption screen
23. In the output, the earlier added approver appears. Select this approver by double-clicking it as shown in Figure 19.
Select the approver from the F4 help output list
24. Give the reason and then enter the justification for that reason. Select the On Approval or On Rejection notification option for email and click the Complete button as shown in Figure 20.
Approval request reason and justification
25. Once the Complete button is clicked, an error message pop-up is shown (Figure 21). It says as per the four-eye principle, the same user cannot be both the developer and the approver. Governance is built in the exemption workflow. Click the continue icon in this pop-up.
Four-eye principle violation error
Go back to steps 12 through 16 to add another user as an approver in another session.
26. Once another approver is added in the ATC system, select the approver for this error exemption. In the approver selection search help output, now two approvers are shown in Figure 22. Select the newly added approver by double-clicking it.
Approver selection pop-up
27. In the next screen, add the Reason and Justification and select the On Approval or On Rejection notification option for email as shown in Figure 23. Click the Complete button. This time the system allows this exemption request.
ATC approval request pop-up details
28. In this way an exemption has been requested by a developer for a priority 2 error. Now, the approver needs to either approve or reject this exemption request. To do so, go to transaction code ATC of the development system and select the Exemption Browser node. In this example, a local request is covered (refer to step 12). Hence, the approver goes to the ATC transaction of the development system.
29. In the next screen, click the execute icon as shown in Figure 24 to see the list of all the exemption requests shown in Figure 25.
ATC exemption browser selection screen
30. In the next screen, click the display/change (pencil) icon as shown in Figure 25.
Approval/Rejection exemption screen
31. In change mode, the Approve and Reject buttons are enabled. If the justification provided in the ATC error looks genuine, then approval can be given. In this example, click the Approve button to approve this error exemption as shown in Figure 26.
Approve the exemption request
32. Once approval is given, the error is suppressed by the system. To verify this, once again run the ATC check for the same program following steps 17, 18, 19, and 20. In the output screen, the priority 2 errors do not appear as shown in Figure 27. This was the error that was approved in the exemption steps.
ATC exempted error has disappeared in the new ATC run post-approval step
Applicability of the Automatic ATC Transport-Block Scenario
The ATC transport-block scenario has the following use cases for different kinds of projects. It also depends on the ABAP programming standards and governance decided by project governance and leadership teams.
- A greenfield implementation project involves a first-time SAP production environment setup, which offers a perfect situation for the use of the transport-block scenario. In this case, if the project governance team decides to carry only ATC error-free objects in production, then it can leverage the automated transport-block scenario. This decision and the enablement of the ATC setup should be up and running before the start of any kind of ABAP development objects.
- An implementation project for an existing live SAP production, involving brand-new Reports, Interface, Conversion, Enhancements, Forms and Workflow (RICEFW) developments, can leverage the transport-block feature. In this case, if the governance body decides on a zero tolerance on priorities 1 and 2 ATC errors, then the ATC transport-block scenario works perfectly. If such projects involve enhancement of existing old development objects, then those objects can be managed under a particular package. This way it won’t burden the existing team with rectification of older ATC errors from such objects. Any reused programs among brand-new development objects and the existing old programs would need clarity on responsibility for their correction. The project governance team and project managers can decide who should do the corrections in reused objects.
If the programming guidelines and skills of the team require a project not to consider such a zero-tolerance policy, then the transport-block scenario is a hurdle. It unnecessarily adds a burden to the transport-release team as transports will never be allowed due to the setup. For successful transport of such ATC erroneous objects, the ATC setup would need to change to relax the related settings of the transport-block option.
- In the case of production support, it is generally observed that the implementation team and support teams are different and may even involve different IT vendors. In such a case, a transport-block scenario in ATC is not applicable. Support team members are only responsible for the changes that they do in the ABAP programs. Hence this team is not responsible for ATC errors that may already exist in these programs, although custom development could work out in this situation. Here the requirement is that ATC should only show errors for the program versions after the date of support handover. SAP has shared multiple constructors to meet such specific requirements in ATC. In conjunction with this custom development and suitable ATC check variant customization specific to project needs, the transport-block scenario can be considered for production support.
Concerned teams can be informed about the errors found as part of the transport block scenario for their review. They can either rectify them or send them for exemption requests. The transport block scenario works successfully after their rectification or exemption approval.