ABAP RESTful Application Programming Model (RAP)

Una aplicación RAP se ensambla a partir de capas, cada una de ellas un objeto de repositorio independiente:

1. Modelo de datos: CDS view entities sobre tablas de base de datos. Una entidad raíz y sus entidades hijas, vinculadas mediante composiciones, forman el business object, por ejemplo una solicitud de compra con sus posiciones.
2. Behavior definition (BDEF): declara lo que el business object puede hacer: crear, actualizar, eliminar, actions, validaciones, determinations, bloqueo, control de concurrencia y draft.
3. Behavior pool: una clase ABAP que implementa las partes personalizadas que declara la behavior definition, como una validación que rechaza las solicitudes por encima de un límite.
4. Capa de proyección: projection views y una behavior definition de proyección que exponen solo lo que necesita un servicio concreto.
5. Service definition: enumera las entidades que expone un servicio.
6. Service binding: elige el protocolo (OData V2, OData V4 o InA) y la categoría, UI o Web API, y publica el servicio. Una vista previa muestra el resultado como una aplicación SAP Fiori elements.

Cada capa tiene una sola función, y así es como RAP mantiene separados el modelo de datos, el comportamiento y la exposición en un único business object ABAP.

El tipo de implementación en la behavior definition decide quién escribe el código transaccional:

• Managed: el framework RAP gestiona las operaciones estándar de creación, actualización y eliminación, el buffer transaccional y el guardado en las tablas persistentes. Los desarrolladores solo añaden lógica de negocio: validaciones, determinations y actions.
• Unmanaged: los desarrolladores implementan ellos mismos cada operación y la secuencia de guardado, normalmente llamando a código de aplicación existente que ya gestiona la persistencia.

Existe una tercera variante para el código más antiguo: los business objects construidos con el modelo predecesor ABAP Programming Model for SAP Fiori (BOPF) pueden migrarse a business objects RAP basados en BOPF. SAP señala que estos no son business objects RAP nativos y no están habilitados para ABAP Cloud.

Criterio de decisión: elija managed cuando el business object es propietario de sus tablas, como una nueva aplicación personalizada en Alder Manufacturing; elija unmanaged cuando una lógica heredada probada deba reutilizarse en lugar de reescribirse. RAP managed reduce el código; RAP unmanaged protege las inversiones existentes.

RAP ha crecido release a release, por lo que la disponibilidad depende de la funcionalidad, no solo del modelo:

SAP S/4HANA Cloud Public Edition recibe las funcionalidades con la cadencia de la nube, y Private Edition sigue el release on-premise sobre el que se ejecuta. SAP ERP (ECC) no incluye RAP: los releases de ABAP Platform que lo incorporan, a partir de 7.53, solo se entregan con SAP S/4HANA. Las tablas de funcionalidades de RAP BDL de SAP indican el release de cada elemento del lenguaje, y comprobarlas para el release de destino es el primer paso de cualquier diseño RAP.

ABAP Cloud es el modelo de desarrollo de SAP para un ABAP preparado para la nube y estable ante las actualizaciones: solo API liberadas, una versión de lenguaje restringida y herramientas basadas en Eclipse. RAP es el modelo de programación que ABAP Cloud utiliza para las aplicaciones y los servicios transaccionales.

• En el SAP BTP ABAP environment y en la extensibilidad para desarrolladores de SAP S/4HANA Cloud Public Edition, RAP es la forma de construir aplicaciones y API transaccionales.
• En Private Edition y on-premise, RAP puede usarse con las reglas de ABAP Cloud, disponibles a partir de SAP S/4HANA 2022 (ABAP 7.57), o en ABAP clásico. La elección determina qué objetos SAP puede usar el código.
• El strict mode en una behavior definition impone las buenas prácticas actuales, como usar CDS view entities como fuentes de datos.

RAP no está, por tanto, ligado a SAP BTP: el mismo modelo se ejecuta dentro de SAP S/4HANA. ABAP Cloud aporta las reglas; RAP aporta la estructura.

Los puntos fuertes de RAP son reales. Un único modelo va desde la base de datos hasta la UI de SAP Fiori elements; el bloqueo, el control de concurrencia y el draft provienen del framework en lugar de código escrito a mano; los servicios se mantienen estables ante las actualizaciones cuando se construyen sobre API liberadas; y el mismo business object puede servir a una UI y a una API.

Sus límites se derivan de dónde se ejecuta:

• Solo ABAP. RAP requiere conocimientos de ABAP, ABAP Development Tools y un sistema ABAP; los equipos que no los tienen se enfrentan a una curva de aprendizaje real.
• Un solo sistema. Un business object RAP es transaccional dentro de un único sistema ABAP. Los procesos que abarcan varios sistemas necesitan integración o eventos por encima.
• Ligado al release. Una funcionalidad documentada para la nube puede llegar a on-premise solo con un release posterior.
• Flexibilidad de UI mediante anotaciones. Las aplicaciones generadas con SAP Fiori elements son tan flexibles como los floorplans y sus puntos de extensión.

RAP es la opción más sólida cuando la lógica y los datos pertenecen al sistema ABAP; no está diseñado para la orquestación entre sistemas.

1. Exponer directamente la capa base. Sin una capa de proyección, cada cambio en el servicio afecta al business object principal.
2. Elegir unmanaged por costumbre. Unmanaged tiene sentido cuando se reutiliza lógica heredada; para tablas nuevas, managed ahorra la mayor parte del código.
3. Vincular una aplicación SAP Fiori a un servicio Web API. Los bindings Web API no incluyen metadatos de UI, por lo que la aplicación muestra tablas vacías o diseños predeterminados. Use un binding UI.
4. Construir sobre vistas CDS basadas en DDIC. Son obsoletas, y el strict mode espera view entities.
5. Ignorar las tablas de funcionalidades. El código copiado de un tutorial de la nube puede no activarse en un release on-premise más antiguo.

La mayoría de los problemas con RAP son decisiones de capas y de release tomadas demasiado pronto, no errores de programación.