Mastering SAP ABAP Interfaces: A Real-World Sales Order Scenario

Why Every ABAP Developer Needs to Master Interfaces

In the world of SAP, systems are more connected than ever. We no longer build monolithic applications that live in isolation. Instead, we create solutions that need to communicate with web portals, third-party APIs, legacy systems, and more. This is where SAP ABAP Interfaces become not just a feature, but a foundational concept for building robust, scalable, and maintainable applications.

An interface is like a contract or a blueprint for a class. It defines a set of methods that a class must implement if it agrees to use that interface. The interface itself contains no implementation code—only the method signatures (name, parameters, exceptions). This simple concept is the key to achieving polymorphism and decoupling your code.

The Real-World Scenario: A Universal Sales Order Processor

Imagine your company receives sales orders from three different sources:

• A modern public-facing Web Portal.
• An old internal Legacy System that generates flat files.
• A new Mobile App used by the sales team.

All these orders must be created in SAP using the `BAPI_SALESORDER_CREATEFROMDAT2` BAPI. Without interfaces, you might create three separate reports or function modules. If the core BAPI logic changes, you have to update it in three places! This is inefficient and error-prone. Let's solve this elegantly with an interface.

Step 1: Define the Contract - The Interface

First, we define an interface, let's call it ZIF_SALES_ORDER_PROCESSOR. This interface will have one method, CREATE_SALES_ORDER. Any class that claims to be a sales order processor must have this method.

INTERFACE zif_sales_order_processor PUBLIC.

  " This is the contract. Every implementing class must create this method.
  METHODS create_sales_order
    IMPORTING
      iv_source_system TYPE string
      it_source_data   TYPE STANDARD TABLE
    RETURNING
      VALUE(rs_result) TYPE bapireturn.

ENDINTERFACE.

Step 2: Build the Concrete Handlers - The Implementing Classes

Now, we create a separate class for each data source. Each class will implement our ZIF_SALES_ORDER_PROCESSOR interface. This forces each class to have a CREATE_SALES_ORDER method, but the logic inside that method will be specific to the data source.

Class for the Web Portal: ZCL_WEB_PORTAL_HANDLER

This class will handle data coming from the web portal, likely in a structured format.

CLASS zcl_web_portal_handler DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES zif_sales_order_processor.
ENDCLASS.

CLASS zcl_web_portal_handler IMPLEMENTATION.
  METHOD zif_sales_order_processor~create_sales_order.
    " Specific logic for web portal data.
    " 1. Map the incoming IT_SOURCE_DATA to the BAPI structures.
    " 2. Call BAPI_SALESORDER_CREATEFROMDAT2.
    " 3. Fill the RS_RESULT structure and return it.
    WRITE: / 'Processing order from Web Portal'.
    " ... BAPI call logic here ...
  ENDMETHOD.
ENDCLASS.

Class for the Legacy System: ZCL_LEGACY_SYSTEM_HANDLER

This class handles the flat file data from the legacy system.

CLASS zcl_legacy_system_handler DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES zif_sales_order_processor.
ENDCLASS.

CLASS zcl_legacy_system_handler IMPLEMENTATION.
  METHOD zif_sales_order_processor~create_sales_order.
    " Specific logic for legacy file data.
    " 1. Parse the flat file structure from IT_SOURCE_DATA.
    " 2. Map the parsed data to BAPI structures.
    " 3. Call BAPI_SALESORDER_CREATEFROMDAT2.
    " 4. Fill the RS_RESULT structure and return it.
    WRITE: / 'Processing order from Legacy System'.
    " ... BAPI call logic here ...
  ENDMETHOD.
ENDCLASS.

Step 3: The Main Program - The Power of Polymorphism

This is where the magic happens. Our main program doesn't need to know about ZCL_WEB_PORTAL_HANDLER or ZCL_LEGACY_SYSTEM_HANDLER. It only needs to know about the interface, ZIF_SALES_ORDER_PROCESSOR. We can create an object reference of the interface type and, based on the source system, assign the correct class instance to it.

REPORT zr_sales_order_main_handler.

PARAMETERS: p_source TYPE string DEFAULT 'WEB_PORTAL'. " Can be 'WEB_PORTAL' or 'LEGACY'

START-OF-SELECTION.

  DATA: lo_processor TYPE REF TO zif_sales_order_processor.
  DATA: lt_data      TYPE STANDARD TABLE OF string.
  DATA: ls_return    TYPE bapireturn.

  " This is the Factory part. It decides which concrete class to use.
  CASE p_source.
    WHEN 'WEB_PORTAL'.
      CREATE OBJECT lo_processor TYPE zcl_web_portal_handler.
    WHEN 'LEGACY'.
      CREATE OBJECT lo_processor TYPE zcl_legacy_system_handler.
    WHEN OTHERS.
      MESSAGE 'Invalid source system' TYPE 'E'.
  ENDCASE.

  " The magic! We call the method on the INTERFACE reference.
  " The program doesn't care which class is actually running.
  " It only knows that any class assigned to lo_processor WILL have this method.
  ls_return = lo_processor->create_sales_order(
    iv_source_system = p_source
    it_source_data   = lt_data
  ).

  IF ls_return-type = 'S'.
    WRITE: / 'Success:', ls_return-message.
  ELSE.
    WRITE: / 'Error:', ls_return-message.
  ENDIF.

The Unlocked Benefits

By using this interface-based approach, you have achieved:

• Decoupling: The main program (ZR_SALES_ORDER_MAIN_HANDLER) is not tightly coupled to the handler classes. It only knows about the interface contract.
• Flexibility & Extensibility: If we need to add the new Mobile App as a source, do we change the main program? No! We simply create a new class, ZCL_MOBILE_APP_HANDLER, that implements the ZIF_SALES_ORDER_PROCESSOR interface and add one more WHEN condition to our factory logic. The core processing call remains untouched.
• Testability: You can easily test each handler class in isolation, mocking the interface to ensure each component works perfectly on its own.

Conclusion

Interfaces are a cornerstone of modern, object-oriented ABAP. They allow you to write flexible, interchangeable, and maintainable code. By defining a clear contract, you can build complex applications where components can be swapped, extended, and tested independently, leading to a far more robust and future-proof system architecture.