We started in the previous post this new serie about ABAP code analysis, with the help of Walter Strobl, Director of Quality in Vision IT and specialist of SAP environments.

Today, we will see what is necessary to know to implement a process of ABAP code analysis with Sonar.

The SAP Workbench

SAP is not only an ERP software with its own screens, treatments and data structures, but also a runtime environment and a development environment.

The first thing you should know is that an ABAP programmer will not install an IDE such as Eclipse with a compiler on his machine : he will connect to a SAP server and works with the SAP Workbench in order to create a program, a screen, to access the dictionary or SAP kernel objects, etc. Everything is stored in the Workbench, there are no files or directories (even if there are some ways of organizing the code).

Access to the Workbench is realized through transactions. For example, to modify an existing program, go into the editor into the Workbench and enter a transaction code (SE38 in our case) to access a screen where you enter details about the program that you want to change. And therefore, the developer does not work with a graphical user interface and must not only know ABAP programmation, but also how to navigate in the Workbench.

This means that we must first extract the code in ABAP Workbench to analyze it. This is not a problem, and we’ll see how to do it in a future article.

It also means that sometimes you have to be careful when you talk about transaction. Not only everything in the Workbench requires a transaction code (even a user does not call a program, but access it through a transaction). But suppose that I speak to a consultant or a SAP administrator, and ask him what kind of transactions is carried out in a set of programs that I will analyse, in order to name it in the Sonar dashboard. Of course, I’m talking about functional transaction: creating a customer, printing an invoice, etc. But my contact will most often understand ‘SAP transaction’ and not ‘functional transaction’, which could cause a misunderstanding.

I have already mentioned that the vocabulary is a bit peculiar. But hey, it’s not like speaking Klingon (it’s SAP, not Star Trek).

SAP Areas

Another important thing to know, because we will have some questions about it in the next post: areas or SAP modules. We said that SAP is composed of different modules or functional areas: the best known are FI/CO (Financial & Controlling), HR (Human Resources) or SD (Sales & Distribution) and PP (Production Planning).

Of course, all these modules work together: an invoice in SD go into an account in FI. But they are quite complex, requiring specific knowledge, and therefore all teams do not work in the same SAP areas, and not all use the same SAP server. So you will not talk, for example, of the ‘Purchasing’ application, but of FI, CO, AM (Asset Management), MM (Material Management) for the management of stocks, etc.

This is important because, as we must extract the ABAP code from a server:

• Different servers will require more than a single extraction.
• The code is always organized by SAP areas. And therefore, at the upper level of our Sonar dashboard, we will find the analysis for FI, CO, HR, etc.

SAP objects

I will not present all types of ABAP objects, as this is not a training about SAP, and anyway, we will see that when we start the analysis. Now, when you will meet ‘ABAPers’ to see with them how to start a process of code analysis, they may ask you what are the objects that are scanned or not. Here are a few to know :

• Class: although there is an object-oriented extension of the ABAP language, a class refers to a ‘package’, ie a set of files that implement a feature (or a technical process). You can also talk of a module, but there is a risk of confusion with a SAP area. In all cases, you should know that an ABAP class is not the equivalent of a Java class.
• Report / Module pool: a program is essentially an interface that allows a user to enter data for a report or a more complex series of processes (usually reusable) to interact with a user, named ‘Module pool’ or also ‘Function pool’.
• Form: this is not a screen, as it would sometimes be with other languages, but a subroutine called by PERFORM.
• Include: a treatment that can be called (for inclusion) in a program, such as a Cobol Copy.

Walter: In your Quality team, you have people who come from the J2EE world, or which are not from the SAP world, and analyze ABAP code? Is it difficult for them to adapt to this new language? What is the level of effort?

The question is important, but we must consider two distinct tasks: the analysis and interpretation of results.

The adaptation necessary for a person to implement ABAP analysis is quite simple, one or two days at most, depending of her knowledge of Sonar and if she has already used it with another technology.

The task of interpretation of the analysis results usually requires a deeper understanding of ABAP technology, and can be acquired in one or two weeks, with the support of a specialist in the language, with a minimum of knowledge of best programming practices. Thus, our teams consist of experts in different technologies (ABAP, Java, PL / SQL, etc.).

There are other activities such as the creation of new rules or measures in a plugin, which requires a deep understanding of the creative process and the technology.

Thanks Walter. It is exact to say that best practices of ABAP programmation are not always normalised as for other technologies. This is something that we will see in the next posts.