See how to use the transport block and exemption workflow features of the SAP NetWeaver ABAP Test Cockpit (ATC). Obtain insight into the applicability of these features in different project scenarios.
Key Concept
The SAP NetWeaver ABAP Test Cockpit (ATC) is an SAP code-quality verification tool. It is integrated in the SAP NetWeaver ABAP Workbench. In its free version, it is a combination of the Code Inspector, extended check (SLIN check), and syntax check tools. It offers multiple checks on ABAP programs based on SAP best practices. These check categories are the Code Inspector check variant categories. ATC offers two interesting features: transport block and exemption workflow. The transport-block feature is meant to block a transport-request release from one system to another. The condition for blocking is that this transport request should have ABAP objects under it that have ATC errors. Exemption workflow is an automated approval engine that allows a developer to request an exemption for ATC errors from a manager so that these errors are ignored by ATC runs after approval.
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.
Figure 1
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.
Figure 2
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.
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 execute transaction code SE09 to go to
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.
Figure 4
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.
Figure 5
Transport release
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.
Figure 6
ATC transport block pop-up with error
8. The error summary table opens as shown in
Figure 7. Click the continue icon to continue.
Figure 7
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 sidebar “Applicability of the Automatic ATC Transport-Block Scenario” for scenarios showing the applicability of a transport-block scenario in different kinds of SAP projects.
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.
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 icon as shown in
Figure 8.
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.
Figure 9
ATC results screen
Exemption-Workflow Scenario
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.
Figure 10
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.
Figure 11
Find the exemption approvers
15. The results appear (
Figure 12). Select the User Name and click the continue icon.
Figure 12
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.
Figure 13
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).
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.
Figure 15
ATC results screen
Figure 16
Figure 16
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.
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.
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.
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.
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.
Figure 21
Four-eye principle violation error
Go back to steps12 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.
Figure 22
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.
Figure 23
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.
Figure 24
ATC exemption browser selection screen
30. In the next screen, click the display/change (pencil) icon as shown in
Figure 25.
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.
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.
Figure 27
ATC exempted error has disappeared in the new ATC run post-approval step
Sapna N. Modi
Sapna N. Modi has 13+ years of experience in the software industry including SAP software in the areas of solution architecture, consulting, presales, and project management. Sapna has multiple SAP and non-SAP certifications. She is an integral part of the team in setting up the SAP Solution Manager practice at L&T Infotech (
www.lntinfotech.com) and has participated in consulting and advisory roles for multiple projects. She has global exposure with experience in the US, Canada, Denmark, Sweden, Germany, the Netherlands, and Kuwait. She is instrumental in and is dedicated to an extreme automation initiative of SAP projects across verticals at L&T Infotech (LTI). Her goal is to accomplish automation-driven efficient operations and to formulate an automation platform for optimized TCO for customers as well as for her organization. Her focus is on innovation to leverage SAP products and non-SAP products involving Robotic Process Automation (RPA), Artificial Intelligence (AI), and Machine Learning (ML) to help customers standardize their portfolio so that it is simplified, automation ready, and able to easily migrate to the SAP S/4HANA platform.
You may contact the author at
sapna.modi@lntinfotech.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the
editor.
