ABAP Cloud - Deprecation Flow

Table of contents

• Introduction
• Preparation
• Release
• Deprecation
• Successor
• Workflow
• Visibility
• Complete example
• Conclusion

How can you handle interfaces and objects used in the system easily and cleanly? In this article, we will look at the current object lifecycle within ABAP Cloud.

 

Introduction

In ABAP Cloud, we work heavily with Software Components, or SWC for short, and release our objects between the components via so-called contracts. Anyone in the system can then use these released APIs. In doing so, we enter into a contract that the object will remain stable. This should help us avoid changes that break existing code, such as:

• Deleting methods
• Extending existing methods with new mandatory parameters

 

You can find out more about "Stable ABAP APIs" in Lars Hvam's SAP Community Post.

 

Preparation

For the demonstration, we first create two simple objects in the system. We create a utility class to return the current timestamp.

CLASS zcl_bs_demo_timestamps DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES zif_bs_demo_timestamps.
ENDCLASS.


CLASS zcl_bs_demo_timestamps IMPLEMENTATION.
  METHOD zif_bs_demo_timestamps~get.
    GET TIME STAMP FIELD rd_result.
  ENDMETHOD.
ENDCLASS.

 

Every class also has a corresponding interface so that we can create a testable object straight away. In the interface we define the type, the method and also store documentation with ABAP Docs.

INTERFACE zif_bs_demo_timestamps
  PUBLIC.

  TYPES td_timestamp TYPE timestampl.

  "! Get current timestamp in TIMESTAMPL format
  "! @parameter rd_result | Actual timestamp
  METHODS get
    RETURNING VALUE(rd_result) TYPE td_timestamp.
ENDINTERFACE.

 

Release

So that we can now use the object outside of our SWC, we first have to release it. To do this, we call up the object and switch to the "Properties" view and the "API State" tab. 

 

We create a new contract using the plus (+) button. If you want to use the object in ABAP Cloud, leave the checkbox at "Use in Cloud Development". If you also want to use the class in the key user apps, you can also set the flag for "Use in Key User Apps".

 

Finally, a check is carried out to see whether the object can be released accordingly and an assignment is made to a corresponding transport request. Finally, we can find the new contract for the object on the "API State" tab.

 

We now repeat this process for the class, but here we receive a corresponding message that the instantiation should be set to PRIVATE. You can resolve this message with a factory or a factory method.

 

Finally, we use the class and have it return a timestamp that we can output. We can use the class in all SWCs because it has a C1 contract.

DATA lo_timestamp TYPE REF TO zif_bs_demo_timestamps.

lo_timestamp = NEW zcl_bs_demo_timestamps( ).
out->write( lo_timestamp->get( ) ).

 

Deprecation

Now, during the course of using an object, the time comes when you, as a developer, want to modernize, expand or make the object available again. In such a case, however, you will not change the existing object, as it is still used in existing code and you do not want to endanger stability. In such a case, we resort to the deprecation flow, thereby giving the user the signal that the API used is outdated.

 

Successor

To do this, we first develop the new API in the system. In our example, we no longer want to use the old timestamp, but instead set it to UTCLONG. To do this, we define the following interface:

INTERFACE zif_bs_demo_utc_timestamps
  PUBLIC.

  TYPES td_timestamp TYPE utclong.

  "! Get current timestamp in UTCLONG format
  "! @parameter rd_result | Actual timestamp
  METHODS get
    RETURNING VALUE(rd_result) TYPE td_timestamp.
ENDINTERFACE.

 

In the second step, we implement the new class and in this case use the UTCLONG_CURRENT function to get the current timestamp.

CLASS zcl_bs_demo_utc_timestamps DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES zif_bs_demo_utc_timestamps.
ENDCLASS.


CLASS zcl_bs_demo_utc_timestamps IMPLEMENTATION.
  METHOD zif_bs_demo_utc_timestamps~get.
    rd_result = utclong_current( ).
  ENDMETHOD.
ENDCLASS.

 

Finally, don't forget to make the new objects available as an API and create the C1 contract (as in the previous steps).

 

Workflow

Now we have to set the current objects to obsolete. To do this, we go back to the object in the "Properties" view. Use the "Edit" Button we can edit the current contract again.

 

To do this we set the status (release state) of the object to "Deprecated".

 

In the next step we can now specify one or more successors. Here we can search for our new interface and save it. In the "Concept Name" field you can enter a comment or an entire concept using free text.

 

After the contract has been updated, we can find the current information listed under "API State".

 

We repeat this process for the class, set it to Deprecated and enter the successor.

 

Visibility

Finally, let's take a look at the class that uses our released API. What information does the user receive from the IDE? As soon as we open the class, we receive two warning messages in the code:

 

The message also refers us to the new interface or the new class.

 

Hint: In addition, there is also a check in the ABAP Test Cockpit, with which we can control whether outdated APIs can also be used or whether they should go through the exception process.

 

Complete example

Here again the complete class that uses our deprecated API. This will make it easier for you to recreate the example in this system.

CLASS zcl_bs_demo_use_depr_flow DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.
ENDCLASS.


CLASS zcl_bs_demo_use_depr_flow IMPLEMENTATION.
  METHOD if_oo_adt_classrun~main.
    DATA lo_timestamp TYPE REF TO zif_bs_demo_timestamps.

    lo_timestamp = NEW zcl_bs_demo_timestamps( ).
    out->write( lo_timestamp->get( ) ).
  ENDMETHOD.
ENDCLASS.

 

Conclusion

The Deprecation Flow helps you manage released objects in the system and shows other developers which objects can be used without problems or which objects are now obsolete.