Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
larshp
Active Contributor
In this blog post, let's look at APIs inside an ABAP system. A API in ABAP can be seen as a set of ABAP objects, for simplicity take DOMA + DTEL + TABL + TTYP + CLAS + INTF as an example.

I consider changes to an API to be stable if the changes in the API do not cause errors in the ABAP programs that consume the API.

 

Consistency


The set of objects in the API must be consistent, all objects referred must also be considered part of the API.

Example: The following interface refers to DTEL MANDT, which refers to DOMA MANDT, both being part of the definition for the "moo" method, and thus should be considered part of the API.
INTERFACE zif_bar.
METHODS moo IMPORTING iv_mandt TYPE mandt.
ENDINTERFACE.

The consumer of an API must be able to lookup all the details by looking just at the API, nothing more, nothing less.

 

Implementation code


Method implementation code is not part of the API, it is up to the provider of the API to have any implementation, which can change independently of the consumer.

Example: This implementation code refers to TABL T000, but its implementation code so not part of the API provided by CLAS ZCL_BAR
CLASS zcl_bar DEFINITION.
PUBLIC SECTION.
INTERFACES zif_bar.
ENDCLASS.

CLASS zcl_bar IMPLEMENTATION.
METHOD zif_bar~moo.
DATA impl TYPE t000.
ENDMETHOD.
ENDCLASS.

 

Use of the API is possible


If an interface is part of the API, the consumer must be able to implement the interface. Likewise, if a method is part of the API, a consumer must be able to call the API.

This easily follows if the API is consistent, but as ABAP is a large language, it takes effort to catch everything that should be part of the API.

 

Building new APIs


When building new APIs consider the following:

INTF should not reference CLAS objects, do proper OO design and define interfaces properly.

Don't add Function Groups/Function Modules as part of an API, function modules have been considered obsolete for many years.

 

Stable changes


Following changes(and more?) are possible to make while keeping the API stable,

DOMA

  • Compatible type changes, for example: extending a field from 20 characters to 30 characters


DTEL

  • Changing to a type compatible domain

  • Changing descriptions, it will not break the consumer programs


TABL

  • Adding fields


TTYP

  • Type compatible changes


INTF

  • New optional parameters in methods


CLAS

  • New methods

  • New optional parameters in methods


 

Unstable changes


 

DOMA + DTEL

  • Incompatible type changes


TABL

  • Removing fields

  • Renaming fields

  • Incompatible type changes


TTYP

  • Setting a new table key


INTF

  • New methods(might cause syntax error in consumer implementations)

  • Removing methods

  • Removing mandatory method parameters

  • Adding INTERFACES


CLAS

  • Removing methods

  • Removing mandatory method parameters


 

And I probably missed a lot of details, comments welcome below 🙂

 
17 Comments
Labels in this area