We continue our series on the analysis of ABAP code.

We have seen in the previous post what you need to know about the SAP technology and ABAP code.

We will now list the questions to ask to the project teams in order to prepare the extraction of code, the analysis and their organization in the Sonar dashboard.

If you already know Sonar because you are used to perform analyzes, for instance of J2EE code, but do not know anything about SAP, this part will probably interest you.
If you are familiar with the SAP technology but ignore all of Sonar, the future posts about analysis of ABAP code with Sonar will interest you.

In both cases, you will first need to prepare the delivery of this code, and this post may be helpful.

Fortunately, we have Walter with us who is expert in both areas, the quality of SAP applications with the Sonar platform, and we will benefit from his experience and expertise.

Who is the customer?

The first question, even if you do not need to ask it to SAP teams because you can already answer it, is whether you work for:

• the IT department of your company, in which case your customers are project teams or stakeholders in different departments;
• a provider or as a consultant, and your customers are other companies to which you deliver services about code quality, and most likely the project teams internal to your company.

You will tell me: what does it matter, anyway, if in both cases we analyze ABAP code? The question is important, because the extraction of ABAP code can be achieved relatively easily if you are in the IT department of your company, when you know which code to download from which SAP server (Workbench) and can obtain the necessary authorizations.

But if you work for a provider, you will have to see the IT department of every customer, and ask if they can provide such accesses and the appropriate permissions to extract the code that they will indicate you (classes, files, etc.). But most customers do not like to give outside access to their critical applications at the heart of their business, in which case they will have to put this code at your disposal. And you have to manage this process and keep a certain traceability and an image of each delivery for some times, in order to be able to reinstall it for a new analysis (with different rules or thresholds for instance) or simply demonstrate, in case of doubt, that there were no errors of analysis and that the results in the dashboard correspond to the delivery done by the customer.

Also, there is a good chance that you will be asked to analyze the code provided by different providers (90% of SAP applications are outsourced). And so you’re probably going to manage this process of extraction and analysis as many times as you have outsourcers, but also according to the use cases.

This is the case of our friend Walter, Director of Quality for Vision IT Group, head of a center of excellence for different customers, which analyzes all code deliveries from different suppliers in Quality Gate processes, but also performs benchmarks of these providers. This kind of analyses is very popular with customers who like to use these results to manage SLA (Service Level Agreements).

There are different use cases and scenarios that can combine, and this is the first most important point to define with your users and customers. Always maximize the benefits for the business. We will talk about these use cases with Walter in the next post, and keep this article with more technical questions.

SAP version

The first question is simple: which SAP version is used? No difference in the language – but in the SAP Workbench itself, and thus the extraction program to implement will not be the same.

SAP areas

We have seen in the previous post that there are different SAP modules: FI, CO, HR are the most frequently encountered. And we will organize our analysis and the results in the dashboard according to them, because this is how your client or the project teams understand SAP applications and want to see them.

SAP servers

These different areas can be distributed over multiple servers, each with its Workbench and custom ABAP code. You need to think about organizing your analysis process from the beginning, from the extraction of code, that you will have to perform on each server.

That said, it depends on the use cases and / or the first point, depending on whether you are in charge or not to perform the extractions. But anyway, the number of extractions depends of the number of servers.

Organization of the teams

Once again, this will depend on the use cases to implement. The most common situation is when different providers are working on the same server. So if you need to implement, for example, a Quality Gate to validate the delivery of each service provider, it is necessary to know who is working on any server and any SAP area.

Beware: this calls for a very common question that it is better to clarify and discuss with your client as soon as possible. ABAP code, as many Cobol applications, can be quite old. Imagine you analyze this code for a Quality Gate and meet a large number of serious or critical defects, and most often the last developper who did implement the changes will not be responsible for these defects, but all the programmers who preceded it. So you can not tell the to the project team or the outsourcer that you will reject the delivery and that they must correct the defects, as they are not responsible for them.

The only way to know who has added new defects would be to analyze all the existing code to provide a ‘baseline’ and then see the new defects in the code that changes this baseline. But that would mean that you will start your process by analyzing millions or tens of millions of lines of code to create this baseline portfolio of SAP applications. Sonar is a very powerful tool when it comes to analyzing the code, but it would be a very high effort for a benefit that will depend on the use cases, but also the relationships that your client has with his project teams and providers. This is anyway a point to address during the first meeting.

Organization of the code

Some customers organize their code in classes (we have seen in the previous post that these are modules and not Object class as for J2EE). Basically, a class is a directory where you can find different programs to analyze. Not a problem for Sonar, whatever the number of programs and the number of directories in the root directory of the analysis.

But you must ask to your customer if he organizes the code into classes or not, because this is not the case for everyone. This will also impact on the extraction / delivery of the code to analyze, since in some cases they will focus on SAP classes and in other cases on different files in a single folder. And in the first case, you will have a dashboard with 2 levels: the area (FI, CO, etc.) and then classes, and in the second case each area with files.

Depending on the use case, you can choose to have other levels (date of analysis, id of delivery, application versions, etc.).

Naming conventions

We do not analyze the SAP kernel code, only the code developed to customize the SAP kernel. Therefore, it is usual to recognize this code with naming conventions.

If you see a class that starts with Z or Y or YY or ZZ or XX, it is custom code that you can analyze. It must be the same at the program level, but here, the rules may change depending on the type of the program. For example, you can see a program name beginning with the letter “L” to indicate a ‘load-module’.

Here is an example of a very usual naming convention: Z [Id] _ [t]_*, with:

• ‘Id’: id of the class of the project
• ‘T’: type of object, R for a Report, I for an Include, etc.
• *: a description of what is supposed to do the code.

With such a rule, you will see files like ‘ZUC_R_CHECK_FISCAL_CODE.abap’, for instance.

SAP standards

Last question, not specific to SAP (always ask this question in any case): are there any coding standards? They are found more often in the SAP world than with other technologies, and it is therefore interesting to see if you can get your hands on a document that describes these good practices. This will also help in the implementation of the use cases.

Walter: do you see other issues to address, when you starts a process of ABAP code analysis with a new customer?

I try to know the amount of code to analyze.

This volume can be measured in lines of code (LOC). In addition, for SAP ECC 6.0 version, we have an ABAP program that allows us to measure this number of lines.
This allows us to get an idea of the time needed to do the analysis and deliver the service, and therefore knowing the effort to achieve, to estimate the ROI of this service.

Yes, it is true that I had forgotten that. Anything else?

The possible integration with other technologies. Sometimes a client will also wish to conduct tests for Java code or PL/SQL. In this case, the composition of the technical team may vary.

Thank you Walter. There are many other issues to be addressed in connection with the use cases, but as this post is already too long, we will leave these issues for the next article. See you next week.

This post is also available in Leer este articulo en castellano.