Desde un punto de vista puramente técnico, la capa de interfaz para los objetos de negocio del modelo de programación de aplicaciones (RAP) ABAP RESTful y el interfaces de objetos de negocio en base a esto hay una definición de comportamiento especial con el tipo de interfaz.
Utilice una interfaz de objeto de negocio si desea liberar su objeto de negocio, por ejemplo, para su uso en otros componentes de software o para su ampliación mediante contratos de estabilidad. Las interfaces de objetos comerciales no son necesarias si no se desea el acceso entre componentes. En esta publicación, describimos la capa de interfaz para RAP objetos comerciales con más detalle.
Estructura de una interfaz de objeto de negocio en SAP
SAP proporciona las interfaces de objetos comerciales. Una interfaz de objeto de negocio consta de dos partes: una vista de proyección CDS con el contrato de proveedor adicional transaccional_interface y una definición de comportamiento con la interfaz de tipo de implementación. Las vistas CDS transaccionales son la capa de interfaz pública estable en un modelo de datos CDS. En el contexto del modelo de programación de aplicaciones ABAP RESTful, se utilizan para sentar las bases de un objeto comercial RAP. Sin embargo, las vistas CDS transaccionales tienen una gama limitada de funciones y solo admiten elementos de proyección y asociaciones de la entidad proyectada. Estas vistas CDS se identifican con el contrato de proveedor adicional transaccional_interface. Se recomienda agregar los contratos de liberación C1 (uso interno del sistema) y, opcionalmente, C0 (contrato de ampliabilidad).
La característica especial de una interfaz de objeto de negocio es que, a diferencia de un objeto de negocio gestionado o no gestionado, un objeto de negocio RAP es un objeto de negocio sin implementación de comportamiento. Un objeto de negocio de este tipo sólo contiene un subconjunto de elementos y el comportamiento de un objeto de negocio RAP. Este objeto de negocio RAP no se puede utilizar directamente, sino que se debe llamar a través de una interfaz de objeto de negocio. Puede haber varias interfaces de objetos de negocio (cardinalidad [0,*]) para que un objeto comercial RAP cumpla diferentes requisitos y casos de uso.
Por lo tanto, una interfaz de objeto de negocio es una capa de abstracción adicional entre un objeto de negocio RAP y su capa de proyección de servicio de negocio (consulte la figura siguiente). Con las interfaces de objetos comerciales, puede garantizar que el consumo estable y seguro del servicio comercial esté técnicamente desacoplado del comportamiento y el modelo de datos del objeto comercial RAP subyacente. La capa de interfaz especifica un subconjunto de elementos o comportamientos de un objeto comercial RAP, como campos, acciones o validaciones. Estos están consolidados y preparados para el consumidor del objeto de negocio. La capa de abstracción adicional entre el objeto de negocio RAP y su capa de proyección de servicios de negocio permite garantizar un ciclo de vida estable.

Las interfaces de objetos comerciales se pueden liberar para ciertos estados de API (por ejemplo, contrato de liberación C1: uso interno del sistema). El requisito previo para esto es que una interfaz de objeto comercial liberada cumpla ciertos criterios de estabilidad y cumpla con las restricciones de cambio y desarrollo. Estas restricciones y especificaciones garantizan el ciclo de vida y la capacidad de actualización. Debido a la separación del objeto comercial RAP básico y la interfaz del objeto comercial, se aplican restricciones más estrictas en el nivel de la interfaz del objeto comercial (según el estado de la versión), pero otros elementos que solo están contenidos en el objeto comercial RAP básico no se ven afectados por estas restricciones y se pueden cambiar sin afectar el tiempo de ejecución de las aplicaciones. Debido a que una interfaz de objeto de negocio solo sirve como una vista de consumo consolidada para un objeto de negocio RAP básico, no tiene su propio controlador de tiempo de ejecución ni su propia implementación de comportamiento. Todas las solicitudes entrantes se delegan al objeto comercial RAP subyacente y su implementación de comportamiento.
Para que una interfaz de objeto de negocio esté disponible para los consumidores, debe liberarse con el contrato de liberación C1 (uso interno del sistema) y el Uso en el desarrollo de la nube visibilidad. SAP utiliza esta visibilidad de manera similar en el modelo de datos virtual (VDM). La capa debajo de una interfaz de objeto comercial liberada, el objeto comercial RAP, no se puede abordar ni consumir directamente, pero siempre debe abordarse a través de la interfaz de objeto comercial liberada.
Cada extensión de una definición de comportamiento se basa en una interfaz de objeto comercial que se utiliza para acceder a la implementación del objeto comercial RAP original. Una extensión de una definición de comportamiento al objeto de negocio original técnicamente extiende la definición de comportamiento básica, pero se consume en tiempo de ejecución a través de la interfaz del objeto de negocio.
Las interfaces de objetos comerciales se utilizan en el modelo de programación de aplicaciones ABAP RESTful para desacoplar los requisitos para el consumo estable de un objeto comercial del modelo de datos subyacente y su comportamiento. Para las anotaciones, esto significa que los cambios de anotación en el modelo de datos básico no deben tener ningún efecto en el modelo de datos en la capa de proyección de la interfaz y las capas superiores. Por lo tanto, la anotación @Metadata.ignorePropagatedAnnotations: true se utiliza en el área de encabezado de una interfaz de objeto comercial. Esta anotación evita que las anotaciones del modelo de datos subyacente se propaguen más a través de la pila de vistas CDS, lo que potencialmente afectaría las proyecciones basadas en la interfaz del objeto comercial. Las anotaciones que deben tener efecto en proyecciones de nivel superior deben definirse explícitamente en la vista de proyección CDS.
Uso de interfaces de objetos comerciales
Para el consumidor de una interfaz de objeto de negocio, es irrelevante si se trata de una interfaz de objeto de negocio o de un objeto de negocio RAP; el acceso se realiza del mismo modo. Por lo tanto, las interfaces de objetos comerciales se pueden consumir de dos maneras diferentes:
- Puede acceder a interfaces de objetos comerciales con el lenguaje de manipulación de entidades (EML).
- Puede proporcionar una interfaz de objeto comercial como servicio comercial. Para hacer esto, debe crear una capa de proyección sobre la interfaz del objeto comercial y crear un servicio comercial separado para el consumo a través de Odatos dentro de esta capa.
Uso de interfaces de objetos comerciales como nuevas BAPI
Como parte de ABAP En la nube, SAP proporciona objetos sucesores de las anteriores interfaces de programación de aplicaciones empresariales (BAPI) para numerosos objetos comerciales. Estos objetos sucesores suelen ser interfaces de objetos comerciales.
Hay dos formas de comprobar si existe un objeto sucesor para su aplicación específica. Primero, puedes intentar abrir una BAPI que normalmente usas en ADT. en el Propiedades pestaña del objeto, navegue hasta la Estado de la API área. Si existe un objeto sucesor, este objeto se mostrará allí en el Sucesores campo. La siguiente figura muestra esto usando BAPI_MATERIAL_SAVEDATA.

Esta BAPI se utilizaba anteriormente para crear o modificar datos maestros de materiales. Con ABAP Cloud, SAP ha presentado un sucesor de esta BAPI. El objeto sucesor es la interfaz de objeto de negocio I_ProductTP_2. Sin embargo, los objetos sucesores de una BAPI no siempre se almacenan directamente en sus propiedades, por lo que aprenderá sobre otra forma de determinar un objeto sucesor más adelante en esta sección.
En el Uso en el desarrollo de la nube puede ver que la interfaz de objeto de negocio I_ProductTP_2 está lanzada para su uso dentro del desarrollo de la nube ABAP. Sin embargo, el objeto no está destinado a aplicaciones clave de extensibilidad de usuarios y, por lo tanto, no se publica.
Si anteriormente creó maestros de materiales utilizando BAPI, trabajar con la interfaz de objetos comerciales en el futuro significará un cambio para usted. Para facilitarle este cambio y el uso de las interfaces de objetos de negocio, SAP proporciona documentación para cada interfaz de objetos de negocio en forma de Documento de transferencia de conocimientos (KTD). Puede abrir este documento directamente desde la definición de comportamiento de la interfaz del objeto de negocio haciendo clic en el Abrir documentación enlace.

En la siguiente figura, puede ver la documentación para la interfaz de objeto de negocio, I_PRODUCTTP_ 2. La documentación consta de dos secciones: La estructura jerárquica de la interfaz de objeto de negocio con todas las entidades, operaciones estándar, acciones y asociaciones se muestra en el lado izquierdo de la ventana de documentación. En el lado derecho puede ver una descripción detallada de los elementos estructurales individuales. Por ejemplo, se utiliza un ejemplo para explicar cómo se puede llamar a la operación de actualización de la interfaz del objeto comercial utilizando EML. Además, recibirá información sobre qué autorizaciones se requieren para esta operación.

Los objetos sucesores de una BAPI no siempre se almacenan directamente en sus propiedades en el Propiedades pestaña. Por este motivo, ahora presentamos otra opción para determinar las propiedades sucesoras. Puede utilizar el ADT para definir un Árbol de repositorio ABAP. Puede configurar filtros en este árbol del repositorio ABAP para seleccionar los objetos con sucesores. Para ello proceda de la siguiente manera:
- Abra el menú contextual de su proyecto ABAP y seleccione Nuevo _ Árbol de repositorio ABAP.

- Seleccione el Objetos liberados plantilla.

- Ahora necesita definir la configuración del filtro para el árbol del repositorio ABAP. En el Filtro de propiedad campo, establezca el valor en API: USE_IN_CLOUD_DEVELOPMENT tipo: BDEFcomo se muestra a continuación. Luego, haga clic en Finalizar.

Esta configuración le proporciona un árbol de repositorio ABAP que enumera todas las interfaces de objetos comerciales publicadas para el desarrollo de la nube ABAP. El resultado se muestra aquí.

Conclusión
Las interfaces de objetos comerciales desempeñan un papel central en el modelo de programación de aplicaciones ABAP RESTful al proporcionar una capa de acceso estable y desacoplada a los objetos comerciales RAP. Sirven como sucesores modernos de las BAPI tradicionales, lo que permite interacciones consistentes y listas para la nube al tiempo que salvaguardan la integridad y el ciclo de vida de los modelos de datos subyacentes. Al definir contratos de estabilidad claros y separar el consumo de la implementación, las interfaces de objetos comerciales garantizan que los desarrolladores puedan ampliar, consumir y mantener aplicaciones sin interrumpir la lógica empresarial central. A medida que SAP continúa su evolución hacia ABAP Cloud, comprender y aprovechar estas interfaces será clave para crear soluciones sólidas y seguras para actualizaciones que se alineen con la estrategia central limpia de SAP.
¡Aprenda el desarrollo completo de SAP en nuestro curso Rheinwerk!
Desarrolladores de SAP: tomen posesión de sus proyectos con desarrollo completo. Desarrolla tus habilidades y domina el backend y el frontend. En este curso, aprenderá a utilizar el modelo de programación de aplicaciones ABAP RESTful, servicios de datos centrales, OData y elementos de SAP Fiori para desarrollar aplicaciones de un extremo a otro. ¡Sube de nivel hoy! Obtenga acceso a las grabaciones del curso haciendo clic en el banner a continuación.
Nota del editor: esta publicación ha sido adaptada de una sección del libro. Modelo de programación de aplicaciones ABAP RESTful: la guía completa por Lutz Baumbusch, Matthias Jägery Michael Lensch. Lutz ha trabajado como desarrollador de SAP desde 2000 y ha sido responsable de proyectos internacionales de SAP en diversas funciones y áreas. Matthias es un desarrollador, arquitecto y formador ABAP full-stack independiente. Michael dirige un equipo de desarrolladores de SAP en All for One Group SE.
Esta publicación se publicó originalmente el 11/2025.

