By Ross Nolan, SAP Specialist, Basis Technologies
When you are adopting agile and DevOps methodologies in SAP development, part of the process is shifting left. That means giving the developers more ownership of code quality, by integrating quality checks into their workflows. It’s a more satisfying way to work, and it cuts cycle time by reducing rework between developers and QA.
At the same time, many organisations find it difficult to achieve consistent code quality across all of their development systems and team members. A company might have multiple developers working on the same code base, or might, for example, have separate code bases for different systems like ECC, BW and CRM.
SAP’s ABAP Test Cockpit (ATC) provides a solution. It enables you to run the same code quality checks across all of your systems and can empower developers to check and manage code quality much earlier in their development workflow. ATC is integrated into ABAP Workbench, so it’s easy for developers and QA experts to use.
ATC uses the SAP Code Inspector (SCI) but has the additional superpower that you can configure ATC centrally and run it across all of your development systems rather than having to rely on local instances (or variants) of SCI for each development system. Having a single, central variant of SCI run through ATC helps to achieve consistency across development systems.
Versioning is an extra benefit. Or more precisely, the fact that you don’t need to worry about it. If you’re using different versions of ABAP in different dev systems - and therefore have different versions of SCI across them - ATC helps to run the right checks in each location by ensuring you have a version of SCI that can be used in all your Dev systems, from most to least current.
The idea is to allow remote development systems to run the SCI variant in the ATC central system. That means they need a way to connect to it, so it makes sense that you can only use Remote Function Call (RFC) based checks in the central SCI variant.
Figure 2: ATC Central SCI variant can only use RFC-based checks
To make a success of implementing ATC, there needs to be a dialogue with developers. First, you need to help the development team to understand how ATC can reduce code issues in the future. ATC includes performance, security, and robust programming checks that can detect issues that could otherwise result in rework. A big part of the conversation with developers is how ATC enables them to have more ownership of code quality, and how this helps their workflow and product quality.
Next, there needs to be agreement on a consolidated SCI variant that can be used across all the development systems. There may be some debate around this. When we implemented ATC, we went through all the suboptions in ATC and held meetings to agree on the right variant for us. This remains open for review. Someone might suggest new checks we should enable, or we might remove checks that we later discover are not helpful to us.
In theory, it would be ideal to centralise all checks in ATC. In practice, there will be issues that developers of some applications (e.g. BW) want to be flagged, but which developers of other systems would not find helpful. In that case, you can exclude those issues from the central variant, and run SCI additionally locally for checks that only apply to certain applications.
With the SCI variant defined, you need to identify all the issues it raises in the existing code. You are likely to identify issues for which you need to raise internal change requests to have them fixed.
To avoid overwhelming developers, ATC has the concept of creating a baseline of the issues in your current code that you do not want to be flagged in future ATC results. This enables you to focus your attention on what really matters to your business and to ignore issues that a human review reveals are not an issue for your code, or which cannot be practically fixed.
The escalation handling process needs to be defined for when developers request an exemption because ATC is flagging something they believe needs to stay as-is. Upon email notification of an exemption, ATC administrators log into the central ATC system and can then approve or reject the exemption request, based on the developer’s justification.
By default, ATC allows you to automate checks in a development system on transport release. If issues are detected, there is the option to inform the developer or to create an error and stop the transport release. That helps to enforce quality, but it’s frustrating for developers who think they have finished making a change, only to find ATC rejecting it. They have to go back to the code, make changes, and do the unit testing again.
Third-party automation tools enable you to run the checks before the developer even tries to release the transport to QA. For example, when the developer enters the desired unit test results in the development system, automation can be used to run ATC. Automation can be used to trigger checks using local SCI variants, too, to ensure that any application-specific quality issues are also identified.
Some companies use automation to run the same checks in the inbox of the QA system. This provides a safety net and revalidates that the transport is ready for QA, and also enables QA to run any additional checks they require.
ATC helps to shift development left by allowing developers to detect quality issues in ABAP before their code leaves development. At the same time, it helps to enforce a standard of quality across multiple development systems.
ATC and SCI are most powerful when combined with automation tools that make ATC part of a connected workflow. Automation helps to push the checks as far left in the development cycle as possible, cutting cycle time and helping to empower developers with greater autonomy.
Others here on SCN have dug much deeper into implementing ATC; I’d recommend taking a look at some of their posts if you’re interested in learning more:
https://blogs.sap.com/2012/09/19/abap-test-cockpit-an-introduction-to-sap-s-new-abap-quality-assuran...
https://blogs.sap.com/2021/03/26/setting-up-a-central-atc-system-part-6-accumulated-faqs/
When you are adopting agile and DevOps methodologies in SAP development, part of the process is shifting left. That means giving the developers more ownership of code quality, by integrating quality checks into their workflows. It’s a more satisfying way to work, and it cuts cycle time by reducing rework between developers and QA.
At the same time, many organisations find it difficult to achieve consistent code quality across all of their development systems and team members. A company might have multiple developers working on the same code base, or might, for example, have separate code bases for different systems like ECC, BW and CRM.
SAP’s ABAP Test Cockpit (ATC) provides a solution. It enables you to run the same code quality checks across all of your systems and can empower developers to check and manage code quality much earlier in their development workflow. ATC is integrated into ABAP Workbench, so it’s easy for developers and QA experts to use.
How ATC improves upon SAP Code Inspector
ATC uses the SAP Code Inspector (SCI) but has the additional superpower that you can configure ATC centrally and run it across all of your development systems rather than having to rely on local instances (or variants) of SCI for each development system. Having a single, central variant of SCI run through ATC helps to achieve consistency across development systems.
Versioning is an extra benefit. Or more precisely, the fact that you don’t need to worry about it. If you’re using different versions of ABAP in different dev systems - and therefore have different versions of SCI across them - ATC helps to run the right checks in each location by ensuring you have a version of SCI that can be used in all your Dev systems, from most to least current.
Figure 1: One central check system for multiple systems on various releases
The idea is to allow remote development systems to run the SCI variant in the ATC central system. That means they need a way to connect to it, so it makes sense that you can only use Remote Function Call (RFC) based checks in the central SCI variant.
Screenshot: RFC based SCI checks in a Central variant
Figure 2: ATC Central SCI variant can only use RFC-based checks
Implementing ATC
To make a success of implementing ATC, there needs to be a dialogue with developers. First, you need to help the development team to understand how ATC can reduce code issues in the future. ATC includes performance, security, and robust programming checks that can detect issues that could otherwise result in rework. A big part of the conversation with developers is how ATC enables them to have more ownership of code quality, and how this helps their workflow and product quality.
Next, there needs to be agreement on a consolidated SCI variant that can be used across all the development systems. There may be some debate around this. When we implemented ATC, we went through all the suboptions in ATC and held meetings to agree on the right variant for us. This remains open for review. Someone might suggest new checks we should enable, or we might remove checks that we later discover are not helpful to us.
In theory, it would be ideal to centralise all checks in ATC. In practice, there will be issues that developers of some applications (e.g. BW) want to be flagged, but which developers of other systems would not find helpful. In that case, you can exclude those issues from the central variant, and run SCI additionally locally for checks that only apply to certain applications.
Establishing a baseline and managing exemptions
With the SCI variant defined, you need to identify all the issues it raises in the existing code. You are likely to identify issues for which you need to raise internal change requests to have them fixed.
To avoid overwhelming developers, ATC has the concept of creating a baseline of the issues in your current code that you do not want to be flagged in future ATC results. This enables you to focus your attention on what really matters to your business and to ignore issues that a human review reveals are not an issue for your code, or which cannot be practically fixed.
The escalation handling process needs to be defined for when developers request an exemption because ATC is flagging something they believe needs to stay as-is. Upon email notification of an exemption, ATC administrators log into the central ATC system and can then approve or reject the exemption request, based on the developer’s justification.
Automating checks in ATC
By default, ATC allows you to automate checks in a development system on transport release. If issues are detected, there is the option to inform the developer or to create an error and stop the transport release. That helps to enforce quality, but it’s frustrating for developers who think they have finished making a change, only to find ATC rejecting it. They have to go back to the code, make changes, and do the unit testing again.
Third-party automation tools enable you to run the checks before the developer even tries to release the transport to QA. For example, when the developer enters the desired unit test results in the development system, automation can be used to run ATC. Automation can be used to trigger checks using local SCI variants, too, to ensure that any application-specific quality issues are also identified.
Some companies use automation to run the same checks in the inbox of the QA system. This provides a safety net and revalidates that the transport is ready for QA, and also enables QA to run any additional checks they require.
Conclusion
ATC helps to shift development left by allowing developers to detect quality issues in ABAP before their code leaves development. At the same time, it helps to enforce a standard of quality across multiple development systems.
ATC and SCI are most powerful when combined with automation tools that make ATC part of a connected workflow. Automation helps to push the checks as far left in the development cycle as possible, cutting cycle time and helping to empower developers with greater autonomy.
Others here on SCN have dug much deeper into implementing ATC; I’d recommend taking a look at some of their posts if you’re interested in learning more:
https://blogs.sap.com/2012/09/19/abap-test-cockpit-an-introduction-to-sap-s-new-abap-quality-assuran...
https://blogs.sap.com/2021/03/26/setting-up-a-central-atc-system-part-6-accumulated-faqs/
- SAP Managed Tags:
