From a purely technical point of view, the interface layer for ABAP RESTful application programming model (RAP) business objects and the business object interfaces based on it are a special behavior definition with the interface type.
You use a business object interface if you want to release your business object, for example, for use in other software components or for expandability via stability contracts. Business object interfaces aren’t required if cross-component access isn’t intended. In this post, we describe the interface layer for RAP business objects in more detail.
Structure of a Business Object Interface in SAP
Business object interfaces are provided by SAP. A business object interface consists of two parts: a CDS projection view with the addition provider contract transactional_interface and a behavior definition with the implementation type interface. Transactional CDS views are the stable public interface layer in a CDS data model. In the context of the ABAP RESTful application programming model, they are used to lay the foundation for a RAP business object. However, transactional CDS views have a limited range of functions and only support projecting elements and associations from the projected entity. These CDS views are identified with the addition provider contract transactional_interface. The addition of release contracts C1 (system-internal use) and optionally C0 (expandability contract) is recommended.
The special feature of a business object interface is that, unlike a managed or unmanaged business object, a RAP business object is a business object without behavior implementation. Such a business object only contains a subset of elements and the behavior of a RAP business object. This RAP business object can’t be used directly, but must be called via a business object interface. There can be several business object interfaces (cardinality [0,*]) for a RAP business object to meet different requirements and use cases.
A business object interface is therefore an additional abstraction layer between a RAP business object and its business service projection layer (see figure below). With business object interfaces, you can ensure that the stable and secure consumption of the business service is technically decoupled from the behavior and data model of the underlying RAP business object. The interface layer specifies a subset of elements or behaviors from a RAP business object, such as fields, actions, or validations. These are consolidated and prepared for the business object consumer. The additional abstraction layer between the RAP business object and its business service projection layer makes it possible to guarantee a stable lifecycle.
The business object interfaces can be released for certain API statuses (e.g., release contract C1—system-internal use). The prerequisite for this is that a released business object interface fulfills certain stability criteria and complies with change and development constraints. These constraints and specifications ensure the lifecycle and update capability. Due to the separation of the basic RAP business object and business object interface, stronger restrictions apply at the business object interface level (depending on the release status), but other elements that are only contained in the basic RAP business object remain unaffected by these restrictions and can be changed without affecting the runtime of applications. Because a business object interface only serves as a consolidated consumption view for a basic RAP business object, it doesn’t have its own runtime handler or its own behavior implementation. All incoming requests are delegated to the underlying RAP business object and its behavior implementation.
To make a business object interface available to consumers, it must be released with the release contract C1 (system-internal use) and the Use in Cloud Development visibility. SAP uses this visibility in a similar manner in the virtual data model (VDM). The layer below a released business object interface, the RAP business object, can’t be addressed or consumed directly, but must always be addressed via the released business object interface.
Each extension of a behavior definition is based on a business object interface that is used to access the implementation of the original RAP business object. An extension of a behavior definition to the original business object technically extends the basic behavior definition, but is consumed at runtime via the business object interface.
Business object interfaces are used in the ABAP RESTful application programming model to decouple the requirements for the stable consumption of a business object from the underlying data model and its behavior. For the annotations, this means that annotation changes in the basic data model must not have any effect on the data model in the interface projection layer and the layers above it. The annotation @Metadata.ignorePropagatedAnnotations: true is therefore used in the header area of a business object interface. This annotation prevents annotations from the underlying data model from being propagated further through the CDS view stack, which would potentially affect projections based on the business object interface. Annotations that are to take effect in higher-level projections should be explicitly defined in the CDS projection view.
Using Business Object Interfaces
For the consumer of a business object interface, it’s irrelevant whether it’s a business object interface or a RAP business object; access takes place in the same way. Business object interfaces can therefore be consumed in two different ways:
- You can access business object interfaces with the entity manipulation language (EML).
- You can provide a business object interface as a business service. To do this, you must create a projection layer above the business object interface and create a separate business service for consumption via OData within this layer.
Using Business Object Interfaces as New BAPIs
As part of ABAP Cloud, SAP provides successor objects for the previous Business Application Programming Interfaces (BAPIs) for numerous business objects. These successor objects are usually business object interfaces.
There are two ways to check whether there is a successor object for your specific application. First, you can try to open a BAPI that you normally use in ADT. On the Properties tab of the object, navigate to the API State area. If a successor object exists, this object will be displayed there in the Successors field. The figure below shows this using BAPI_MATERIAL_ SAVEDATA.
This BAPI was previously used to create or change material master data. With ABAP Cloud, SAP has introduced a successor to this BAPI. The successor object is the business object interface I_ProductTP_2. However, the successor objects for a BAPI aren’t always stored directly in its properties, which is why you’ll learn about another way of determining a successor object later in this section.
In the Use in Cloud Development field, you can see that the business object interface I_ProductTP_2 is released for use within ABAP cloud development. However, the object isn’t intended for key user extensibility apps and is therefore not released.
If you’ve previously created material masters using the BAPI, working with the business object interface in the future will mean a change for you. To make this change and the use of business object interfaces easier for you, SAP provides documentation for each business object interface in the form of a Knowledge Transfer Document (KTD). You can open this document directly from the behavior definition of the business object interface by clicking on the Open Documentation link.
In the next figure, you can see the documentation for the business object interface, I_PRODUCTTP_ 2. The documentation consists of two sections: The hierarchical structure of the business object interface with all entities, standard operations, actions, and associations is displayed on the left-hand side of the documentation window. On the righthand side, you can see a detailed description of the individual structural elements. For instance, an example is used to explain how you can call the update operation of the business object interface using EML. In addition, you receive information on which authorizations are required for this operation.
The successor objects for a BAPI aren’t always stored directly in its properties on the Properties tab. For this reason, we now introduce another option for determining successor properties. You can use the ADT to define an ABAP Repository tree. You can set filters in this ABAP Repository tree to select the objects with successors. To do so, proceed as follows:
- Open the context menu of your ABAP project, and select New _ ABAP Repository Tree.
- Select the Released Objects template.
- Now you need to define the filter settings for the ABAP Repository tree. In the Property Filter field, set the value to api:USE_IN_CLOUD_DEVELOPMENT type:BDEF, as shown below. Then, click on Finish.
This setting provides you with an ABAP Repository tree that lists all business object interfaces released for ABAP cloud development. The result is displayed here.
Conclusion
Business object interfaces play a central role in the ABAP RESTful application programming model by providing a stable, decoupled access layer to RAP business objects. They serve as the modern successors to traditional BAPIs, enabling consistent, cloud-ready interactions while safeguarding the integrity and lifecycle of the underlying data models. By defining clear stability contracts and separating consumption from implementation, business object interfaces ensure that developers can extend, consume, and maintain applications without disrupting core business logic. As SAP continues its evolution toward ABAP Cloud, understanding and leveraging these interfaces will be key to building robust, upgrade-safe solutions that align with SAP’s clean core strategy.
Learn Full Stack SAP Development in Our Rheinwerk Course!
SAP developers: Take ownership of your projects with full stack development. Grow your skills and master the backend and the frontend. In this course, you’ll learn to use the ABAP RESTful application programming model, core data services, OData, and SAP Fiori elements to develop applications from end to end. Level up today! Get access to course recordings by clicking the banner below.
Editor’s note: This post has been adapted from a section of the book ABAP RESTful Application Programming Model: The Comprehensive Guide by Lutz Baumbusch, Matthias Jäger, and Michael Lensch. Lutz has worked as an SAP developer since 2000 and has been responsible for international SAP projects in various roles and areas. Matthias is a freelance full-stack ABAP developer, architect, and trainer. Michael leads a team of SAP developers at All for One Group SE.
This post was originally published 11/2025.
Comments