ABAP Obsolete - Function Module

Table of contents

• Introduction
• Problems
• Learning
• Object-Oriented Programming
• Global Area
• Architecture
• Usage
• Parallelization
• Background Processing
• RFC Scenarios
• Extensions
• Conclusion

In this article, we'll examine the use of function modules in modern development. Then we'll explore whether they are still needed.

 

Introduction

Especially in early development, function modules were the gold standard for encapsulating and separating code and functions within an SAP system. This is particularly evident in the historical use of numerous function modules and function groups to utilize SAP solutions and functions. The best example of this is the BAPI. This is a function module that provides standard interfaces and was originally developed by SAP with the idea of reusability within the SAP system. However, function modules also have their drawbacks. And we want to take a detailed look at these two aspects in this article.

 

Problems

Let's now look at some examples of problems that can occur if we still use function modules and function groups in our development and employ them to their full extent.

 

Learning

Young people and developers learning ABAP these days have a problem: simply too many topics, frameworks, and methodologies have been added in recent years that need to be learned. If you just take a look at the Learning Roadmap, you'll see how much new material has been added to the curriculum for a modern ABAP Cloud developer, all of which needs to be learned.

 

This doesn't even include the various topics like form technologies, interface technologies, and other things that are also found in a traditional system. This means that as a young developer, you either start learning all these topics from scratch, or you begin to select, perhaps with the help of a senior developer, which topics you still need. We would always recommend that you avoid certain overly complex topics. And one aspect of the complexity is learning about function groups and function modules, along with the global scope that a function group provides. It's best to keep things simple here and focus only on the function module and its implementation.

 

Object-Oriented Programming

During their studies and training, many young developers learn the concept of object-oriented development: inheritance, methods, various attributes, and everything else needed for object-oriented development. This is not reflected at all in SAP's function modules. Several concepts are missing here; basically, there are input and output interfaces similar to methods, but without instantiation, which creates a reusable object. This concept is therefore different, firstly, and secondly, it must be learned specifically for SAP, and the actual knowledge of object-oriented programming remains somewhat in the background.

 

Global Area

Because even the global area of a function group, which is usually filled with form routines, variables, and constants, can lead to problems in certain situations. For example, we have previously looked at how buffers can also lead to problems when using RFC function modules. Normally, one would assume: We open a new session when we call the function module again. But that is usually not the case; instead, we continue to use the old session, and global buffers can become a data problem here. More information can be found in the linked article about the problem and its background.

 

Architecture

We recently revisited the overall architecture and how it functions at the ABAP layer. Classes now form the basis of our architecture and all our code. Classes are used to implement unit tests. Other objects, such as reports or function modules, are essentially just wrappers that call the various methods of the classes. This has the advantage that we can reuse our code with the classes, make it testable, and cover it with local unit tests. And we run into fewer problems needing to understand function groups and global areas in more detail; instead, these simply call our functions, where we can then also build static variables and buffers in our classes.

 

Usage

So what about the use of function modules? Are they really still needed, or can we use other concepts instead? And what does SAP itself think about it?

 

Parallelization

Let's look at the classic example of parallelization. We have a huge package that we want to distribute across different processes to reduce processing time. We typically use parallelization for this, which in the past offloaded function module calls to different processes. This meant we were busy implementing the function module, the logic, and also had to handle the various processes. However, with ABAP Cloud, there's a class that only requires us to implement an interface or class and use it to perform parallelization. This means we don't actually need a function module anymore to implement parallelization in the system.

 

Background Processing

The same applies to background processing. Let's move away from the same LUW (Logical Unit of Work) and start a background process. While our user is already executing the next transaction or action in the system, their process continues to run in the background. To achieve this, we started our function module in a new session and let the processing continue there. Here, too, there's a new class in the ABAP Cloud environment, based on bgPF, which takes an instance of our function module, places it in the background, and performs the processing there. No function module is needed at this point either.

 

RFC Scenarios

Here we come to the first scenario where we still need a function module: the classic RFC scenario, when we provide interfaces using this technology. This is primarily used when we have SAP-to-SAP communication, as this is the simplest and fastest way to exchange data or call functions on another system. However, we would always recommend using the ABAP OO architecture and using the RFC function module only as a wrapper, calling a class inside it.

 

Extensions

Another way we can still encounter classic function modules is through system extensions. For example, there are BTEs and user exits, which rely on function modules or even require a function module to call. Basically, we create a function module with a fixed interface for this, but we still recommend that you also outsource the code.

 

Conclusion

It's not quite that simple to get rid of the function module and develop completely without it in the system. If you're still working with the standard or need to build interfaces, then you sometimes can't avoid using a function module. Generally, you shouldn't use it in custom developments where you can decide on the architecture yourself, and instead rely on well-known concepts, implementations, and frameworks.