Clean core en la letra: cuando el in-app se estira de más
Forzar lógica compleja en extensibilidad in-app cumple la letra del clean core y erosiona el upgrade. Señales y salida para utilities en LATAM.
· 12 min de lectura
Hay un riesgo del que casi no se habla en los proyectos de clean core. No es el del desarrollador que se salta las reglas y modifica el estándar: ese ya lo detecta cualquier auditoría. Es el opuesto, y es más difícil de ver porque llega disfrazado de buena práctica. Un requerimiento crece, el equipo decide resolverlo igual dentro del modelo in-app, y el resultado pasa todos los controles técnicos mientras acumula fragilidad que nadie mide hasta la siguiente actualización.
En una comercializadora de energía, un distribuidor de agua o una empresa de gas, ese requerimiento suele nacer pequeño: una validación en la contratación, un atributo adicional en el punto de suministro, un ajuste en el tratamiento de un caso de aclaración. La extensibilidad in-app existe exactamente para eso. El problema empieza cuando lo pequeño deja de serlo y la decisión de dónde construirlo ya se tomó.
El límite del modelo in-app es un contrato, no un obstáculo
La extensibilidad de key user opera con una versión restringida del lenguaje: no permite acceso directo a tablas de base de datos ni sentencias de creación, actualización o borrado, obliga a leer a través de vistas CDS liberadas y descarta frameworks clásicos como reports y dynpros (SAP Community, 2020). ABAP Cloud, en la capa de desarrollador, aplica la misma lógica: bloquea sentencias obsoletas y el acceso directo a tablas no liberadas para asegurar la estabilidad del sistema (Saptutorials.in, 2026).
Conviene leer esas restricciones como lo que son: un contrato de estabilidad. Cada cosa que el modelo in-app no deja hacer es una cosa que el upgrade no tendrá que revisar. Cuando un requerimiento choca contra ese muro, el muro está informando algo — que el requerimiento pertenece a otro nivel de la arquitectura, no que haya que buscarle la vuelta.
Hay una restricción adicional que suele pasarse por alto en el diseño: la extensión side-by-side no agrega puntos de extensión nuevos al estándar, y toda extensión sigue acotada por los parámetros de entrada y salida que expone la interfaz del BAdI (SAP Learning, s. f.). Es decir, el límite no es solo de lenguaje. Es de semántica: el punto de extensión fue diseñado para una intención concreta.
Los síntomas del in-app estirado
Ninguno de estos patrones dispara una alerta en un control automático. Todos aparecen en revisiones de código de proyectos que se declaran clean core:
- Wrappers que multiplican. Existe un camino documentado para sortear una limitación: implementar el BAdI con la versión de lenguaje de key user y consumir una clase creada con herramientas estándar y liberada para uso en la herramienta de key user (SAP Community, 2020). Es legítimo y a veces necesario. Cuando se vuelve el patrón por defecto, la dependencia con objetos no liberados sigue ahí — solo cambió de lugar.
- Lógica repartida entre varios puntos de extensión porque ninguno solo alcanza para el caso, con estado transportado en campos personalizados que actúan como mensajería informal entre implementaciones.
- Volumen mal ubicado. Una validación que corre bien en un contrato individual se comporta de otro modo dentro de una ejecución masiva de facturación o de un ciclo de lectura completo. El punto de extensión no fue dimensionado para eso.
- Duplicación sin reutilización, porque el modelo in-app no ofrece las mismas herramientas de modularización, prueba y depuración que el entorno de desarrollo profesional.
- Ausencia de prueba automatizada sobre lógica que ya decide montos facturados o resultados de reclamos.
El costo no aparece en una factura. Aparece en la ventana de actualización, cuando hay que retestear manualmente algo que debía ser transparente — justo el escenario que el clean core existía para evitar.
Cumplir la letra no equivale a proteger el upgrade
El propio SAP reconoció que la clasificación binaria del custom code entre “clean core” y “no clean core”, gobernada por chequeos de ABAP Test Cockpit, resultaba demasiado restrictiva y poco aplicable a sistemas con volumen relevante de código clásico, y evolucionó hacia un modelo más flexible (SAP Community, 2025). El modelo por niveles reconoce grados: el Nivel A corresponde a extensiones construidas con ABAP Cloud sobre APIs liberadas; el Nivel B admite APIs clásicas ampliamente documentadas y recomendadas —incluidos los wrappers sobre APIs clásicas que habilitan su consumo desde aplicaciones de Nivel A—, con buenas prácticas de estabilidad de upgrade (SAP Learning, s. f.).
Esa gradación es una herramienta de diagnóstico, no una calificación que se aprueba. Un veredicto técnico favorable describe qué tecnología se usó; no dice si el diseño era el adecuado para el problema. La pregunta de gobierno no es “¿pasó el chequeo?”, sino “¿esta lógica sigue siendo pequeña?”.
Cómo reencauzar sin rehacer el proyecto
La corrección rara vez exige reescribirlo todo. Exige mirar el inventario con un criterio distinto del que se usó al construirlo.
Para el inventario existe soporte de producto: la aplicación de inventario de extensibilidad registra las extensiones creadas en el framework, quién realizó el último cambio y su estado de exportación e importación (SAP Learning, s. f.). El criterio para reubicar es de arquitectura: si el requerimiento necesita servicios externos, orquestación entre sistemas, persistencia propia o procesamiento intensivo, ya no es una extensión pequeña, por más que el editor la acepte.
En utilities, además, el terreno se ha ido ampliando por el lado correcto. SAP ha ido habilitando campos y lógica personalizados sobre objetos del negocio de servicios públicos, incluyendo datos maestros del punto de suministro y casos de aclaración, y documenta el panorama de clean core para la industria en la nota SAP 3406389 (SAP Community, 2025). Cuando existe un punto de extensión liberado para el objeto que se quiere extender, forzar el camino artesanal deja de tener justificación técnica.
La regla práctica es de sentido común operativo: la extensibilidad in-app es excelente para lo cotidiano — un campo, una validación corta, una regla de negocio acotada. Cuando la conversación empieza a girar sobre cómo esquivar una limitación en lugar de sobre el proceso de facturación o de reclamos que se quería mejorar, la decisión de ubicación ya está equivocada.
Detectarlo a tiempo es la mitad del trabajo. La otra mitad es dejar registro de por qué se decidió así — el catálogo de extensiones que evita repetir el mismo debate cada trimestre, tema del próximo artículo de esta serie.
Fuentes
- SAP Community — Restricted ABAP and SAP S/4HANA On-Premise: https://blogs.sap.com/2020/07/23/restricted-abap-and-sap-s-4hana-on-premise/
- SAP Community — Restricted ABAP for SAP BTP ABAP Environment: https://blogs.sap.com/2020/06/03/restricted-abap-for-sap-cloud-platform-abap-environment/
- Saptutorials.in — Mastering SAP Extensibility: A Comprehensive Guide To Clean Core Architecture: https://www.saptutorials.in/sap-extensibility-guide/
- SAP Community — ABAP Extensibility Guide, Clean Core for SAP S/4HANA Cloud (actualización agosto 2025): https://community.sap.com/t5/technology-blog-posts-by-sap/abap-extensibility-guide-clean-core-for-sap-s-4hana-cloud-august-2025/ba-p/14175399
- SAP Learning — Explaining Extensibility Model Best Practices: https://learning.sap.com/courses/practicing-clean-core-extensibility-for-sap-s-4hana-cloud/explaining-extensibility-model-best-practices_e290f382-800e-40ef-a203-85a13115f487
- SAP Learning — Using the Key-User In-App Extensibility Tools in SAP S/4HANA Cloud: https://learning.sap.com/courses/implementing-sap-s-4hana-cloud-private-edition/using-the-key-user-in-app-extensibility-tools-in-sap-s-4hana-cloud-private-edition_bfd97d11-03ce-46d1-87d4-6118b5fff695
- SAP Community — SAP S/4HANA 2025: What’s in it for the Utilities Industry: https://community.sap.com/t5/sap-for-utilities-blog-posts/sap-s-4hana-2025-what-s-in-it-for-the-utilities-industry/ba-p/14216995
¿Este análisis mapea un mercado donde ya operas o estás evaluando entrar?
Revisamos tu caso específico, mapeamos los riesgos que aplican, y te decimos honestamente si es oportunidad para ti —sin pitch comercial, solo discusión técnica y estratégica.
