Por qué la herramienta con la que llevas veinte años integrando SAP ya no es la primera opción —y qué la sustituye
Si has integrado algo contra SAP en las últimas dos décadas, casi seguro escribiste el nombre de una BAPI. BAPI_BANK_GETLIST, BAPI_SALESORDER_CREATEFROMDAT2, BAPI_PO_CREATE1… eran la puerta de entrada: estables, documentadas, omnipresentes. Tan asentadas que para muchos equipos “integrar con SAP” y “llamar a una BAPI” eran la misma frase.
Eso está cambiando, y no por moda. Bajo el paradigma Clean Core, SAP está moviendo el desarrollo ABAP hacia los Business Objects del RAP (ABAP RESTful Application Programming Model), con CDS y EML por debajo. Las BAPIs no desaparecen de golpe, pero dejan de ser el punto de partida recomendado.
Lo esencial, en 3 puntos:
- Qué cambia: el desarrollo ABAP moderno se apoya en Business Objects de RAP (CDS + comportamiento), no en BAPIs sueltas.
- Por qué: Clean Core exige usar APIs liberadas (released) con contrato de estabilidad. La mayoría de las BAPIs no lo son.
- A quién obliga: en SAP Public Cloud es obligatorio. En Private Cloud y On-Premise es opcional, pero recomendado.
Contenido
Qué es el Clean Core (y por qué afecta a tu código)
“Clean Core” (núcleo limpio) es la estrategia de SAP para que el sistema central de S/4HANA se mantenga estándar, actualizable y limpio de modificaciones. La idea: cuanto menos toques el núcleo y más te apoyes en interfaces oficiales y estables, más fácil será actualizar y migrar a la nube.
El problema histórico es conocido. Durante años, el ABAP custom accedía a tablas y módulos internos sin garantía de que SAP no los cambiara en el siguiente upgrade. Clean Core ataca eso: separa lo que es API pública y estable de lo que es detalle interno que puede cambiar sin avisar. Para hacerlo medible, SAP clasifica los objetos estándar por niveles:
En SAP, released (liberado) no es decorativo: es un compromiso contractual de mantener la interfaz estable. El ABAP Test Cockpit (ATC) marca con prioridad los usos de objetos no liberados, para que sepas cuánta deuda técnica acumulas antes de un upgrade.
El dato incómodo: la mayoría de las BAPIs no son “Level A”
Si la regla es “usa solo objetos liberados”, ¿dónde quedan las miles de BAPIs de siempre? El Cloudification Repository de SAP —el inventario oficial de objetos liberados para ABAP Cloud— da una respuesta poco halagüeña.
Según el análisis publicado en la comunidad de SAP (datos de mayo de 2026 para SAP Cloud ERP Private), de los casi 3.800 módulos de función BAPI*, apenas ~23 son Level A (plenamente liberadas). El resto se reparte entre Classic API (~2.360), no liberadas (~120) y sin API (~440).
Léelo dos veces: de casi cuatro mil BAPIs, apenas dos docenas alcanzan el grado máximo de cumplimiento. El resto sigue funcionando —especialmente en Private Cloud y On-Premise—, pero ya no es lo que SAP recomienda para desarrollo nuevo. No es que las BAPIs “estén mal”: pertenecen a otra era arquitectónica, la de las llamadas RFC puntuales sin un modelo de datos unificado detrás.
Qué las sustituye: el Business Object de RAP
El sustituto no es “otra BAPI mejor”, sino un cambio de modelo. Un RAP Business Object no es una función suelta, sino una entidad de negocio completa definida en dos capas:
En lugar de una BAPI para crear, otra para modificar, otra para leer y otra para listar —cada una por su cuenta—, tienes un único objeto de negocio que reúne datos y operaciones, con sus validaciones y consistencia transaccional integradas.
Para consumirlo desde ABAP, SAP usa el EML (Entity Manipulation Language), un subconjunto del propio ABAP, type-safe (con verificación de tipos):
- Leer → READ ENTITIES (o SELECT sobre la CDS).
- Modificar → MODIFY ENTITIES, que cubre CREATE, UPDATE, DELETE y acciones.
- Persistir → COMMIT ENTITIES.
La gran diferencia con la BAPI: el EML te da acceso directo y tipado al objeto sin necesitar una UI Fiori ni una Web API por medio. El mismo Business Object sirve para la app Fiori, para una Web API OData y para tu código de integración. Una sola fuente de verdad, tres consumidores.
Un ejemplo concreto: el maestro de bancos
Las cuatro BAPIs clásicas del maestro de bancos mapean casi directo al Business Object moderno:
Pero lo interesante es lo que solo existe en el Business Object: funcionalidad nueva. Quien se queda en las BAPIs clásicas no usa solo una herramienta más vieja: se pierde funcionalidad que ya solo se publica por la vía moderna.
¿Obligatorio o recomendado? Depende de dónde corras
SAP Public Cloud → obligatorio. Solo puedes usar objetos liberados (Level A). Si no está released, no lo tocas. El desarrollo va sí o sí por RAP.
Private Cloud y On-Premise → opcional, pero recomendado. Las Classic APIs siguen siendo utilizables y nadie te apaga la BAPI mañana. Pero SAP recomienda migrar por la funcionalidad nueva que ya solo aparece en los Business Objects, por las validaciones alineadas con Fiori, y porque cada línea escrita hoy en RAP es una línea que no reescribirás cuando toque ir a la nube.
Truco práctico: antes de integrar nada, consulta el Cloudification Repository Viewer y mira el estado del objeto para tu versión exacta de SAP. Y deja que el ATC te marque la deuda técnica de lo que ya tienes: sus prioridades son tu hoja de ruta de migración.
Este giro no es aislado: es la misma dirección que ADT para VS Code (con foco en RAP) y el ABAP MCP Server. El mensaje de SAP es coherente de punta a punta: el futuro asistido por IA se construye sobre ABAP Cloud, RAP y Clean Core, no sobre tablas internas y BAPIs sueltas.
Conclusión
Las BAPIs no se mueren mañana, sobre todo en On-Premise y Private Cloud. Pero han dejado de ser el punto de partida. Bajo Clean Core, lo que SAP te pide —y en Public Cloud te obliga— es pensar en Business Objects: modelo de datos en CDS, comportamiento en su Behavior Definition y acceso tipado con EML. Una entidad de negocio completa, en lugar de un puñado de funciones sueltas.
Así que la pregunta honesta no es “¿tengo que tirar mis BAPIs?”. Es: ¿cuánto de tu próximo desarrollo vas a escribir todavía mirando al pasado, y cuánto ya en RAP, donde va a estar todo lo demás?
Fuentes: SAP Community — ABAP development under the Clean Core paradigm · SAP Help Portal (Entity Manipulation Language, Business Object, Public Released APIs) · Cloudification Repository Viewer (SAP). Verificadas en junio de 2026.
Artículo elaborado por el equipo de formación de Logali Group con base en datos oficiales SAP de 2026.LAU.

