API liberadas y SAP Business Accelerator Hub

Un objeto está liberado cuando su estado de liberación es Released bajo un contrato de liberación concreto, que define el uso permitido y los cambios que SAP evitará:

Un objeto Deprecated sigue funcionando, pero debe sustituirse por su sucesor; un objeto Decommissioned ya no tiene soporte, un estado que SAP aplica actualmente solo a las API remotas. Para los objetos C0 y C1, un ajuste de visibilidad decide si pueden usar el objeto los desarrolladores de ABAP Cloud, los key users o ambos.

Una API liberada es, por tanto, un compromiso sobre un objeto y una finalidad, no una etiqueta general para cualquier cosa que tenga una interfaz.

El SAP Business Accelerator Hub, antes SAP API Business Hub, es una aplicación web alojada por SAP. Cataloga API de SAP y de partners (OData, SOAP, REST), eventos de negocio, vistas CDS, data products, integration flows y process blueprints.

Para cada API, el hub muestra la especificación, la documentación y, en muchas API, un sandbox para probar llamadas antes de conectar ningún sistema. Un desarrollador de Alder Manufacturing que debe crear facturas de proveedor desde un portal externo empieza aquí: busca la API, consulta su estado y su sucesor, la prueba en el sandbox y luego descarga la especificación.

Hay dos límites importantes. El hub documenta las API estándar de SAP, no las específicas de cada cliente, y las API se listan por producto, de modo que una API listada para una edición no está automáticamente disponible en otra. El SAP Business Accelerator Hub es el punto de partida para el diseño de API remotas, no la prueba de que una API existe en un sistema determinado.

Las API liberadas se dividen en dos grupos prácticos:

• API locales (contrato C1). Vistas CDS, clases, behavior definitions y otros objetos liberados que usa el código ABAP personalizado del mismo sistema. El código ABAP Cloud solo puede llamar a estas. Los desarrolladores las encuentran en ABAP Development Tools, donde la pestaña API State muestra el estado y el contrato de liberación, y en la sección de extensibilidad para desarrolladores del Business Accelerator Hub.
• API remotas (contrato C2). Servicios OData, SOAP y de otro tipo que llaman a través de la red las aplicaciones de SAP BTP, el middleware o sistemas de terceros. Están documentadas en el Business Accelerator Hub.

Cuando SAP sustituye una API, la antigua pasa a estar obsoleta y se designa un sucesor; SAP declaró obsoleta la API OData Production Order en SAP S/4HANA Cloud 2008, por ejemplo.

La distinción determina la arquitectura: las API locales sirven a las extensiones on-stack construidas con ABAP Cloud, mientras que las API remotas sirven a las extensiones side-by-side y a las integraciones.

• SAP S/4HANA Cloud Public Edition: las API liberadas son la única vía de acceso. El código ABAP personalizado usa solo API liberadas locales, y las API remotas se exponen mediante communication scenarios que un administrador activa con un communication arrangement.
• Private Edition y on-premise: las API liberadas conviven con interfaces clásicas como las BAPI. Las API OData remotas se activan como los demás servicios OData en SAP Gateway, por ejemplo con /IWFND/MAINT_SERVICE para OData V2. Cuando no existe una API liberada, las directrices de SAP permiten wrappers personalizados alrededor de API clásicas de la lista, liberados con el contrato C1.
• SAP BTP ABAP environment: se aplican los mismos contratos de liberación, y los objetos personalizados usados entre software components están liberados o conectados mediante relaciones entre software components.

Los clientes solo pueden liberar sus propios objetos con los contratos C0 y C1. El concepto de API liberada es idéntico en todas las ediciones; lo que difiere es cuánto acceso no liberado sigue tolerando cada edición.

• Estabilidad ante actualizaciones por contrato. SAP verifica los objetos entregados frente a su contrato de liberación, por lo que no se esperan cambios incompatibles en una API liberada durante una actualización.
• Cumplimiento obligatorio, no solo recomendación. En ABAP Cloud, el compilador rechaza las llamadas a objetos que no están liberados para el desarrollo en la nube, lo que convierte la regla de clean core en una comprobación de sintaxis.
• Un vocabulario común. Los mismos estados y contratos se aplican en todas las ediciones de SAP S/4HANA y en el SAP BTP ABAP environment.
• Cambio planificado. La declaración de obsolescencia con un sucesor designado ofrece a los equipos una vía de migración en lugar de una interfaz rota.

Las API liberadas son la regla de dependencias sobre la que se apoya el nivel A de la clasificación de clean core.

• La cobertura es desigual. No todos los business objects ni todos los campos tienen una API liberada. Una queja frecuente en las comunidades de profesionales es encontrar la operación necesaria solo en una BAPI clásica o en una tabla interna.
• Un contrato no es un diseño. Una API liberada garantiza la estabilidad técnica, no que su granularidad se ajuste a un proceso; puede que se necesiten varias llamadas para un solo paso de negocio.
• El comportamiento todavía puede cambiar. Las reglas de contrato de SAP permiten cambios compatibles en las API liberadas y no prometen una compatibilidad descendente total, por lo que los consumidores deben volver a probar tras las actualizaciones.
• La obsolescencia es fácil de ignorar. Las API obsoletas siguen funcionando durante un tiempo, por lo que el cambio al sucesor tiende a retrasarse.

Las API liberadas eliminan el riesgo de actualización de la interfaz; el ajuste al proceso y el ciclo de vida de cada consumidor siguen siendo responsabilidad del equipo.

1. Suponer que todo servicio OData es una API. Un servicio OData generado para una aplicación SAP Fiori es un servicio de UI. Compruebe el estado de liberación antes de que una integración dependa de él.
2. Diseñar solo a partir del hub. Confirme que la API existe y está activada en el sistema y el release de destino.
3. Ignorar los avisos de obsolescencia. Haga seguimiento de los sucesores de cada API en uso.
4. Envolverlo todo. Los wrappers C1 personalizados alrededor de API clásicas cubren carencias; cada uno necesita un responsable y una revisión cuando SAP libera un sucesor.

El criterio de decisión práctico es sencillo: si el objeto no tiene un estado de liberación para el uso previsto, trate cualquier dependencia de él como deuda técnica y regístrela.