Modelo ABAP RESTful Application Programming (RAP)

¿Qué es RESTful Application Programming (RAP)?

El modelo ABAP RESTful Application Programming, desarrollado por SAP, está creado íntegramente sobre el lenguaje ABAP y sigue el marco de la transferencia de estado representacional (REST) para crear aplicaciones en una arquitectura cliente-servidor, con una interfaz uniforme para la manipulación de recursos.

El objetivo principal de RAP es permitir a los desarrolladores crear de manera eficiente aplicaciones empresariales listas para la nube que gestionen diferentes transacciones comerciales en forma de servicios OData estándar o crear extensiones para aplicaciones existentes sin modificar el código estándar actual.  Admite el desarrollo integral desde el modelado de datos hasta la exposición de servicios y el modo compacto con SAP Fiori UX.

RAP admite el desarrollo para diversas plataformas SAP, incluyendo SAP BTP ABAP para crear aplicaciones y extensiones nativas en la nube, así como SAP S/4HANA Cloud (ediciones pública y privada), que permite desarrollos personalizados compatibles con los ciclos continuos de innovación y actualización de la nube. RAP está disponible para SAP S/4HANA On-Premises desde la versión 1909, lo que permite a los clientes crear aplicaciones mediante prácticas modernas de desarrollo y a prueba del futuro.

RAP desempeña un papel fundamental en el modelo de desarrollo ABAP en la nube para aplicaciones transaccionales al utilizar Core Data Services (CDS) a fin de definir estructuras de datos y vistas, proporcionar mecanismos para implementar la lógica empresarial y garantizar la integridad de los datos durante las transacciones.

¿Por qué aprender RESTful Application Programming?

Evolución de los requisitos de las aplicaciones empresariales

RAP no es solo un nuevo marco de desarrollo; es el modelo de programación estratégico de SAP para adoptar el paradigma moderno en la creación de aplicaciones empresariales dentro del ecosistema SAP.

Las aplicaciones empresariales modernas requieren información inmediata de sus datos operativos para fundamentar la toma de decisiones. En consecuencia, las capacidades analíticas se están integrando dentro de las aplicaciones transaccionales, lo que permite obtener información sin necesidad de cambiar de contexto.  RAP permite la integración directa de datos con el entrenamiento y análisis de modelos de IA, lo que reduce la necesidad de replicación y procesamiento de datos complejos.

RAP está optimizado para la base de datos SAP HANA, aprovechando todo el potencial de sus capacidades de procesamiento en memoria, y ejecutando operaciones como uniones, agregaciones y cálculos complejos a mayor velocidad, que anteriormente representaban cuellos de botella de rendimiento en bases de datos tradicionales.

SAP Fiori introdujo un nuevo lenguaje de diseño y un nuevo paradigma de experiencia de usuario para las aplicaciones SAP, caracterizados por la simplicidad, la coherencia y el acceso basado en roles. RAP permite a los desarrolladores exponer objetos empresariales como servicios OData, lo que permite una integración perfecta con elementos Fiori y una experiencia coherente en varios dispositivos.

RAP está diseñado bajo principios de nube, y las aplicaciones se encuentran intrínsecamente optimizadas para el entorno SAP BTP ABAP, lo que permite tanto la extensibilidad dentro de la aplicación como las extensiones en paralelo. Esto lo hace ideal para implementaciones híbridas y nativas en la nube.

Expectativas del usuario final

Fiori UX consume directamente los servicios RAP OData, lo que ofrece una experiencia de usuario coherente en diferentes dispositivos, al mismo tiempo que mantiene el contexto. El diseño subyacente de RAP promueve la ausencia de estado, lo que permite que las sesiones de los usuarios puedan retomarse fácilmente desde cualquier dispositivo, continuando desde el punto donde se dejaron en el dispositivo anterior.

Cualidades del producto (listo para usar)

Los principios de programación de RAP permiten a los desarrolladores agregar varias cualidades críticas de forma predeterminada sin requerir esfuerzos posteriores al desarrollo:

• Escalabilidad: la arquitectura sin estado de RAP y la interacción optimizada con SAP HANA permiten inherentemente la escalabilidad, lo que posibilita que las aplicaciones se implementen de manera distribuida y se escalen fácilmente en entornos de nube.
• Capacidad de prueba: RAP proporciona herramientas y técnicas integradas para probar la lógica de las aplicaciones y promover la separación de las capas lógicas, lo que facilita la realización de pruebas unitarias y el mantenimiento de las definiciones de comportamiento.
• Extensibilidad: RAP permite a los desarrolladores crear puntos de extensión bien definidos en sus aplicaciones, lo que posibilita realizar modificaciones y adiciones de nuevas funciones sin necesidad de realizar cambios en el código fuente.
• Capacidad de soporte: las aplicaciones desarrolladas se mantienen fácilmente con capacidades detalladas de diagnóstico y depuración después de la implementación.
• Capacidad de documentación: la naturaleza declarativa de RAP, como las definiciones CDS y su modelo de programación estructurado, conduce de forma inherente a una mejor documentación.

Fundamentos de RAP

¿Qué es un objeto empresarial?

Un objeto empresarial en RAP representa una entidad o concepto comercial del mundo real dentro de un dominio empresarial, como un pedido de ventas, un cliente, un producto o un empleado. Encapsula todos sus datos, comportamiento y relaciones. El objeto empresarial es la unidad central de control para la manipulación coherente de datos y la integridad transaccional, ya que define la estructura de los datos, las reglas que rigen su manipulación y el ciclo de vida de una entidad comercial.

¿Qué es una consulta?

Una consulta es la interfaz de solo lectura que permite acceder a los datos para su consumo y se crea sobre las vistas Core Data Services (CDS), utilizándose principalmente para recuperar y mostrar datos empresariales. Proporciona una forma estructurada de recuperar, filtrar, ordenar y agregar datos, y suelen servir como fuente de datos para paneles analíticos, funcionalidades de búsqueda o listas de objetos en la interfaz de usuario.

¿Qué es un servicio empresarial?

Los servicios empresariales en RAP proporcionan una interfaz externa para acceder a las funcionalidades de los objetos empresariales, tanto de lectura como de escritura, con las que pueden interactuar los usuarios finales o sistemas externos a través de la interfaz de usuario de aplicaciones Fiori. Los servicios empresariales normalmente se exponen mediante una definición de servicio, que describe qué ofrece el servicio, y una vinculación de servicio, que especifica cómo se expone utilizando un protocolo determinado, como OData v2 o v4, UI, Web API, entre otros.

¿Qué es un evento empresarial?

Un evento empresarial en RAP representa un activador o una notificación definidos que señalan un cambio o una acción significativa que ocurre dentro de un objeto empresarial, lo cual puede activar otros eventos en aplicaciones o servicios que estén vinculados. Por ejemplo, un “pedido de ventas creado” o un “precio de producto modificado” es un evento empresarial que otras aplicaciones o flujos de trabajo pueden consumir para su posterior procesamiento. Las definiciones de eventos y vinculaciones de eventos se definen y utilizan para la integración asíncrona entre servicios, ya sea a través de SAP Event Mesh o mediante lógica personalizada.

Modelado de datos

El modelado de datos en RAP se realiza mediante Core Data Services (CDS), que define entidades, es decir, estructuras de datos, sus asociaciones, por ejemplo, relaciones con otras entidades, y proyecciones con vistas personalizadas para la exposición. El modelado de datos es el punto central para definir toda la estructura de la aplicación desde una perspectiva de flujo de datos.

Lenguaje ABAP

El lenguaje ABAP moderno sirve como base para implementar la lógica empresarial dentro de RAP, aprovechando sus funciones, que incluyen Entity Manipulation Language (EML), las anotaciones y los conceptos orientados a objetos, así como sus amplias bibliotecas y sus capacidades de gestión de errores.

Herramientas

El desarrollo de RAP cuenta con el respaldo de un conjunto diverso de herramientas, tales como el editor de CDS, los editores de código fuente ABAP, los asistentes de ADT y el editor de vinculación de servicios, las cuales están integradas principalmente dentro de ABAP Development Tools (ADT) en el IDE de Eclipse (una plataforma de desarrollo de código abierto ampliamente utilizada para el desarrollo de software).

Extensibilidad

RAP proporciona mecanismos de extensibilidad integrados, que permiten a los clientes y socios mejorar o adaptar objetos y servicios empresariales estándar sin modificar el código base central. Ofrece un mecanismo preciso para ambos tipos de extensibilidades: extensibilidad dentro de la aplicación, que permite agregar campos personalizados, lógica personalizada u objetos empresariales personalizados directamente en aplicaciones existentes, y extensibilidad en paralelo, que implica crear aplicaciones o servicios separados para consumir y ampliar objetos empresariales estándar.

Arquitectura de 3 capas del modelo RAP

El modelo RAP tiene tres capas fundamentales, cada una con un rol específico, y proporciona un enfoque estructurado para crear aplicaciones SAP Fiori empresariales y exponer API para interacciones externas.

Modelado de datos y comportamiento

El modelado de datos y la definición del comportamiento son la capa fundamental. Definen las entidades que representan los objetos empresariales y las relaciones entre dichas entidades.

Las vistas Core Data Services se utilizan para definir modelos de datos que se pueden reutilizar y para definir la estructura de las entidades, incluyendo sus atributos, asociaciones y aplicar diferentes filtros y cálculos, así como anotaciones a fin de proporcionar metadatos para el consumo de la interfaz de usuario.

La definición del comportamiento es el paso que define qué acciones son posibles con una estructura de datos, como operaciones de creación, actualización y eliminación.

El modelo de datos y las operaciones disponibles se definen en la base de datos. Sin embargo, la lógica real para ejecutar estas operaciones se implementa en las clases ABAP, que contienen la lógica empresarial para la creación, actualización, eliminación y otras operaciones personalizadas realizadas sobre los objetos empresariales.

Servicio empresarial

La capa de servicio empresarial es responsable de exponer la estructura de datos y el comportamiento definido en la primera capa como un servicio consumible. La definición del servicio se escribe para especificar qué entidades CDS y su comportamiento estarán expuestos, controlando así el alcance del servicio.

La definición de la vinculación de servicio es el segundo paso que especifica el protocolo que se utilizará para la comunicación con el servicio, es decir, OData v2 u OData v4.

Consumo del servicio

El consumo del servicio se refiere a la capa donde los clientes o las aplicaciones utilizan los servicios expuestos. Cuando un servicio está destinado a una aplicación SAP Fiori Elements, se lo denomina servicio de IU, y su propósito es proporcionar datos y metadatos que Fiori Elements utiliza para generar automáticamente pantallas, tablas y formularios.

El servicio se puede exponer como una API web para que lo consuma cualquier cliente OData y este tipo de servicio no incluye metadatos específicos de la interfaz de usuario. Estos servicios son ideales para la integración con sistemas no SAP, aplicaciones móviles o cualquier aplicación personalizada que requiera interacción con datos y lógica empresariales.

Evolución de los modelos de programación ABAP

La programación ABAP ha evolucionado desde la codificación de estilo libre hasta el modelo RESTful Application Programming, adaptándose a los cambios en el paradigma tecnológico, las transformaciones arquitectónicas y las necesidades de desarrollo, especialmente después de la llegada de SAP Fiori y el desarrollo nativo de la nube.

Programación ABAP clásica

En los modelos clásicos, los desarrolladores solían escribir código ABAP en un estilo procedimental e imperativo, accediendo directamente a las bases de datos y mezclando la lógica empresarial con la de interfaz de usuario, lo que generaba un fuerte acoplamiento y, en consecuencia, hacía que la base de código fuera más compleja de mantener.

La interfaz de usuario se construía con herramientas como SAPscript, Smart Forms y la programación de diálogos (Dynpro). Esto implicaba la creación de pantallas con elementos de la interfaz de usuario y su vinculación con la lógica ABAP, así como con los módulos Process Before Output (PBO) y Process After Input (PAI). Dynpro era eficaz para las aplicaciones de escritorio tradicionales, pero carecía de capacidades modernas de diseño responsivo.

Modelo de programación ABAP para SAP Fiori

Con la llegada de SAP Fiori, surgió un nuevo modelo de programación orientado a adaptarse a las necesidades de la experiencia de usuario moderna y responsiva. Este modelo se centra en la creación manual de OData con la herramienta SAP Gateway Service Builder (SEGW). Los desarrolladores definen manualmente entidades, propiedades y asociaciones, e implementan las operaciones de creación, lectura, actualización y eliminación (CRUD).

Mediante el mecanismo OData.publish, los servicios OData se registran y publican para su consumo en SAP Gateway, que actúa como un hub para la exposición y gestión de servicios OData.

Core Data Services permitió a los desarrolladores definir modelos de datos semánticamente ricos para la creación de entidades, asociaciones y cálculos en la base de datos.  Business Object Processing Framework (BOPF) basado en CDS fue diseñado para simplificar la implementación de la lógica de los objetos empresariales, tales como comportamiento, validaciones y operaciones de CRUD.

Modelo ABAP RESTful Application Programming

RAP representa la evolución más reciente, diseñado para la creación eficiente de aplicaciones listas para la nube para SAP S/4HANA y SAP BTP.

Centraliza el concepto de servicio empresarial, encapsulando tanto los aspectos de datos como de comportamiento, tales como qué entidades y comportamientos se expondrán para aplicaciones SAP Fiori o externas, y mediante qué protocolo.

Core Data Services (CDS) sigue siendo un componente central dentro de RAP, ya que permite la definición de modelos de datos reutilizables y anotaciones para la generación automática de interfaces de usuario de Fiori Elements.

RAP separa la definición del comportamiento de su implementación. Una especificación declarativa define qué operaciones son posibles, mientras que la implementación del comportamiento es donde reside el código ABAP para implementar la lógica de los comportamientos definidos.

Pasos en el proceso de desarrollo de RAP

El proceso de desarrollo de aplicaciones en RAP comienza con la definición de la estructura de datos subyacente con sus relaciones, comportamiento y metadatos para exponer el servicio que puede ser consumido por Fiori Elements o aplicaciones externas.

1. Proporcionar las tablas de la base de datos

El primer paso es elegir qué tablas se utilizarán para almacenar los datos empresariales. Estas pueden ser tablas SAP estándar existentes o tablas definidas personalizadas. Agregue explicaciones al integrar las heredadas y sobre cualquier modificación realizada a las tablas, si no estaban basadas en CDS. Crear nuevas tablas, con atributos personalizados específicos de la aplicación, también es una opción adecuada para una implementación limpia y separada.

2. Definir el modelo de datos

El siguiente paso es definir el modelo de datos, mediante la creación de vistas CDS que representen los objetos empresariales. Estas vistas pueden constar de una sola tabla como una vista CDS simple o unir múltiples tablas para crear vistas compuestas con definiciones de relación primario-secundario para objetos empresariales complejos.

• Los objetos empresariales simples representan completamente un producto o cliente con todos los atributos y comportamientos relevantes encapsulados dentro de una vista CDS.
• Los objetos empresariales compuestos abordan escenarios empresariales complejos que involucran múltiples entidades, como un pedido de ventas, que puede no ser una entidad única y podría vincularse con el encabezado del pedido de ventas y los artículos de dicho pedido.

La relación primario-secundario define la asociación y la composición en CDS, lo cual admite el comportamiento transaccional y garantiza la coherencia.

3. Definir e implementar el comportamiento (solo para aplicaciones transaccionales)

El modelo de datos define la estructura del objeto empresarial. Por el contrario, la definición y la implementación del comportamiento determinan cómo se comportará transaccionalmente, incluidas las operaciones admitidas, como crear, actualizar y eliminar. Aquí se implementan operaciones personalizadas con verificaciones de validación antes de guardar los datos.

Behavior Pool, una clase ABAP global, se utiliza para la implementación del comportamiento, y es donde se escribe el código ABAP real.

Las funciones clave de las aplicaciones transaccionales son las siguientes:

• Habilitación de borradores: permite que los usuarios finales guarden datos empresariales incompletos como borradores, sin realizar una confirmación definitiva, lo que mejora la experiencia de usuario al permitir pausar y retomar el trabajo posteriormente.
• Numeración automática: generación única y secuencial de claves para entidades que requieren identificadores únicos, como los números de pedidos de ventas.
• Validaciones: Verificaciones de coherencia de datos implementadas para verificar que los formatos de entrada y los valores esperados cumplan con la lógica empresarial. Por ejemplo, las fechas de entrega no pueden estar en el pasado y los formatos de números telefónicos deben ser correctos.
• Determinaciones: campos que se calculan automáticamente en función de la entrada en otros campos. Por ejemplo, el nombre completo se completa automáticamente a partir del nombre y apellido, o al ingresar un nombre de producto, se completan automáticamente su descripción y precios.

La implementación del comportamiento puede omitirse si la aplicación es exclusivamente de visualización de datos, como un informe de listas o un reporte analítico, y no requiere operaciones de modificación.

4. Proyectar el objeto empresarial de RAP

En lugar de exponer todos los campos de la vista CDS subyacente, se exponen subconjuntos seleccionados de campos con vistas de proyección CDS para un servicio en particular. Se puede cambiar el nombre de los campos o agregar campos calculados previamente específicos de la interfaz de usuario, y se puede utilizar una convención de nomenclatura como ZC_ para mantener la coherencia.

De forma similar al modelo de proyección de datos, la proyección del comportamiento permite habilitar o deshabilitar operaciones específicas, como crear, eliminar y actualizar, en el servicio. Por ejemplo, en lugar de eliminar la operación de eliminación en el comportamiento de CDS, este comportamiento no se expone en el servicio.

Se agregan anotaciones específicas de la interfaz de usuario a la vista de proyección para definir cómo se deben mostrar los datos en la interfaz de usuario de Fiori Elements y controlar aspectos como etiquetas de campo, capacidades de búsqueda y funciones analíticas.

5. Definir el servicio

La definición del servicio es un objeto del repositorio que hace referencia a una o varias vistas de proyección CDS y actúa como un contenedor de las entidades que se expondrán como un servicio.

Se suele utilizar la convención de nomenclatura Z y se describen anotaciones específicas para controlar la exposición y las propiedades de navegación de la interfaz de usuario.

6. Vincular el servicio y probarlo

El paso final es definir la vinculación del servicio mediante la descripción de los métodos de consumo, es decir, la interfaz de usuario Fiori o aplicaciones externas, y el protocolo, como OData v2 o v4.

Para los servicios de la interfaz de usuario, los desarrolladores pueden habilitar la vista previa para generar automáticamente una previsualización de Fiori Elements, lo que les permite probar rápidamente la funcionalidad sin desarrollar la aplicación Fiori completa.

Generalmente, se utiliza la convención de nomenclatura ZUI_<service_Name>_04 para el servicio de la interfaz de usuario del protocolo OData v4.

Implementación de los objetivos empresariales

Existen dos enfoques principales para implementar los tipos de objetos empresariales en RAP:

• Gestionados
• No gestionados

Ambos métodos se basan en modelos de datos definidos por entidades de vistas CDS. La diferencia radica en el aprovisionamiento del comportamiento transaccional del objeto empresarial.

Objetivos empresariales gestionados

La implementación de tipo Gestionados se utiliza principalmente cuando una aplicación se desarrolla desde cero, aunque también puede aprovechar el soporte listo para usar para el procesamiento transaccional. El marco proporciona validaciones y determinaciones estándar.

Objetivos empresariales no gestionados

El enfoque No gestionados se adopta para tener control total sobre la lógica transaccional, las operaciones CRUD y la persistencia de datos al manejar lógica empresarial compleja e interacción con múltiples sistemas. Los desarrolladores deben implementar componentes esenciales del contrato REST. El comportamiento debe especificarse en su definición, pero implementarse manualmente en clases ABAP dentro de Behavior Pool.

Cuando la lógica empresarial ya está encapsulada en módulos funcionales, el enfoque No gestionados ayuda a los desarrolladores a reutilizar la lógica existente en los objetos empresariales. Este enfoque puede beneficiarse de la orquestación estándar de ejecución de RAP para crear un servicio RAP.

Reutilización de servicios y bibliotecas

ABAP RAP proporciona una colección de funcionalidades, API y componentes prediseñados para su uso en múltiples aplicaciones o servicios. La reutilización de servicios y bibliotecas existentes permite a los desarrolladores ahorrar tiempo y esfuerzo en tareas como verificaciones de autorización estandarizadas, determinaciones de texto y código redundante, lo que les posibilita concentrarse en la lógica empresarial única específica de la aplicación.

Las bibliotecas y servicios predefinidos proporcionan funcionalidades genéricas listas para usar aplicables en varios dominios empresariales, como administración de borradores, control y validaciones de campos, gestión del procesamiento transaccional, utilidades de fecha y hora, manejo de Etag para control de concurrencia de datos, generación de registros estandarizados y seguimiento de errores o eventos.

RAP permite crear lógica personalizada específica del dominio para estos servicios internos o bibliotecas, y estos servicios personalizados se pueden reutilizar en cualquier lugar.

La capacidad de reutilizar bibliotecas estándar o personalizadas permite a los desarrolladores reducir el código repetitivo. Esto no solo acelera el proceso de desarrollo, sino que también mejora la capacidad de mantenimiento. La reutilización de servicios y bibliotecas está diseñada para integrarse dentro de las aplicaciones, lo que permite a los desarrolladores llamar a servicios externos o invocar funciones de biblioteca directamente desde sus implementaciones de comportamiento y vistas de proyección.

Preguntas frecuentes