Published at January 4, 2021by Jörg Brandeis

Introduction

In this series of articles, I address a topic that is relevant to every BW/4HANA project: the implementation of customer exit variables. There is a lot of uncontrolled growth here, and in most older BW systems things look pretty chaotic. This is true even when someone has developed a "framework" for outsourcing the code.

The title suggests that in BW/4HANA, in contrast to classic BW, something might be different. Unfortunately, that is not the case; the title was chosen for marketing reasons only. ;-) Unfortunately, SAP missed the opportunity to choose an alternative concept here with BW4.

There is one advantage in many BW/4HANA projects, however, namely that they are greenfield projects. This means there is a chance to do things better right from the start than they were in the old predecessor system.

Overview of the individual topics

This series consists of the following posts. It is best to read through the topic from front to back.

A well-known topic

Many other authors (and consultants) have already dealt with these problems, and they have arrived at approaches of varying elegance. For example

• Tobias Meyer in his blog with a custom BAdI filtered on the variables
• Thorsten Kessler in his blog with articles about
  • The BAdI RSROA_VARIABLES_EXIT_BADI
  • The coexistence of BAdI and EXIT
• Denis Reis describes a function module based approach in this article

This is only a small selection of the articles on this topic. Above all, it shows: there is room for optimization here. And this also matches my experience from several large BW/4HANA projects.

The perspective of a developer

Since I previously worked as an ABAP developer and development manager in product development, I have a different understanding of quality and clean, maintainable code than developers who mostly work on customer projects. In particular, I have significantly more experience than many BW consultants, for whom ABAP development represents only a very small part of their daily work.

In my recent projects, however, this experience from ABAP product development has proven very helpful. Because when it goes beyond the individual variable exits or a single transformation routine, especially when concepts and frameworks are needed, the topics of clean code, unit tests, maintainability, and reliability play a major role.

From this perspective, I would like to make a proposal for a truly clean design pattern for the implementation of customer exit variables. It takes into account the principles of modern software development, in particular clean code and test-driven development. But it should also simply provide practical benefits, especially a lot of transparency in the daily work with the variables. Among other things

• Decoupling of the variable code so that as few dependencies as possible exist. This way, changes cannot affect the entire system.
• Dependencies between the variables are moved out of the code into customizing. This makes them clearly visible.
• Common logic is developed only once and can be reused without risk.
• Similar logic can be reused via parameters. The parameterization, in turn, is clearly visible.
• Standard tasks are handled with helper methods, which makes the code of the individual variables simpler and more stable.
• Every implementation of a customer exit variable can be verified with ABAP unit tests.

But first I will start with an analysis of the situation. Why is there so much uncontrolled growth, what are the causes, and what can we learn from it? I address these questions in the article Problems with customer exit variables