ABAP Cloud

SAP describe ABAP Cloud como una metodología de desarrollo formada por piezas que ya existían en la plataforma ABAP, combinadas bajo un único conjunto de reglas:

• ABAP CDS para modelos de datos y consultas analíticas.
• El ABAP RESTful Application Programming Model (RAP) para business objects transaccionales y servicios.
• ABAP for Cloud Development, una versión restringida del lenguaje que solo admite un subconjunto de sentencias ABAP; las pantallas dynpro clásicas, por ejemplo, no forman parte de ella.
• API de SAP y puntos de extensión liberados como única vía permitida para acceder a código y datos de SAP.
• ABAP Development Tools en Eclipse como IDE, con las ABAP development tools para Visual Studio Code como opción adicional.

Sobre esta base, el modelo ofrece servicios reutilizables como rangos de números, application jobs y un repositorio de UI para aplicaciones SAPUI5 y SAP Fiori elements. Por tanto, ABAP Cloud es un reglamento para usar ABAP moderno, no un nuevo lenguaje ni un runtime aparte.

El entorno ABAP de SAP BTP es un servicio de plataforma para el desarrollo ABAP side-by-side y a menudo se le llama por su nombre de proyecto interno en SAP, Steampunk. En SAP S/4HANA, el mismo modelo se ejecuta dentro del ERP, lo que el glosario ABAP de SAP denomina embedded Steampunk. En Private Edition y on-premise, cada objeto de desarrollo lleva una versión del lenguaje, de modo que un equipo puede crear objetos nuevos con ABAP Cloud mientras el código más antiguo sigue siendo clásico.

ABAP Cloud es la única opción ABAP en los productos de nube pública y la opción recomendada, junto al ABAP clásico, en todos los demás.

ABAP Cloud convierte las reglas de clean core en comprobaciones que se ejecutan mientras se escribe el código:

1. Cada objeto de desarrollo tiene una versión del lenguaje ABAP. Los objetos en ABAP for Cloud Development se comprueban en la verificación de sintaxis y en tiempo de ejecución.
2. La verificación de sintaxis solo acepta objetos de SAP liberados para el desarrollo en la nube con el contrato de liberación C1, además de los puntos de extensión liberados con C0.
3. SAP comprueba sus propios objetos liberados frente a su contrato de liberación, por lo que no se esperan cambios incompatibles en una actualización.
4. En Private Edition y on-premise, cuando falta una API liberada necesaria, la guía de SAP permite un wrapper escrito en ABAP clásico, liberado por el cliente con el contrato C1 y gobernado con comprobaciones de ABAP Test Cockpit.

En Alder Manufacturing, una aplicación de aprobación personalizada para el alta de proveedores creada de esta forma lee los datos de proveedores mediante vistas CDS liberadas, no mediante tablas de SAP. ABAP Cloud hace de la estabilidad ante actualizaciones una propiedad del compilador en lugar de una promesa de revisión de código.

• Actualizaciones predecibles. El código que compila bajo ABAP Cloud depende solo de objetos liberados, lo que reduce el trabajo de regresión en cada cambio de release.
• Un único modelo en todas las implementaciones. Los mismos conocimientos y patrones se aplican en el entorno ABAP de SAP BTP, en Public Edition y en Private Edition u on-premise.
• Conocimientos ABAP existentes. Los equipos conservan ABAP, los transportes y la gestión del ciclo de vida conocida en lugar de cambiar de lenguaje.
• Proximidad a los datos. El código ABAP Cloud on-stack se ejecuta junto a los datos y las transacciones de SAP S/4HANA, con una consistencia transaccional que una extensión remota no puede ofrecer.
• Camino integrado hacia SAP Fiori. Los servicios RAP alimentan directamente las aplicaciones SAP Fiori elements.

Para el ABAP personalizado que debe sobrevivir a los cambios de release, ABAP Cloud es el modelo de desarrollo en torno al cual están construidas las herramientas, las comprobaciones y la documentación de SAP.

• Limitado por las API liberadas. Si SAP no ha liberado un objeto, el código ABAP Cloud no puede usarlo. En Public Edition la brecha sigue abierta hasta que SAP libere una API; en los demás casos se cubre con wrappers que necesitan un responsable.
• Los patrones heredados quedan excluidos. Las pantallas dynpro clásicas y los reports con salida en SAP GUI no forman parte del modelo, por lo que el código existente rara vez se migra sin rediseño.
• Curva de aprendizaje. CDS, las behavior definitions de RAP y las herramientas basadas en Eclipse son nuevas para muchos desarrolladores de ABAP clásico.
• No es un proceso de gobierno. ABAP Cloud garantiza cómo depende el código de SAP; no decide qué construir, quién es su responsable ni cómo se vincula con un proceso de negocio.

ABAP Cloud asegura la dependencia técnica; el alcance, la responsabilidad y el encaje en el proceso siguen siendo decisiones aparte.

1. Tratar ABAP Cloud como un producto que hay que licenciar. Es un modelo de desarrollo; los productos son el entorno ABAP de SAP BTP y SAP S/4HANA.
2. Mezclar versiones del lenguaje sin un plan. En Private Edition, decida por componente de software qué objetos deben ser ABAP Cloud e impóngalo con ABAP Test Cockpit.
3. Crear wrappers por defecto. Un wrapper C1 es un puente para una API que falta; busque primero una API liberada.
4. Elegir la ubicación equivocada. Use ABAP Cloud on-stack cuando la lógica necesite consistencia transaccional con los datos de SAP S/4HANA; use el entorno ABAP de SAP BTP u otros runtimes cuando la extensión necesite su propio ciclo de vida.

El criterio de decisión es la dependencia: si la lógica debe modificar datos de SAP dentro de la misma unidad de trabajo, ABAP Cloud on-stack suele ser el lugar adecuado.