✒️SAP BASIS / Arquitectura Fiori en SAP S/4HANA Por Mayra Herrera Naranjo

El entorno del sistema SAP Fiori consiste prncipalmente en

• Un servidor Front-end (FES)
• Un servidor Back-end (BES)

Estos representan roles del sistema dentro de un servidor de aplicaciones ABAP o plataforma ABAP.El servidor backend es una SAP Business Suite o un SAP S/4 HANA que contiene aplicaciones y datos de cualquier área basado en un AS ABAP 7.40 o superior. El servidor front-end es un ABAP básico 7.40 o superior ambos pueden ejecutarse sobre cualquier BD.

Se recomienda usar un SAP Web Dispatcher u otro proxy inverso entre el FLP y el FES. Un proxy inverso ofrece un único punto de comunicación que contiene reglas de enrutamiento para redirigir las solicitudes a los sistemas de destino correctos.

El despliegue embebido significa que tanto el servidor FES como el servidor backend se encuentra en la misma instancia de sistema SAP. Tiene limitaciones en escalabilidad, separación de responsabilidades, flexibilidad para futuras migraciones o expansiones de sistemas.

El entorno de SAP Fiori en un BES es compatible con aplicaciones transaccionales basadas en SAPUI5 así como Web Dynpro y transacciones ABAP. Entre los componentes obligatorios de un FES:

• SAP Gateway: Encargado de la comunicación mediante protocolo OData entre el FES y el BES
• UI Central: Proporciona funciones generales de SAP Fiori
• Interfaces de usuario específicas del producto: Aplicaciones Fiori desarrolladas con SAPUI5 y otras tecnologías

El SAP Gateway y el código ABAP que contiene la lógica de negocio de las plicaciones residen en el BES donde se lleva a cabo el procesamiento real de los datos y las reglas de negocio y el FES es la capa de presentación y comunicación.

El central UI incluye las vistas, funciones y herramientas necesarias para la personalización, customizing y configuración de entorno. La personalización se hace por el usuario dentro del FLP, el FLP debe tener la capacidad de leer y escribir datos en el FES mediante OData, el FLP no se comunica directamente con el BES las configuraciones de SAP Fiori se almacenan en el FES esto facilita la gestión centralizada y evita necesidad de duplicar configuraciones

• FLP: Punto de acceso unico para todas las aplicaciones Fiori
• FES: Aloja el FLP, configuraciones generales y personalizaciones
• BES: Nose comunica directamente con el FLP, solo ejecuta lógica de negocio
• OData: Canal de comunicación entre FLP y FES

Las aplicaciones transaccionales están compuestas por aplicaciones SAPUI5 y servicios SAP Gateway, las aplicaciones SAPUI5 se almacenan en el reositorio ABAP como objetos BSP y se entregan mediante complementos específicos de interfaz de usuario (UI add-ons). Los servicios SAP Gateway se entregan como parte de las actualizaciones de la solución del Servidor BES y es en lenguaje ABAP, su activación o registro de estos servicios se realizan en el FES por parte del cliente.

Cuando una aplicacion transaccional necesita acceder a datos se realiza una solicitud OData a través del SAP Web Dispatcher hacia el SAP Gateway, de ahí el framework de SAP Gateway genera una solicitud RFC hacia la implementación del servicio BES. Este modelo es típico en arquitecturas de Central Hub, el último paso es el código ABAP en el BES accede a la base de datos, obtiene los datos y los retorna por el mismo canal hacia el usuario.

Las aplicaciones clásicas forman arte de la solución del BES y no tienen interacción con el FESm excepto a través del FLP. L ainterfaz de usuario y los datos provienen directamente del código ABAP que se ejecuta en el BES. La función del FES es proporcionar la información de conexión al BES cuando se inicia una solicitud de navegación. Incluyen:

• Transacciones GUI
• Aplicaciones Web Dynpro ABAP
• ITS-based

El FES actua como un punto de lanzamiento, y es necesario configurar destinos de navegación y alias de sistema en el FES.

SAP Gateway esta compuesto principalmente por el complemento de software SAP_GWFND presente tanto en el FES como en el BES. La UI central se basa en el componente de software SAP_UI que contiene todas las tecnologías de interfaz de usuario disponibles en el sistema, los complementos no contienen solo una aplicación, sino todas las aplicaciones SAPUI5 de un área funcional completa (add-ons de producto).

El product UI es un complemento para SAP Gateway y SAP Netweaver, incluye todas las aplicaciones Fiori corrrespondientes a una solución específica el ERP 6.0 con Enhacement Package, la actualización en el BES corresponde a la instalación del Enhacement Package 7. Todas las aplicaciones Fiori se instalan de esta manera siguiendo una aruitectura modular. La SAP Fiori App References Library específica:

• Componentes necesarios del lado FES
• Requisitos del lado BES
• Dependencias de servicios OData y configuraciones requeridas

Un servicio Gateway consiste en clases ABAP y elementos de personalización en el FES y es una entrada en el catálogo de servicios en el BES. Las clases ABAP se dividen en dos clases proveedores de modelo (MPC) proprocionan el c´pdigo para los metadatos del servicio y dos clases proveedoras de datos (DPC) contienen el código para manejar las solicitudes al servicio. El nombre externo definido en la personalización se utiliza para registrar el servicio en el catálogo de serivcio del FES.

Todas las transacciones de SAP Gateway están conectadas entre sí mediante navegación hacia adelante, las más importantes son:

• Mantenimiento de Servicios SAP Gateway
• Cliente SAP Gateway
• Editor de servicios SAP Gateway
• Workbench ABAP

La transacción SAP Gateway Service Builder (SEGW) utiliza proyectos para agrupar todos los artefactos de un servicio en un único lugar centrlizado, ayuda a organizar el proceso de desarrollo y modelado de servicio. SEGW es la herramienta principal de SAP para desarrollar servicios OData personalizados dentro del framework de SAP Gateway, proprociona una interfaz lógica que simplifica y acelera el desarrollo de servicios. Un proyecto SEGW incluye:

• Entidades y asociaciones: Definen el modelo de datos del servicio
• Tipos complejos: Estructuras de datos anidadas
• Model Provider Class: Clase ABAP que define los metadatos del servicio
• Data Provider Class: Clase ABAP que define las solicitudes de servicio
• Mappings: Asociaciones entre el modelo OData y estructuras/tablas ABAP
• Implementación de métodos: Lógica especifica para operaciones CRUD

Las ventajas del SEGW son:

• Modularidad: Cada proyecto encapsula un conjunto de funcionalidades relacionadas
• Reutilización
• Paralelismo: Varios desarrolladores pueden trabajr simultaneamente en varios proyectos
• Trazabilidad: Todos los objetos estpan organizados y gestionados desde un único punto

El proceso es crear un nuevo proyecto, definir entidades y asociaciones, mapear estructuras ABAP, generar las clases MPC y DPC automáticamente, implementar la lógica de negocio en la DPC, registrar y activar el servicio.