How to: Understand ABAP Code and Identify Dependencies Faster

Abstract — This article examines challenges and offers solutions in the area of ABAP programming, which serves as the central programming language in the SAP environment. The first part explains the most important aspects around ABAP, including its role in controlling and extending business processes in organizations and the variety of ABAP objects. Then, typical challenges in dealing with ABAP coding in large companies are described, such as non-transparent dependencies, historically grown code structures, lack of modularity, as well as the risk of unplanned adaptations. Finally, special emphasis is placed on the deployment of automated add-on tools that increase transparency and efficiency in ABAP development. A use case shows how these tools help to analyze and document code structures and dependencies more quickly and precisely.

1. Understanding ABAP Coding: Definition, Classification and Associated Objects

ABAP (Advanced Business Application Programming) is a programming language developed by SAP that is mainly used for the development of applications in the SAP environment. With SAP being the world’s leading company for business software, ABAP is one of the main languages when it comes to controlling and expanding business processes within applications.

Although ABAP was originally procedural, today it also supports object-oriented programming, similar to Java or C++. This makes it easier to implement modern software development principles.

In a large company, the number of ABAP objects (programs, classes, function modules, reports, modules, etc.) can run into tens of thousands. This includes:

• Reports: Programs that are used for retrieving, processing and displaying data (more information can be found here)

• Function Modules: Reusable modules in ABAP that encapsulate specific tasks and are called in programs (more information here)

• Forms: User-defined forms such as invoices or delivery bills.

• Enhancements: User exits, BAdIs (Business Add-Ins) and other mechanisms for customizing the SAP standard.

2. Mastering Challenges in ABAP coding

Development teams in large companies often struggle with non-transparent dependencies due to the abundance of ABAP coding. This results in errors, increased data model complexity, difficult maintainability and risks during system updates. Below, we’ll explain how these dependencies come about in the first place:

a) Avoid Missing or Insufficient Documentation

One of the most common causes of non-transparent dependencies is inadequate or non-existent documentation. In many projects, the focus is placed on the development of functionality, while the documentation aspect is neglected. However, it is essential to record for “posterity” how different programs, modules and data structures are linked together. Without clearly defined requirements, assigned responsibilities and the continuous updating of documentation, it becomes difficult to recognize dependencies, because: Reverse engineering across multiple system types is extremely time-consuming.

b) Managing Historically Evolved Code

SAP systems and their ABAP codes often exist for many years and are continuously adapted and extended. Over time, more and more user-defined functions, quickly implemented solutions, workarounds and enhancements are created that were originally intended to respond to short-term requirements. Old modules/programs continue to be used even though new solutions exist and changes are sometimes made without taking the overall system into account. As a result, these “evolved” structures are no longer clearly traceable, especially if different internal and external developers or teams have worked on the same programs over the years.

c) Consider Re-use and the Lack of Modularity

In ABAP development, global data and functions are often used that are integrated in many different programs. If developers use global classes, database tables or function modules without defining a clean modularization and clear interfaces, close dependencies arise between different parts of the system. Copying code instead of using common modules also leads to this. These dependencies are often difficult to recognize and are not always documented.

d) Avoid Unplanned and Uncoordinated Adjustments

In larger SAP installations, several developers or teams often work on different data structures and functions at the same time. If these adjustments are made without clear coordination or communication, no versioning is available or code review processes are missing, dependencies can arise that those involved are not aware of. These dependencies then remain opaque until they become apparent due to an error or problem.

e) Correctly Regulate the Use of Dynamic and Indirect Calls

In ABAP, it is possible to use dynamic program calls and indirect accesses to implement generic solutions (e.g. dynamic function calls or SELECTs to tables whose names are only determined at runtime). Metadata or tables are also sometimes used at runtime to control program sequences. Such techniques can be useful for developing flexible solutions, but they make the code less comprehensible. Without clear references to the dependent modules, it becomes more difficult to understand which programs or data structures are actually being used.

f)  Mind the Close Connection Between User-defined and Standard SAP Components

“User exits”, “enhancements” or “modifications” to extend the SAP standard are commonplace. These user-defined developments (Z programs, enhancements) are often strongly linked to the SAP standard. When changes are made to the standard (e.g. through an SAP upgrade or a support package), unforeseen dependencies can arise because the programs are closely interlinked in a way that is not transparent. The close links between user-defined enhancements and the SAP standard can be difficult to understand.

g) Do Not Neglect Tests and Quality Controls

If the code is not sufficiently tested or checked, dependencies can be overlooked. Tests, especially unit and integration tests, often uncover hidden dependencies caused by changes in a module or program. If such tests do not take place or are inadequate, these dependencies remain undetected for a long time and changes are put into production with errors. This aspect is therefore due to a lack of quality assurance processes.

3. Tool Support: Automated Transparency in ABAP Coding

As described above, the challenges with ABAP coding are many and varied and involve a lot of effort in terms of documentation, coordination and quality assurance. SAP add-on tools can automate these processes: They document, can quickly search and adapt the code, facilitate testing and offer collaboration functions for both internal and external stakeholders.

A specific use case will help you to visualize the use of such tools in everyday working life:

You are an ABAP developer. For some time now, you have been wondering why the record type for company code 2000 in table ACDOCA is always set to Planned. Unfortunately, you no longer have access to the original developers who implemented these processes because they have long since left the company. You are therefore faced with the challenge of determining the origin of the data in this table without any tips or documentation.

Instead of laboriously combing through the SAP BW backend and manually searching for the relevant ABAP objects, use an SAP add-on tool that can automatically search through metadata and put it into context. One such tool is our “System Scout” software, for example. Using its “ABAP Relations” function, you can analyze relationships between various ABAP objects and the ACDOCA table at the touch of a button. This is how you discover that the Z_UPDATE_ACDOCA program manipulates the ACDOCA table.

But you require even more information: It is important for you to know which ABAP objects trigger the data manipulation. Here, too, the tool offers a helpful function: the where-used list. It carries out this analysis for the program Z_UPDATE_ACDOCA and finds out that this program is referenced in the function module Z_FM_ACC:

Knowing where to look for the logic responsible for the record type plan will save you valuable time if you have a full to-do list and no documentation.

After the automated analysis of the source code, you also find out that a very old logic from 2012 always sets the record type for company code 2000 to planned.

Incidentally, apart from the use case listed in the classic ABAP environment, the “ABAP Relations” function also supports you in the BW environment. If a lookup scan is carried out in a BW data flow, the identified objects can then also be analyzed with “ABAP Relations”:

For example, you can see that the table ZSUPPLIER is manipulated by a program – namely Z_UPDATE_SUPPLIER:

In addition, identified tables of BW objects are displayed directly as BW objects. This ensures a better understanding and enables further interactions and analyses.

The functions of the System Scouts tool, in particular “ABAP Relations” and the where-used list, offer considerable advantages to ABAP developers who need to quickly understand complex data flows:

• They provide a quick overview of data manipulations and their origin, save time and increase the accuracy of analyses.

• By clearly displaying the relationships between different ABAP objects and tables, these functions create transparency and make work considerably easier.

• In addition, support in the BW environment makes the entire data flow analysis in SAP systems even more efficient and easier to understand.

P.S.: Nobody stays in their job forever – so don’t forget to document ABAP objects and their relationships for posterity. There is also an SAP add-on tool that automates this – the Docu Performer. It ensures that future ABAP developers no longer have to research, but can directly access detailed and up-to-date documentation.