The S/4HANA conversions, that are in full swing at many companies, make it particularly clear when programs have been poorly programmed in terms of maintainability. In this article, I would like to explain the importance of maintainability in the SAP environment.
Definition
The S/4HANA conversions, that are in full swing at many companies, make it particularly clear when programs have been poorly programmed in terms of maintainability. In this article, I would like to explain the importance of maintainability in the SAP environment.
The maintainability (or supportability or serviceability) of software is the ease with which a software system or a software component can be modified in order to correct errors, improve performance or other attributes or make adjustments to the changed environment.
This is very general and abstract.
However, Wikipedia sums it up very well in the next paragraph:
Maintainability is imperative
- the longer the planned period of use of the software is
- the less experts in the subject area are available
SAP programs have a very long period of use, and experts are often rare, as SAP programming requires not only technical knowledge, but often module knowledge as well. Developers are therefore not interchangeable. For this reason, it is essential that programs are created to a high level in terms of maintainability.
Key aspects
The following aspects apply generally when it comes to source code. In the chapter “Maintainability from an SAP perspective”, I will discuss what this means specifically in the SAP context.
- Readability of the Code: The code should be clear so that developers can easily understand it. Well-named variables, functions and classes as well as consistent help.
- Modularity: The application should be divided into independent components that can be developed, tested and maintained separately. This makes it easier to execute changes without affecting the entire system.
- Documentation: Good documentation that describes the code and its structure is crucial. This includes both inline comments and external documents that explain its purpose and how it works.
- Testing: Extensive testing, including unit tests, integration tests and system tests, is important to ensure that changes to the code do not lead to unintended errors.
- Flexibility and Expanadability: The code should be written in such a way that it is easily expandable. This means that new features or changes can be easily added without affecting existing functionality.
- Error handling and Logging: Robust error handling and meaningful logging mechanisms make it easier to debug and identify problems in the system.
Maintainability from an SAP perspective
In this chapter I will discuss specific challenges that my colleagues and I often encounter. I will try to show what tools are available and how particularly serious errors can be avoided.
Readability of the code
Opinions often differ greatly when it comes to the readability of the code. Starting with the discussion of whether Hungarian notation should be used or not. There is no uniform standard for “readability”, because what is clear and understandable for one person raises questions for another. There are still companies where object-oriented programming is undesirable because the company’s own developers do not have enough expertise with this method. You also need to get used to the new ABAP features.
Figure 1 Modern ABAP source code for converting one table into another
Indenting code also helps with readability. But here too, opinions differ as to when something is better or worse readable. In addition, some people find certain things annoying, whereas others don’t. Personally, I become annoyed when source code is not properly indented in a uniform manner.
The official SAP Style Guide, has been available since around 2020 and clarifies many questions. However, together with the open-source projects ABAPlint and ABAP Cleaner there are now good ways to generate uniform code. With the ABAP Cleaner, the entire source code can be formatted at the push of a button. Mit dem ABAP Cleaner kann der gesamte Quelltext auf Knopfdruck formatiert werden. The possibilities go far beyond those of the Pretty Printers. The configuration options are diverse and can be adjusted to your own wishes.
The technical possibilities for implementing code formatting according to generally accepted rules are now available and easy to use. But what advantages does the company have if code is formatted in a uniform and readable manner?
It is assumed that source code is read about ten times more often than it is written. In my opinion, the ratio is much higher, because when I’m programming, I read the source code several times and may only make minor changes. What I’m getting at is that readable code makes both analysis and programming easier. When errors occur, I want to be able to quickly and clearly identify what’s happening in the source code. Because if I can understand what’s happening in the code well, then I can usually act accordingly. However, if it’s unclear, then it delays understanding and error correction.
An important part of readable code is the use of descriptive and appropriate names for the individual objects (classes, methods, variables, etc.). Unfortunately, there is a restriction in the SAP system that limits the name length to 30 characters. This length is usually sufficient. However, sometimes it would be helpful if longer name methods could be used.
However, opinions differ here too. If I have an internal table called RETURNED_FAULTY_EQUIPMENTS, then on the one hand the name is descriptive, but on the other hand I always have to read or write this text. If this table is accessed frequently, it could be advantageous to just call the table EQUIS and to document in the data declaration which equipment is present in the table.
The following example should clarify what I am getting at. The following source code is “telling”:
Das hier aufgeführte Beispiel ist eher „technisch“:
Decide for yourself which is easier to read and how important this aspect is from a certain point of view.
Modularity
Robert C. Martin, one of the best-known advocates of clean code, recommends a maximum of 20 lines of code per method. In the SAP environment, this is rarely achieved. Just calling a BAPI, including the data declaration, often requires 40 lines or more. You should make sure that a program unit should only contain as much coding as necessary. This is often not the case with SAP programs and units of 1000 lines of coding are not uncommon. Unfortunately, SAP itself is not a good example here either.
Modularization is an important component in making programs more readable. Object orientation helps here because it enables short writing and the direct assignment of a value by using the RETURNING parameter.
When debugging program code, it is particularly helpful if the name already indicates what a module does. The following example clearly shows what happens:
The individual modules can be changed and tested separately. This makes it readable and robust against changes.
Another important aspect of modularization is the separation of data acquisition, business logic and interface.
Documentation
Documentation is a perpetually controversial topic. How much documentation is necessary? What needs to be documented and where is the documentation stored?
Every object (program, class, table, data element, etc.) can be documented in SAP. However, it is very laborious, as the integration of the Word editor often does not work smoothly. Additionally, it is not possible to include screenshots or other explanatory images. Links cannot be used without further ado either. The advantage, however, is that the documentation is located directly on the object in the SAP system and is therefore directly accessible.
The use of external programs, such as Word or Visio, is a much better way of documenting. However, this documentation must also be findable.
Inline documentation, i.e. the use of comments directly in the source code, is in any case essential. There are voices that claim that good source code does not need documentation, but I disagree. Useful comments are helpful for understanding a program.
Tests
Unit tests are still a rarity in the SAP world. In my opinion, this is because many SAP-specific functions are used, and database access is more or less always involved. Separating data selection, business logic and interface is complex. However, this effort is often not worth it if “just a few data are to be selected”, “a bit of calculation is done” and then the output is in the ALV grid. In my view, this is also legitimate. However, if this program is constantly being expanded, then you should not miss the right time to adapt the program architecture for the purpose of maintainability.
Everyone needs to experience and work out for themselves when it makes sense to use unit tests. With this knowledge in mind, a completely different program architecture results.
Creating unit tests is also a way of documentation. A developer can see which constellations are possible. If an error is corrected, you can use the test cases created to see whether they still produce the same result.
Static program checks can also help to make a program robust and maintainable. SAP provides the Code Inspector and ATC checks for this purpose. These tools help to prevent problems before they arise. Both tools can be configured individually. The simplest check is also the one that developers find least fun: checking whether the return code is requested after certain program units, such as function module calls or database operations.
Flexibility and expandability
If the above points have already been taken into account, there is a good chance that the code is flexible and can be easily extended. Good readability leads to a good understanding of the program logic. Modularization also means that the source code can be easily adapted. If the logic of SET_SENDER from the example above changes, the method can easily be swapped. A new function, such as ADD_DOCUMENT, can also be added.
If INTERFACES are used during development, entire classes can be replaced with new functionality.
Error handling and logging
Many programmers follow the happy path when programming and testing. The test data is selected so that all required program components are run through. After all, you want to be sure that all functions do what they are supposed to. In doing so, it is often overlooked that problems can arise at various points. Consistent error handling is therefore helpful.
In the worst case, when an error occurs, a user receives the message “An error has occurred” or even a short dump. If an error occurs frequently at this point, error handling must be more detailed. If an error is likely (the object to be processed is locked by another user), then an explanatory message with all the necessary information must be issued.
Writing data to determine errors or log activities is also an important part of maintainable programs. In the SAP system, the Business Application Log (BAL) is usually used for this. With this application, data can be written in a standardized way to a log and saved to the database if necessary. Log points can be used to log program processes. These are set in the program code and activated as required using the SAAB transaction. Dynamic log points can even be set. These do not have to be called in the program but can be set and activated in debugging.
Obstacles to maintainable programs
The maintainability of a program depends on many things. I have outlined some of them above. However, what exactly maintainability means can vary from case to case and from perspective. Depending on the use case, certain aspects need to be considered more than others. For an application that is run by many users every day and is frequently expanded, maintainability should be given particular attention.
If all of this is so important, why isn’t enough attention paid to maintainability when creating programs or making changes?
When creating an application, the most important thing is that the program works and meets the requirements. However, once it works, a developer doesn’t want to make any more changes because that could destroy the functionality that has just been created. In addition, short-term success is often more important than long-term maintainability.
To be fair, although there are techniques for creating potentially maintainable source code, it often only becomes clear later which maintainability aspects turn out to be important over time.
Another aspect that speaks against maintainability is time pressure. Bug fixes are usually carried out under great stress and deadline pressure. In this situation, there is no time for refactoring code and writing unit tests. Even if this is intended for the short term, once the bug has been fixed, the problem no longer exists, and maintainability is out of the question. In addition, it is not recorded how long a problem has been worked on. If this were done, it would be possible to see that bug fixes on certain programs take longer. The reasons could be determined here and counteracted with appropriate code improvements.
Conclusion
There is no standard or uniform procedure for writing maintainable applications. However, that should not prevent developers from working towards this goal to the best of their knowledge and belief. Experience is very important. However, many things are easy to implement and are more likely to challenge your inner demons. I have seen a number of programs where the creators did not even bother to delete superfluous comments or call up the Pretty Printer.
When it comes to programming, I also like the old Boy Scout saying coined by Lord Robert Baden-Powell, the founder of the Boy Scout movement:
Try to leave the world a little better than you found it.
