After an interruption due to the reorganization of the blog – I hope you enjoy the new interface – we continues our series on the analysis of ABAP code.
We saw last time how to set up our first analysis of ABAP code with Sonar and Jenkins.
This week, we will examine the firsts ABAP rules, at least the most critical in terms of good programming practices.
Pains of the ABAP world
What are the defects most feared by most companies? What are the bad programming practices that pose the greatest risk to their business? What are the main concerns of the project leaders and stakeholders? In short, what are the pains in the ABAP world?
- Anything that can stop a transaction.
- Anything that can impact performance.
Do not forget that SAP is a financial software, and an error in the processing of an operation means, at best a delay and at worst a financial loss, and in all cases a very bad image. If you are not even able to bill correctly, edit an order or manage properly your inventory without error, how do you want people to have confidence in your company, your products, your staff.
In addition, SAP is the preferred ERP of big companies: the amount of data collected and handled in the context of their activity is extremely high, and ABAP programs often manage several tables with several millions of rows. The performance is a real concern, and all the good practices of SQL programming will dominate our panel of ABAP rules.
Quality Profile
So I will create a Quality Profile a little different from the Sonar one that comes with the ABAP plugin, in order to highlight the most critical rules in terms of robustness and performance.
To do this, I’ll connect ‘Admin’ in Sonar, and configure a new Quality Profile. I pass on the way forward, you should already know and if not, it is very intuitive. You can also see this post ‘Quality Profile’, about the creation of a Quality Profile. That’s for Cobol rules, but the principle is the same.
Here is the result:
I created a ‘ABAP JPF Profile’ with 51 rules. I have enabled ABAP 11 rules that were simply optional in the default ‘Sonar way’ Quality Profile, because they are not used by all customers. But I find them interesting, they are useful in the context of an audit, and if a project team tells me they are not part of their quality model, it will always be possible to disable them or degrade their criticality .
Error management
I then launched an analysis of some code I use to make demos. Here are the main blocking rules or Blockers in SONAR.
Two rules identify incorrect handling errors: ‘Avoid calling a function module without handling exceptions’ and ‘Handle error codes when using CALL FUNCTION’.
Errors happen, no one is immune from an erroneous algorithm, a case not provided, etc. A module without exception handling means an interruption of the corresponding transaction. The user might not be able to finalize the current operation, with all the possible consequences: data corruption ‘blank page’, etc.. In the worst case, he will not even know that an error has occurred.
The second rule identifies a call to a function whose return code is not processed. This is incorrect in all languages, and indicates a ‘bad practice’ unfortunately quite common. Most ABAP applications are outsourced to providers, sometimes offshore, and you do not know what is the level of knowledge of their teams. So if you have treatments without management of the code return, you forbide to put in production the corresponding program and you ask your provider that he immediately corrects this defect.
And to give some formation to his programmers to learn this good practice, if you find a large number of them. However, even when this rule is known, the lack of attention is always possible that will cause such violations.
For your information, the return code is the parameter ‘SY-SUBRC’, as we can see when looking at the code line where the defect is located.
What? Did I forget to tell you that you could go down to the line of code where is the violation? And yes, no need to search the error in hundreds of lines of code, SONAR will take you there immediately. Handy when it comes to check it, or for the programmer who must make the correction.
Achtung Verboten !
The other two rules cover instructions strictly prohibited.
‘Forbid use of SYSTEM-CALL’ identifies a call to the SAP core. It is absolutely forbidden because in an upgrade of SAP version (which happens quite regularly), the called treatment may disappear and thus the corresponding program will stop working.
This rule is well known, and I did not find any violations in the ABAP code that I have. So I created my own program ‘Z_SYSTEM_CALL’, with 38 copies of this instruction, all with a different syntax.
And I can check the previous list of Blockers that SONAR has recognized these 38 different syntaxes, and there is no false-positive or parsing errors.
The ‘BREAK-POINT’ instruction does interrupt a program immediately. It is actually used to debug it. Its presence in the code simply means that the programmer forgot to remove it once its development is complete. If you want to put shame on an outsourcer, show him a ‘BREAK-POINT’ in the version that he just delivered. I usually meet 1 or 2 (or more) in an application.
The Blockers we have seen correspond to zero tolerance defects. They must be corrected immediately, no exception is allowed and this code will not be installed in production. Some may consider that incorrect exception handling is certainly serious but not blocking, but I see pretty often the management of the return code in the top 5 Blockers for most customers that I know.
We will see in the next post critical rules about performance.
This post is also available in Leer este articulo en castellano and Lire cet article en français.