The Open Source contribution Clean ABAP style guide for ABAP coding offers best practices and set of rules for you as developers to enable you to write more efficient, easier to understand and maintainable code. Having a common understanding of the code style enhances consistency of the code base and thus significantly improves your developer experience enforcing to work more quickly with even unfamiliar code and speed up the ramp up of new developers in your environment.
The style guide allows to enforce rules with static code checks. Based on the Clean ABAP, the free and Open Source code pal for ABAP tool contains a set of checks to support the Clean ABAP adherence. Code pal for ABAP checks can be used in Code Inspector and ABAP Test Cockpit.
Service virtualization and testing (SVT) solutions like Int4 IFTT (Certified ABAP addon for SAP Solution Manager – SAP Solman) provide the developers and functional consultants with ways to quickly simulate the interfaces of any 3rd party, non-SAP systems as well as B2B partners – EDI. This allows not only to quickly run test scenarios during the development (DEV) and integration (SIT) phases of the project but also run the regression testing on any non-productive environment. Not having to install and maintain many new test instances of non-SAP systems also allows the SAP S/4HANA transformation projects to be more sustainable as projects use less resources and can be done much faster, therefore reducing carbon footprint significantly.
Unit tests play a big role in modern software development. Unit tests let us check parts of our code for correctness very quickly within seconds. Independence of unit tests on any external dependencies means independence on any external environments like network, file system, database etc
Most of SAP developments work with database and we need a good isolation technique to test them. ABAP SQL Test Double Framework in my opinion is one of the best implementations ever. It lets you create something like a virtual database with temporary data in any table, Open SQL selects and updates work with that data in test mode.
But unfortunately ABAP SQL Test Double Framework is available starting from 7.51 version. I work in company where most of project use releases 7.50 and lower and I cannot use it.
This blog post will help you to change database entry in any environment with ease, but remember this is very powerful technique and may leads to data inconsistency if any wrong key data changed.
Also after this blog post you will be able to update the entries.
“This is very useful technique which can be used to change database tables data in any environment (if you have CHANGE access in Debugger).
The changes which can be taken out through this process cannot be tracked so may leads to inconsistencies. Think twice before using this….”
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 organizations 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.
In this blog we will take a look at how to run your ABAP Unit tests in CI pipeline when publishing from AbapGit and how to run the unit tests without relying on additional source code installed on the Abap server.
Why would you even want to consider this approach. You could just keep running your Unit tests like normal.
While this is certainly true, I don’t think you can test too often, so adding another layer of testing in a pipeline where you could also integrate other packages as well is pretty cool. Or possibly you could use this setup to potentially shift your development to a server off the common transport path to later integrate into the test system via a pipeline.
In this blog post I explain how you obtain statistics records with high quality and how you analyze them with transaction STATS. In the best case, such an analysis proves that your app combines excellent single user performance with low resource consumption and is scalable. In all other situations, the analysis will indicate the bottleneck where optimizations shall apply.
As owner and developer of transaction STATS I am more than happy to share tips and tricks that will help you to efficiently work with the tool and to obtain insights into your application’s performance.
You can use STATS since SAP NetWeaver 7.40. I am continuously improving it and this blog post presents the tool’s state for SAP NetWeaver 7.57 as of late December 2021.
As an SAP developer coming from the Java world, I always focus on Object Oriented ABAP and believe in the high value of unit testing. So the question came once, how should I test ODATA service?
In the past I tried to build mocking classes, so that I could call the ZCL*DPC_EXT methods, but it was too difficult and had little value when compared to development efforts. Then I left the topic and decided to keep example requests in SAP Gateway Client through transaction /IWFND/GW_CLIENT. That was ok for documenting purposes, but it was not a unit test unfortunatelly.
Let’s look at it a little bit closer.
I prefer using various configuration for different projects. So in my case I created a separate folder for the demo project and configured package.json file:
{
"name": "uiveri5-example",
"version": "0.0.0",
"scripts": {
"tests": "uiveri5 ./tests/conf.js"
Every now and then we find a need for doing some work in parallel. Recently I’ve worked on a process that was taking far too long to be of any use. It was taking large amounts of data in and creating an even larger amount of records given complex rules, validations and enrichment.
Refreshing some ABAP parallelism techniques, my options were basically to split the input data and then running FMs in background, starting a new task or writing a report and scheduling a job with parallelism being ranges of a selection criteria.
All valid options, I suppose, but I got used to work purely in OO and hammering FMs here and there to have my parallelism had a particular bad smell. It would prevent me to assert some critical behavior via unit tests, for starters, and it would also add this new responsibility, running in parallel, to weird places with code that looked boring and repetitive (take data from classes, run fm, take data back…).
Although it is generally best practice to create global exception classes, they can seem a bit overkill for some applications. Think of PoCs, demo scenarios, BAdI implementations, etc. A handy but not so well-known option for these situations is to define a local exception class inside the global class. These allow internal exceptions (exceptions raised within the class itself) to be handled without the need for another global DDIC object.
In this part, we are going to focus on the installation and access to the ABAP platform.
I will reiterate the process blueprint to help follow the steps we need to achieve to complete this installation. Since we tackled Step 1 of the blueprint in Part 1 of this series, we will continue from step 2 in this part.
1. Create and login into an ubuntu instance on Azure.
2. Prepare the data drive on your ubuntu instance.
3. Install docker and move docker data directory to the prepared data drive.
4. Install ABAP Platform 1909 Dev Edition with docker.
5. Open the necessary ports on Azure.
6. Access your ABAP instance in SAP GUI and generate a new license.
As coders, we run into several situations where we would like to test snippets of code on a local system before even implementing the snippet in a dev system. In certain instances, we as developers would want to use code QA tools like the ABAP Test Cockpit and either do not have the authorizations to access the tool or are not comfortable with setting it up in a customer system.
My goto setup to get a personal system was the SAP Cloud Appliance Library (SAP CAL), It serves the purpose it was designed for perfectly. It is very well built and very intuitive to use while requiring very little interaction with the underlying technologies to get up and running in a test ABAP environment. The only apparent downside with regards to SAP CAL is the fact that it is a bit of an overkill for what a developer might want to use the system for, which warrants its relatively heavy price tag. The cost break down of running an an SAP NetWeaver AS ABAP 7.51 SP02 on HANA Dev system as at the time of writing this post is:
With SAP BTP ABAP Environment 2105 we delivered the basic scope of ATC exemptions. Now you can create and approve ATC exemptions using ADT in Eclipse and transport them between different SAP BTP ABAP Environment systems.
NOTE: In order to incorporate feedback from early adapters before making this functionality free available for all, it is currently available via the feature toggle. You need to create a customer ticket on the BC-CP-ABA component to turn it on in your SAP BTP ABAP Environment system.
Let’s take a look at the ATC exemption process in detail. The following class contains the hard-corded user name and will be checked with the ABAP Test Cockpit for security violations:
Part 9 – Write a third unit test
To recap from the preceding blog, we added a new unit test for testing production subroutine set_alv_function_module_name and, when executed, this unit test triggers a warning. Here is the source code as we left it in the previous blog:
Part 8 – Fix the production code bug identified by the second unit test
To recap from the preceding blog, we fixed the production code highlighted by a unit test failure, which caused the unit test to now pass and the production code, when executed, to retrieve the correct rows from the persistence repository. Unfortunately, we also found that when we request the output in ALV grid format we still are presented with the ALV report in classic list format. Here is the source code as we left it in the previous blog:
Part 7 – Write a second unit test
To recap from the preceding blog, we had added a new unit test method to call subroutine get_flights_via_carrier three times, each time using a different carrier value, and found that this unit test method issued two failures, suggesting that one of the carrier values did not cause a test failure. Here is the source code as we left it in the previous blog:
Part 6 – Using the correct method call syntax to request a unit test assertion
To recap from the preceding blog, we had changed the call to method assert_not_initial of class cl_abap_unit_assert so that it uses the standalone static method call syntax instead of the former dynamic method call syntax. We also know there is a bug in the production code: the ALV report presents rows for the wrong airline. Here is the source code as we left it in the previous blog:
