Estrategias para Ampliar SAP S/4HANA On-Premise sin Modificar el Código Base: Una Guía Práctica

Resumen

Este artículo explora las metodologías modernas para extender las funcionalidades de aplicaciones estándar en SAP S/4HANA On-Premise, respetando el principio de “Clean Core” (no alterar el código base). Basado en la ponencia de Jorge Briseño de Logali Group, se analizan los tres pilares de la extensibilidad: Key User, Developer y Side-by-Side. Además, se detalla un caso práctico utilizando SAP Business Application Studio (BAS) y Adaptation Projects para intervenir una aplicación Fiori Elements, demostrando cómo añadir lógica personalizada mediante TypeScript sin comprometer la integridad del estándar.

Índice de Contenidos

1. Introducción
2. Los Tres Pilares de la Extensibilidad en SAP S/4HANA
3. Preparación y Análisis Técnico de la Aplicación Estándar
4. Herramientas Clave: Business Application Studio y Adaptation Projects
5. Caso Práctico: Implementación de Botones y Lógica Personalizada
6. Conclusión
7. Recurso Adicional: Video Completo

Palabras Clave

SAP S/4HANA, Extensibilidad, Adaptation Project, SAP Fiori Elements, SAP BTP, Business Application Studio, TypeScript, Clean Core, Key User Extensibility.

1. Introducción

En el ecosistema actual de SAP, la capacidad de adaptar el software a las necesidades del negocio sin comprometer las actualizaciones futuras es un desafío crítico. Antiguamente, la modificación directa del código estándar era común, pero esto generaba deuda técnica y dificultades en el mantenimiento.

Con la llegada de SAP S/4HANA On-Premise, el paradigma ha cambiado. Ahora es posible (y mandatorio) ampliar funcionalidades mediante técnicas que no tocan el código fuente original. Este artículo desglosa cómo los consultores y desarrolladores pueden aprovechar herramientas como Adaptation Projects para crear soluciones robustas y escalables.

 

2. Los Tres Pilares de la Extensibilidad en SAP S/4HANA

Para abordar una ampliación, es fundamental entender qué tipo de extensibilidad se requiere según la complejidad del requerimiento:

• Key User Extensibility (In-App Extensibility): Diseñada para consultores funcionales o usuarios clave, no requiere código. Permite realizar cambios directos en el Fiori Launchpad, como ocultar filtros, renombrar etiquetas o agregar campos personalizados (Campos Z) mediante las apps Custom Fields y Custom Logic.
• Developer Extensibility: Requiere la intervención de un perfil técnico (Frontend o Backend). Se utiliza para extensiones más complejas que no pueden resolverse con herramientas Key User. Involucra el desarrollo sobre servicios OData o, en el frontend, el uso de Adaptation Projects.
• Side-by-Side Extensibility: Se basa en el desacoplamiento total. Permite crear nuevas aplicaciones satélite utilizando modelos como RAP (ABAP RESTful Application Programming Model) o CAP (Cloud Application Programming Model), desplegadas generalmente en SAP BTP (Business Technology Platform).

 

 

Preparación y Análisis Técnico de la Aplicación Estándar

Antes de escribir una sola línea de código, es vital realizar un diagnóstico de la aplicación objetivo (por ejemplo, “Manage Credit Accounts”):

1. Verificación en Fiori App Library: Confirmar los requisitos técnicos y funcionales.
2. Estado del Servicio: Asegurar que el servicio OData y la aplicación estén activos en el sistema On-Premise.
3. Análisis de Estructura (Transacción SE80): Es crucial identificar si la aplicación es Freestyle SAPUI5 o Fiori Elements. La presencia de carpetas de anotaciones y extensibilidad suele indicar que se trata de una aplicación Fiori Elements, la cual es ideal para ser ampliada mediante Adaptation Projects.

 

 

4. Herramientas Clave: Business Application Studio y Adaptation Projects

Para el desarrollo, se utiliza el SAP Business Application Studio (BAS) conectado al sistema On-Premise mediante un Cloud Connector.

Un punto crítico diferenciador es la elección de la plantilla:

• No se deben usar plantillas como Basic o List Report (usadas para desarrollos desde cero).
• Se debe seleccionar explícitamente Adaptation Project.

Al configurar el proyecto, se definen parámetros como el ID, el namespace, la versión de SAPUI5 (ej. 1.120.40) y, como estándar moderno, el uso de TypeScript para un código más limpio y tipado.

 

 

5. Caso Práctico: Implementación de Botones y Lógica Personalizada

El flujo de trabajo para extender una interfaz de usuario (UI) se divide en dos fases: visual y lógica.

Extensión Visual (Adaptation Editor)

Utilizando el editor visual, se puede agregar un control, como un botón en la Overflow Toolbar. Al hacer esto, el sistema no modifica la vista original, sino que genera un Fragmento XML dentro de la carpeta changes/fragment del proyecto. Este archivo contiene la definición del nuevo elemento.

Extensión de la Lógica (Controlador)

Para que el botón tenga funcionalidad, se requiere programación en JavaScript o TypeScript:

1. Creación del Controlador: Se genera un archivo de extensión (ej. ListReportController.ts) en la carpeta code/controllers.
2. Vinculación: En el fragmento XML, se referencia al método del controlador utilizando la ruta completa y el sufijo .extension.
3. Funcionalidad: Se puede implementar lógica simple (como un Message Toast) o compleja, como abrir un diálogo para capturar información de un Business Partner y enviarla a un servicio CAP en BTP.

 

 

6. Conclusión

La ampliación de funcionalidades en SAP S/4HANA On-Premise ha evolucionado hacia un modelo no intrusivo. El uso de Adaptation Projects permite a las empresas personalizar sus procesos críticos manteniendo el núcleo del sistema limpio (“Clean Core”). Esto no solo facilita las actualizaciones futuras del ERP, sino que también empodera a los desarrolladores para utilizar tecnologías modernas como TypeScript y SAP BTP, garantizando soluciones sostenibles a largo plazo.

 

7. Recurso Adicional

Si quieres entenderlo mejor, puedes ver el video completo donde se explica paso a paso este proceso.