Paradigma ABAP 1: del ABAP clásico a ABAP Cloud, RAP e IA

Seguidores Online » Redes Sociales » Paradigma ABAP 1: del ABAP clásico a ABAP Cloud, RAP e IA

El mundo SAP y, en particular, el desarrollo ABAP, está viviendo un cambio de era. Lo que durante décadas fue un lenguaje centrado en informes y personalizaciones sin demasiadas ataduras, se ha transformado en el núcleo de una estrategia cloud, de clean core y de integración con inteligencia artificial. Para cualquiera que programe en ABAP o gestione un sistema SAP, entender este nuevo paradigma no es opcional: es la diferencia entre seguir siendo relevante o quedarse anclado en el pasado.

El concepto de “paradigma ABAP 1” engloba esta transición: ABAP Cloud, SAP BTP, Steampunk, RAP, CAP, el modelo de tres capas (ABAP Tier Model) y la irrupción de SAP ABAP‑1 como modelo de IA especializado. Todo ello se suma a los fundamentos clásicos del lenguaje, a la orientación a objetos (ABAP Objects) y a la evolución hacia aplicaciones RESTful y Fiori. En las siguientes secciones vamos a desmenuzar todo este ecosistema con calma, con vocabulario claro y ejemplos conceptuales que se puedan aterrizar en proyectos reales.

Del ABAP clásico al ecosistema ABAP Cloud, BTP y Steampunk

Durante más de cuarenta años, ABAP ha sido la piedra angular de los sistemas SAP, desde R/2 y R/3 hasta ECC y S/4HANA. Originalmente, ABAP (Allgemeiner Berichtsaufbereitungsprozessor) nació como un lenguaje de informes parecido a COBOL, pensado incluso para que usuarios avanzados generasen reportes sobre bases de datos lógicas y tablas transparentes. Con el tiempo, el lenguaje se complicó, se institucionalizó la figura del desarrollador ABAP y el sistema estándar se llenó de ampliaciones Z que tocaban casi cualquier cosa.

Con R/3 y luego NetWeaver, ABAP se consolidó como 4GL de negocio, con acceso mediante Open SQL a diversas bases de datos, integración RFC con otros sistemas y un Workbench muy completo: SE38 para programas, SE11 para el diccionario, SE37 para módulos de función, SE24 para clases, SE80 como navegador de objetos, Screen y Menu Painter, etc. Sobre esta base se construyó un inmenso parque de código personalizado que hoy es, a la vez, un activo y un problema.

La llegada de S/4HANA y SAP BTP obliga a repensar este modelo. SAP apuesta por una arquitectura cloud, un core estándar lo más limpio posible y extensiones desacopladas. Aquí entra en juego el entorno ABAP Cloud y, con él, el famoso concepto de Steampunk, que pasó de ser nombre informal de la comunidad a etiqueta estratégica.

Steampunk es el entorno ABAP en SAP BTP que permite desarrollar extensiones side‑by‑side, es decir, aplicaciones y servicios en la nube que se conectan a S/4HANA sin incrustarse en el núcleo del ERP. Se ofrece como plataforma como servicio (PaaS), totalmente gestionada, con ABAP Cloud como modelo de desarrollo y un conjunto de APIs liberadas para interactuar de forma segura con los sistemas transaccionales.

Para los escenarios donde sí se requiere lógica “incrustada” en el propio S/4HANA Cloud, SAP ha introducido el llamado Embedded Steampunk: el entorno ABAP de S/4HANA Cloud que permite extensiones on‑stack, pero estrictamente gobernadas por las reglas de ABAP Cloud. Esto significa que el desarrollador pierde libertades históricas: no hay acceso directo a tablas no liberadas, no se modifican objetos estándar, no se usan comandos obsoletos ni módulos de función clásicos sin liberar. Todo debe pasar por APIs y puntos de extensión oficiales.

Clean core, restricciones y el modelo ABAP de tres capas (ABAP Tier Model)

El enfoque clean core es una de las grandes obsesiones de SAP en S/4HANA. El objetivo es sencillo de formular y duro de aplicar: mantener el núcleo del ERP sin modificaciones directas, de forma que las actualizaciones y upgrades se puedan aplicar de manera rápida y predecible, sin proyectos interminables para adaptar código Z invasivo.

El modelo clásico de extensibilidad (user exits, BAdIs antiguas, modificaciones directas del estándar) ha demostrado ser un cuello de botella para los upgrades. Cada salto de versión implicaba revisar cientos o miles de objetos, con costes y tiempos difíciles de justificar en un entorno donde la innovación cloud exige releases frecuentes.

Para los entornos S/4HANA On‑Premise y Private Edition, donde existe más flexibilidad, SAP propone el ABAP Tier Model, o modelo de extensibilidad de tres capas, que permite convivir código clásico con el nuevo paradigma ABAP Cloud, sin renunciar al clean core:

• Tier 1: ABAP for Cloud Development. Es la capa “limpia”, donde residen los nuevos desarrollos y extensiones modernos. Usa la versión restringida del lenguaje ABAP Cloud, solo permite objetos liberados (clases, interfaces, vistas CDS, APIs modernas) y se desarrolla típicamente en Eclipse ADT. No hay llamadas directas a tablas estándar no liberadas ni a BAPIs antiguas.
• Tier 3: ABAP clásico (legado). Representa todo el inventario de código tradicional: módulos de función, BAPIs antiguas, Dynpros, Web Dynpro, lógica Z histórica, tablas estándar no liberadas, etc. Desde Tier 1 está prohibido referenciar estos objetos directamente.
• Tier 2: capa puente o API enablement. Es la “pasarela” que conecta el mundo limpio (Tier 1) con el legado (Tier 3). En esta capa se crean wrappers e interfaces que encapsulan llamadas a ABAP clásico, exponiendo únicamente interfaces compatibles con ABAP Cloud.

La dinámica típica del modelo de tres capas se entiende bien con un ejemplo práctico: imaginemos que necesitamos seguir usando una BAPI clásica como BAPI_PR_CREATE para solicitudes de oferta, pero queremos que la lógica de negocio nueva viva en ABAP Cloud.

En Tier 2 se define una interfaz OO (por ejemplo, ZIF_WRAPPER_PR) cuyo contrato respeta las restricciones ABAP Cloud: tipos liberados, firmas limpias, sin referencias directas a tablas o tipos no permitidos. A continuación, se crea una clase wrapper (ZCL_WRAPPER_BAPI_PR) que implementa esa interfaz y, dentro de sus métodos, llama a la BAPI clásica de Tier 3, mapeando parámetros de forma controlada.

Para instanciar el wrapper desde Tier 1 se diseña una clase factory (ZCL_WRAPPER_FACTORY_PR) con un método estático que devuelve una referencia a la interfaz. La factory crea la instancia de la clase wrapper real, pero desde Tier 1 solo se ve la interfaz. La interfaz y la factory se marcan con el estado de API adecuado (por ejemplo, contrato C1 “Use in Cloud Development”) para que el entorno ABAP Cloud las acepte.

En Tier 1, el código ABAP Cloud solo interactúa con la interfaz liberada, sin conocer que por debajo se está llamando a una BAPI antigua. Así se mantiene el código nuevo limpio, y cuando SAP libere una API moderna equivalente, será posible sustituir la implementación interna del wrapper sin reescribir la lógica de negocio de la capa superior.

Los Software Components son clave para reforzar estas reglas. Asociando los paquetes de Tier 1 a componentes configurados para ABAP Cloud, el sistema y Eclipse ADT realizan chequeos estrictos: no dejan usar tablas sin liberar, módulos de función clásicos ni sentencias prohibidas. Los paquetes de Tier 2, en cambio, se asocian a componentes “clásicos”, donde sí se permite ABAP completo para hablar con el legado.

RAP y CAP: modelos de programación modernos en el paradigma ABAP 1

Una de las grandes preguntas para los clientes actuales de SAP es: “¿con qué modelo de programación desarrollo ahora?”. SAP responde básicamente con dos pilares: CAP (Cloud Application Programming Model) y RAP (RESTful Application Programming Model), que se reparten el territorio según la tecnología de base.

CAP está orientado a desarrolladores que prefieren estándares abiertos como Node.js o Java. Proporciona un marco de servicios y modelos de datos para crear microservicios y aplicaciones cloud sobre SAP BTP, ideal cuando la lógica no tiene por qué estar en ABAP y se quiere aprovechar el ecosistema de herramientas de desarrollo no propietario.

RAP, en cambio, es el modelo estratégico para la comunidad tradicional ABAP. Es la evolución natural del lenguaje hacia un entorno RESTful, preparado para SAP HANA y para el consumo desde SAP Fiori, tanto en S/4HANA On‑Premise como en ediciones Cloud y en el entorno ABAP de BTP.

Con RAP se construyen objetos de negocio transaccionales listos para la nube, encapsulando datos, comportamiento y exposición como servicio OData (v2 o v4). La arquitectura se basa en:

• Modelado de datos con Core Data Services (CDS), definiendo entidades, asociaciones, proyecciones y anotaciones para la interfaz de usuario y la capa de servicio.
• Definición de comportamiento, donde se declara qué operaciones soporta el objeto (crear, actualizar, borrar, acciones, validaciones, determinaciones, borradores, numeración automática, etc.).
• Implementación del comportamiento en clases ABAP (Behavior Pool), usando ABAP moderno y Entity Manipulation Language (EML) para gestionar las operaciones sobre entidades.
• Definiciones de servicio y service bindings, que determinan qué entidades y comportamientos se exponen y bajo qué protocolo (UI, API web, OData v2/v4).

RAP distingue claramente entre modelado de datos, comportamiento y exposición. Primero se eligen o crean las tablas de persistencia, luego se definen vistas CDS que representan el objeto de negocio (simple o compuesto, con relaciones principal‑detalle), después se especifica el comportamiento y, por último, se proyecta qué parte de ese objeto se expone a la interfaz de usuario o a APIs externas.

El modelo incluye además el concepto de objetos de negocio gestionados y no gestionados. En los gestionados, el propio framework RAP se encarga de buena parte del tratamiento estándar (CRUD básico, borradores, locking, etc.), y el desarrollador se concentra en validaciones y determinaciones. En los no gestionados, la lógica transaccional se implementa manualmente, lo cual tiene sentido para escenarios complejos o cuando se quiere reutilizar lógica existente en módulos de función o código clásico.

RAP también está pensado para jugar bien con la IA y la analítica embebida. Al estar optimizado para SAP HANA, permite integrar analítica en tiempo real, entrenamiento de modelos y consumo de resultados directamente desde las aplicaciones transaccionales, sin necesidad de duplicar datos en otros sistemas. Y al exponer servicios OData bien definidos, encaja como guante con SAP Fiori Elements, que genera interfaces estándar con mínima programación frontend.

Fundamentos clásicos de ABAP y ABAP Objects en el nuevo contexto

Aunque todo el foco esté ahora en cloud, RAP y BTP, no se puede entender el paradigma ABAP 1 sin los cimientos clásicos del lenguaje. ABAP es un 4GL estructurado que soporta tanto programación procedural como orientada a objetos (ABAP Objects), con una sintaxis muy marcada: cada sentencia termina en punto, las palabras clave no distinguen mayúsculas/minúsculas y el espacio en blanco tiene un papel importante.

El modelo de ejecución clásico diferencia entre informes y module pools. Los informes son programas lista‑orientados, pensados inicialmente para mostrar datos pero que, en la práctica, también pueden modificarlos. Los module pools implementan diálogos complejos con pantallas (dynpros) y flujo lógico PBO/PAI. Además, existen programas no ejecutables como includes, subroutine pools, function groups, clases e interfaces e incluso type pools.

El diccionario ABAP (SE11) es el corazón de los metadatos del sistema. Define tablas (transparentes, pooled, clustered), índices, vistas, estructuras, elementos de datos, dominios, ayudas de búsqueda y objetos de bloqueo. Cuando un objeto del diccionario cambia, los programas que lo referencian usan automáticamente la definición nueva en la siguiente ejecución, sin recompilar, gracias a que ABAP se interpreta en tiempo de carga.

En cuanto a tipos de datos, ABAP ofrece enteros (I), decimales empaquetados (P), punto flotante (F), caracteres (C), numéricos (N), fechas (D), horas (T), hexadecimales (X), cadenas de longitud variable (STRING, XSTRING) y la posibilidad de declarar tipos basados en estructuras y tablas del diccionario. Las fechas y horas tienen la peculiaridad de poder tratarse tanto como enteros (número de días o segundos) como cadenas en formato YYYYMMDD u hhmmss, lo que simplifica muchas operaciones.

El salto conceptual llegó con ABAP Objects, la extensión orientada a objetos del lenguaje, introducida en la versión 4.6 y consolidada a partir de 6.10 con el Web Application Server. ABAP no es un lenguaje puramente orientado a objetos, pero permite combinar código procedural y OO en un mismo programa, lo que facilitó la transición progresiva.

En ABAP Objects, todo gira en torno a clases, objetos, interfaces, herencia y polimorfismo. Una clase define atributos y métodos; los objetos son instancias con estado, comportamiento e identidad propia. Las clases pueden ser globales (definidas con SE24 y reutilizables en todo el sistema) o locales (declaradas dentro de un programa).

La sección de definición de una clase se organiza en áreas de visibilidad: PUBLIC, PROTECTED y PRIVATE. Los componentes públicos son accesibles desde cualquier consumidor y subclases; los protegidos solo desde la propia clase y sus herederas; los privados exclusivamente desde la clase que los define. Este control de visibilidad es la base del encapsulamiento efectivo.

ABAP distingue también entre componentes de instancia y estáticos. Los atributos y métodos de instancia dependen de cada objeto, mientras que los estáticos existen una sola vez por clase y se comparten entre todas las instancias. Los constructores (CONSTRUCTOR y CLASS_CONSTRUCTOR) permiten inicializar el estado de instancia o de clase cuando se crea un objeto o se carga la clase por primera vez.

El lenguaje implementa eventos, manejadores y un modelo de excepciones basado en clases. Los eventos se disparan con RAISE EVENT y los métodos manejadores se registran con SET HANDLER; las excepciones se lanzan con RAISE EXCEPTION y se capturan con bloques TRY…CATCH…CLEANUP, donde las clases de excepción (cx_*) encapsulan información sobre la situación de error. Todo esto es muy relevante porque RAP y ABAP Cloud se apoyan precisamente en este modelo OO moderno.

La irrupción de SAP ABAP‑1 y Joule‑for‑Developers en el día a día del ABAPer

En paralelo a la transformación cloud, SAP ha querido capitalizar el auge de la inteligencia artificial posicionando su propio modelo de IA especializado en ABAP: SAP ABAP‑1. A diferencia de los grandes modelos de lenguaje genéricos, este se entrena sobre el gigantesco corpus de código ABAP del propio ecosistema SAP.

El objetivo de SAP ABAP‑1 es proporcionar un asistente experto en el lenguaje y en los patrones de desarrollo SAP, accesible vía herramientas como Joule‑for‑Developers. En la práctica, esto se traduce en ayuda para:

• Generación de código ABAP siguiendo buenas prácticas actuales (ABAP Cloud, RAP, uso de CDS).
• Creación de código “boilerplate” y casos de prueba repetitivos, liberando tiempo del desarrollador para lógica de negocio más fina.
• Refactorización y migración de código heredado a arquitecturas RAP y clean core, identificando usos prohibidos, proponiendo wrappers y patrones tier 2, etc.

Para los clientes SAP actuales, el valor añadido es enorme: gran parte del esfuerzo de modernizar un paisaje S/4HANA no está en lo funcional, sino en revisar, clasificar y transformar años de desarrollos Z. Tener una IA entrenada específicamente en ABAP puede reducir tiempos y errores en esa transición.

No obstante, también hay motivos para el escepticismo. SAP utiliza esta brillantez técnica como palanca comercial: cada vez más capacidades de desarrollo y modernización pasan por servicios de la SAP AI Foundation y modelos con licenciamiento premium. Esto refuerza el vendor lock‑in y preocupa a analistas e inversores, hasta el punto de que entidades como JP Morgan han señalado dudas sobre la estrategia de nube e IA de SAP, ligándolas a caídas puntuales en la cotización.

La presión para los equipos de TI y los ABAPers es doble: por un lado, deben reciclarse hacia ABAP Cloud, RAP, BTP y conceptos web modernos; por otro, aprender a convivir con asistentes de IA que automatizan partes del trabajo. Lejos de ser una amenaza inmediata, puede ser una oportunidad para subir de nivel, siempre que se asuma que el rol clásico de “programador ECC” se está agotando.

El futuro del desarrollador ABAP: entre cloud, open tech y reciclaje profesional

Una cuestión recurrente en la comunidad es qué va a pasar con los ABAPers. Con entornos como Cloud Foundry o Kyma en SAP BTP, es perfectamente posible desarrollar extensiones en Java o Node.js sin escribir una sola línea de ABAP. Incluso existiendo ABAP en la nube, muchos CIOs podrían preferir tecnologías abiertas con más talento disponible en el mercado.

La realidad a corto y medio plazo es que ABAP on‑premise seguirá vivo. La ola de migraciones de ECC a S/4HANA garantiza trabajo durante años: conversiones, reimplementaciones, remediación de código, proyectos de Brownfield y Greenfield. Pero es muy probable que, tras ese periodo, el peso de ABAP disminuya frente a desarrollos cloud en JavaScript, Java u otros lenguajes estándar.

Para muchos ABAPers, la estrategia razonable pasa por un “doble juego”: profundizar en ABAP Cloud, RAP y el modelo de tres capas para seguir siendo valiosos en el mundo SAP, y en paralelo abrirse a tecnologías web y abiertas. Aprender JavaScript en serio (no solo un curso rápido) permite acceder a React, Angular, Node.js y, por supuesto, SAPUI5 y Fiori, que no dejan de ser librerías y frameworks sobre JS.

Además de JavaScript, hay un conjunto de conocimientos transversales que se vuelven imprescindibles para un desarrollador SAP moderno:

• Manejo de CSS y maquetación para entender y ajustar el look&feel de aplicaciones web.
• Funcionamiento de APIs REST y servicios OData, incluidos conceptos como recursos, verbos HTTP, paginación, filtrado, etc.
• Protocolo HTTP, códigos de estado y manejo de errores, cookies, sesiones y mecanismos de autenticación (Basic Auth, OAuth, tokens).
• Arquitecturas cloud y patrones de integración, desde side‑by‑side extensibility hasta event‑driven architectures con SAP Event Mesh u otros brokers.

Este reciclaje no significa renunciar a la identidad ABAP, sino entender que ABAP se está redefiniendo como lenguaje regulado, orientado a servicios y respaldado por IA dentro de la plataforma BTP. El viejo “Z‑código anárquico” da paso a un rol de arquitecto y orquestador de objetos de negocio, APIs y servicios cloud.

En paralelo, el mercado de formación también se ha adaptado. Existen formaciones específicas en extensibilidad S/4HANA Cloud (clean core), cursos sobre ABAP Cloud y RAP, y contenidos prácticos sobre el modelo ABAP Tier Model, donde se enseña paso a paso a crear paquetes Tier 1 y Tier 2, interfaces, wrappers, factories y contratos de liberación C1 utilizando Eclipse ADT y Software Components configurados.

Mirando el conjunto, el paradigma ABAP 1 no es un punto final sino una reconfiguración profunda del ecosistema. ABAP sigue vivo, pero ahora vive en una nube altamente regulada, conectada a SAP BTP, guiada por principios de clean core, extendida con modelos de IA como SAP ABAP‑1 y estirada hacia servicios RESTful con RAP y CAP. Las empresas que se atrevan a reestructurar su forma de desarrollar y a invertir en esta transición mantendrán su competitividad digital en la era de la IA; las que se queden ancladas en el ABAP de siempre verán cómo su ventaja se erosiona poco a poco.