ABAP OO - Constant interface

Table of contents

• Constants
• Administration
• Interface
• Advantages
• Conclusion

In this article we will show you another and beautiful use of constants via global, lightweight interfaces that you can use over and over again. How do you set up such libraries and manage them with little effort? We want to show you that in this article.

 

Constants

Why do we use constants and what are they used for? The question can be answered very quickly, because we use constants at this point where we keep using the same (constant) values in literals. Here you can name a True or False value as an example, for this there are already constants such as ABAP_TRUE and ABAP_FALSE in the system.

In many places in the system you will also find domains with fixed values. You can then address and use such values in your class or in your report. As an example, such a domain:

 

Administration

Where are such constants generally managed? Mostly in the classes or reports where they are used. In many cases, they are therefore not located in a central location, but separately in the current object. As a result, if the values are changed or new values are added, not all calling positions are adjusted or found.

A remedy is therefore provided by a global object that accepts and manages the constants. A class or an interface can come into question here. We recommend a lighter weight interface, as only definitions for the constants are required. You should also avoid wanting to integrate all constants into one object, this has the disadvantage that changes to central objects are difficult to manage and transport. In addition, an overhead of constants is loaded each time it is used, which you probably don't need at runtime.

 

Interface

Let's take a look at the domain from above and define a constant interface as an example:

INTERFACE zif_bs_c_demo_status PUBLIC.
  CONSTANTS:
    "! Status - Inititalized
    c_initialized TYPE zbs_demo_status VALUE '',

    "! Status - Finished
    c_finished    TYPE zbs_demo_status VALUE 'X',

    "! Status - New
    c_new         TYPE zbs_demo_status VALUE '1',

    "! Status - In Progress
    c_progress    TYPE zbs_demo_status VALUE '2',

    "! Status - In Test
    c_test        TYPE zbs_demo_status VALUE '3'.
ENDINTERFACE.

 

The interface only contains constants for the ZBS_DEMO_STATUS domain, so the names no longer have to be particularly cryptic, but can describe the content. You can store a corresponding ABAP Doc for each constant to explain the constant or its use in more detail. The constant interface has a naming convention with which you can find all of your interfaces using the search. With _C_ we mark an interface with constants and at the end of the name we list the domain from which the values originate.

We would therefore briefly list the following key points for a constant interface:

• Uniform convention for constant interfaces
• Constants for a maximum of one element
• Description with ABAP Doc

 

Advantages

What benefits can you get from working in this or a similar way? Here is a short list of the positive aspects of the method:

• Constants only maintained once in the system
• Central management and use of the values
• Proof of use via values
• Easy exchange and refactoring

 

The where-used list in particular can help you keep the system under control. If you ever get a request where a certain account or a certain company code is used, you can show this with a short proof of usage without having to start the code scanner.

 

We started a where-used list for the entire interface and received all call points for all constants and the interface itself. This makes research a little easier.

 

Conclusion

Managing constants centrally and easily is not a big challenge, it just requires a little discipline and the necessary rules. If the prerequisites are met, then working with constants is even more fun, because things are much easier to find in the system and the next time you query, you know where the objects are used.