BTP - Central ATC
How can you configure the ABAP Test Cockpit in the BTP? What are the stumbling blocks and what can you do with them in the end? Read more in this article.
Table of contents
In this article we will look at the different aspects of the ABAP Test Cockpit in the BTP and how you can use it effectively in your organization. We will also share some current experiences from configuration and use.
Introduction
The ABAP Test Cockpit, or ATC for short, is based on the old Code Inspector and is a further development of the tool for static code analysis in the system. The advantage of the ATC lies in the modular structure of the tests and variants. For example, additional tests can be installed in the system and the ATC can be expanded. There are a few projects in the open source area. The ABAP Test Cockpit can also be configured so that transports or tasks cannot be released if the correct status has not been achieved in the tests. In this way, a basic level of quality can be created in the system without much effort.
There are currently the following scenarios for different uses of the ATC:
- Custom Code Migration - In this scenario, we want to test a development system with a specific variant or scenario. For this purpose, we have the "Custom Code Migration" app at our disposal, which we can use to carry out a test run.
- Developer Scenario - In this scenario, the development system calls the BTP and initiates the test run in the system. This can happen manually via the ABAP Development Tools or SE80, or automatically when a transport or task is released in the system.
Hint: Currently, no ABAP environment can be connected to the Central ATC; only local checks and approvals are possible here. This should be possible in a later release.
SAP Blogs
On the SAP side, Olga Dolinskaja writes very good blogs on setting up and using the ABAP Test Cockpit in the cloud. You can find more information at the following blogs:
- Configure ATC in Cloud
- ATC for On-Premise
- Use ATC as On-Premise Developer
- Exemption process
- Schedule ATC runs
- How to use baselines
Preparation
Before we can start configuring the system, you should make sure that the following notes have been implemented in the system:
- 2599695 - Migration of custom developments: SAP Fiori app: Remote stubs for the tested system
- 3333009 - RFC stub for CVA/SLIN remote tests
- 3358660 - Cloud developer scenario
- 2270689 - Remote analysis (for source system)
- 3053248 - Approvers are not displayed
- 3422320 - Dumps in the Central ATC
Note 2270689 is a collective note, here you have to use the one for your system release. The notes must be imported for each development system that you want to connect to the BTP.
Connection
After we have prepared the on-premise development systems, we need to set up the appropriate connections. Firstly, we need a connection from on-premise to the BTP, from the BTP to on-premise and releases in the Cloud Connector.
ABAP Environment
In the ABAP Environment we need to implement two scenarios to establish a connection. Firstly, we need the connection to the on-premises in order to serve the custom code migration scenario, and secondly, we need a technical user and the connection to the system for development. In the first step, we would create the communication arrangement for SAP_COM_0464:
You can already enter the system ID here, as we need many of these connections. In this example, we are using the ID of a CAL system. Under the additional properties, we maintain the object provider; we recommend storing the SID so that the system can be assigned. You can assign the system group uniformly for all development systems in a landscape.
For further configuration, you must store a communication system that points to the development system and enter the technical user that you created on-premise in the next section. As a last step, we have to create the inbound connection in the system. For this we need the communication scenario SAP_COM_0936:
In the additional attributes, you then store the object provider from the previous step. This is important for the back connection during the testing process. If the process is started on-premise, the system must also establish a connection to the on-premise in order to be able to read data.
In the next steps, we set up an inbound scenario and create a technical user, which we then enter on-premise in the RFC connection in order to establish a connection. The "User Name" is then relevant for the on-premise configuration:
You can find further details on configuring an outbound and inbound connection in this article.
On-Premise
In the on-premise system we have to set up an RFC connection and a technical user who is used for access from the BTP. In the first step we create the RFC connection in transaction SM59. To do this we create a connection of type "3" (ABAP Connection). We use your company's Cloud Connector instance as the target.
We store the created user on the ABAP environment as the user and password. In this case, however, not the technical CC* user, but the assigned user name. Since the field is not too long, the name should not be too long.
In this case, we use SNC to establish communication with the Cloud Connector. You can find the corresponding settings in the system using the button.
In the last step, we activate fast serialization for the RFC connection. You can find further information in the section below.
Once we have created the RFC connection, we still have to create a technical user in the system. You can name this freely, but it should be of type "B" (System). You can find the authorizations for the user in the technical documentation, so you should create a role for the technical user.
Cloud Connector
We have to configure three things in the Cloud Connector. In the first step, we need a service channel from on-premise to the ABAP environment, which routes the traffic. For this purpose, we have entered the Cloud Connector as the target in the RFC connection.
The second step is to map the virtual host to our on-premise system. We need one mapping for each system.
The last configuration is to release the RFC resources for the BTP. This happens for each virtual system. The resources can, however, be made available in the system via download and upload. You can find the list of authorizations and releases required for the import in note 2861842.
Summary
Here is a brief summary of the various connections and steps:
- BTP - definition of outbound and inbound connections, creation of communication users
- On-Premise - RFC connection, technical user
- Cloud Connector - release of resources for on-premise, routing towards ABAP Environment (Central ATC)
Configuration
Now that we have configured the connections and access, it is now time to set up the developer scenario. To do this, we need to make configurations on both systems.
ABAP Environment
First of all, we need to create a check variant if we want to use our own configuration. To do this, we would create an "ATC Check Variant" on the development system and can configure it freely. We would then have to transport this to the Central ATC system.
On-Premise
On-Premise we have to configure the variant using the SCI transaction and then carry out the basic configuration using the ATC transaction. To do this we call up the SCI transaction and navigate via the "More -> Code Inspector -> Management of -> Reference Check System" menu to store the created RFC connection.
In the next step we create a global check variant in the transaction. The easiest way to do this is to give this variant the same name as in the ABAP environment. You can then store the variant in the "In the reference check system" area.
When saving, a check is also carried out to see whether the variant exists in the Central ATC. As a final step, we would then complete the basic configuration in the ATC transaction. There you can set when the ATC is executed and what effect the errors then have on the transport and task release. Here are the settings from an S/4HANA 2023 system. The interfaces look different depending on the release.
Summary
What have we actually configured? Here is a brief summary:
- BTP - creation of the test variant
- On-Premise - creation of the remote variant, configuration of the ATC
Use
You should now be familiar with the use of On-Premise, and can use all of the standard ATC scenarios. Various applications are now available to you in the BTP:
- "ABAP Test Cockpit Configurator" (F4712) - You can use the app to define a standard variant and adjust the classification for test messages. This allows you to set messages higher or lower or even hide them completely if you are not interested in certain messages in a test.
- "Custom Code Migration" (F3191) - The app is used to plan various test runs related to code analysis in the remote system. This means that variants for a BTP or S/4HANA migration are available to you, as is the classic test run with your own variants.
- "Approve ATC Exemptions" (F7472) - You can use the application to process requests for messages from the on-premise system. The developer submits the requests using the ABAP Development Tools.
- "Schedule Custom Code Analysis" - This is a variant of the "Application Jobs" app with a filter for test runs. This allows you to plan and carry out test runs in the system.
Stumbling blocks
We encountered the following stumbling blocks and errors during implementation. If you have followed these points, you should have fewer problems when introducing the Central ATC:
Dumps after note implementation
After executing the report RS_ABAP_SETUP_ANALYSIS (2270689), we experienced dumps in the system of the type "LOAD_PROGRAM_CLASS_MISMATCH". The error occurred when resources were activated in the system. It helps to generate the classes mentioned in the dump again.
User name for RFC connection
When creating an on-premise connection, it is important to enter the correct user in the authentication details. If you choose a user name that is too long, it will not fit in the field and you may come up with the idea of using the technical ID (CC*).
Target Cloud Connector
The target of the RFC connection is the Cloud Connector, which then forwards the traffic to the ABAP environment. Configuring the ABAP environment directly did not work and probably only works on new systems via a WebSocket connection.
Missing approver
If the approver remains empty when you request it in the ADT or if an error message appears, then note 3053248 probably needs to be imported. When you call up the approvers from the BTP, the group mapping is then missing.
Dumps in the Central ATC
If you receive some dumps in the central system that refer to the function module SADT_REST_RFC_ENDPOINT, note 3422320 is probably missing. The function module should not be called during the check.
TIMEOUT during checks
Do the checks take a long time for certain objects, even though there is hardly any coding in the object? The error can also occur with WebDynpros and large programs. The check takes a very long time in the ADT and the SAP GUI and runs into a TIMEOUT after just under an hour. In this case, the variant may contain checks that are causing the error; checking the variant can help.
TIMEOUT in ADT
The check in the SAP GUI completes in a few seconds, but in the ABAP Development Tools it runs very slowly and leads to a TIMEOUT. In this case, taking a look at the settings of the RFC connection will help. If "fast serialization" is activated, the problem should be solved.
Authorizations and releases
It can sometimes happen that not all objects are released in the Cloud Connector or that the on-premise user has all the authorizations. It is worth taking a look at the logs of the Cloud Connector and the ST22/Feed Reader. Depending on the test used, different authorizations are required; you should test all scenarios in more detail here.
Evaluation
In this section we want to look at the benefits and use. Why do we use the Central ATC in the ABAP environment?
- Many development systems - If you have many development systems, you must always ensure that the Central ATC is up to date with all systems. With many systems it can quickly happen that a system is updated early, then the tests on the system no longer work.
- Maintenance time - The upgrade process on the ABAP environment is very quick and there is no manual effort on your part. However, you should test the main functions after the release.
- Costs - In the first step the costs seem expensive at around 2200 EUR per month, but you also get the CVA module for free. On-premise the module currently costs a lot of money or you rely on a third-party product, which also costs accordingly.
- ADT - Requesting exceptions only works via the ABAP Development Tools. We see this point as positive, as the ADTs are already the standard development tools and even the last ABAP developers should understand this.
But there are also a few points that you should assess for yourself and how important they are to you.
- Features - Currently, not all features work like on-premise. There are no time-limited releases, the four-eyes principle can currently only be ensured organizationally and no release teams can be created for each system landscape. Likewise, the option of dynamically setting or controlling the objects in the test set is missing.
- Upgrade - We have not had this case yet, but it may be that after a BTP release all on-premise systems also need the latest stub. Depending on the size of the landscape, new notes must be implemented everywhere.
Conclusion
The ABAP Test Cockpit in the cloud can take the stress out of upgrading on-premise and provides added value in the form of CVA tests that would cost a lot more on-premise. At the same time, you always get the latest tests in the BTP, even for your older systems.
