Árbol de decisión: dónde construir cada extensión SAP
Cuatro preguntas para decidir en minutos si una necesidad de facturación o reclamos se resuelve in-app o en SAP BTP, sin escalar a ABAP por reflejo.
· 12 min de lectura
El primer movimiento de un árbol de decisión de extensibilidad no es una discusión: es una búsqueda. Tres consultas, cada una contra un artefacto con nombre propio, cada una con resultado binario, todas resolubles antes de que termine una reunión de treinta minutos. Solo cuando las tres pasan tiene sentido abrir una conversación de arquitectura.
La primera de esas consultas es un catálogo. SAP Business Accelerator Hub es el lugar central donde están listados los APIs, eventos y puntos de extensión liberados, y los objetos liberados tienen contrato de estabilidad y ciclo de release (SAP Community, 2024). Si el punto de extensión que el requerimiento necesita no está en ese catálogo, ninguna decisión posterior lo hace aparecer. Y aquí está el hallazgo que ordena todo lo demás: una extensión side-by-side no aporta puntos de extensión adicionales para las aplicaciones estándar, porque sigue limitada por los parámetros de entrada y salida que expone la interfaz del BAdI (SAP Learning, s.f.). Si el dato no viaja en esa firma, salir del core no lo consigue. El pedido no cambia de esfuerzo: cambia de rama.
La entrega anterior de esta serie trabajó el reconocimiento temprano de una necesidad que ya no cabe adentro. Esta pieza convierte ese reconocimiento en un procedimiento con orden fijo: qué se consulta, en qué orden, y con qué artefacto se responde cada paso.
Tres consultas que se responden en minutos, no en una reunión
Los tres primeros pasos del árbol no son arquitectónicos: son verificaciones. Cada una tiene una fuente consultable y un resultado binario, y cualquiera de las tres puede cerrar el caso antes de que empiece el debate.
¿El punto de extensión existe y está liberado? Los BAdIs liberados de SAP S/4HANA Cloud se consultan en la pestaña de Developer Extensibility del SAP Business Accelerator Hub, con su documentación técnica asociada (SAP Community, 2024). Esa consulta también se puede hacer sin salir del entorno de desarrollo: el Repository Browser de las ABAP Development Tools es una vista que permite mostrar y acceder a los objetos de desarrollo del propio sistema (SAP Community, 2024).
¿El contexto de negocio admite el campo? La extensibilidad de key user opera sobre contextos de negocio liberados, y el registro de contextos se revisa directamente en el sistema con la transacción SCFD_REGISTRY (SAP Community, 2024). En SAP S/4HANA Cloud existe además un indicador de capacidad del contexto: cuando se supera el 100%, ya no es posible agregar un campo adicional (SAP Community, 2024). Es un techo físico, no una preferencia de arquitectura, y conviene conocerlo antes de comprometer una fecha.
¿La lógica puede leer lo que necesita? En la app Custom Fields and Logic, la lógica de key user solo consume APIs de la lista blanca (SAP Community, 2024). Esa lista tampoco es un misterio: en el árbol de repositorio ABAP se pueden desplegar los objetos liberados y filtrarlos por tipo para ver qué está disponible (SAP Community, 2024). Si una validación necesita leer algo que no está liberado, la rama in-app queda descartada en el primer minuto, no en el sprint tres.
Cuando ninguna verificación descalifica una rama
Solo aquí la conversación se vuelve arquitectónica. Y aquí aparece un sesgo predecible: un equipo con perfil ABAP ve problemas ABAP, y un equipo con perfil cloud quiere llevarlo todo afuera. La elección de cómo construir depende tanto de la complejidad real del requerimiento como del conjunto de habilidades disponible (Kellton, 2026); cuando el segundo factor pesa más que el primero, la arquitectura la termina definiendo el organigrama.
SAP documenta cuatro factores que deben influir en la elección entre extensibilidad in-app y side-by-side (SAP Learning, s.f.). Traducidos a la operación de una utility, se leen así:
---
config:
theme: base
fontFamily: 'Inter Variable, system-ui, sans-serif'
themeVariables:
darkMode: true
fontFamily: 'Inter Variable, system-ui, sans-serif'
fontSize: '15px'
background: '#111113'
primaryColor: '#1A1A1D'
primaryTextColor: '#F4F5F8'
primaryBorderColor: '#B89C5C'
secondaryColor: '#242428'
tertiaryColor: '#1A1A1D'
mainBkg: '#1A1A1D'
secondBkg: '#242428'
tertiaryBkg: '#2E2E33'
lineColor: '#B89C5C'
textColor: '#F4F5F8'
titleColor: '#F4F5F8'
nodeBorder: '#B89C5C'
clusterBkg: '#1A1A1D'
clusterBorder: '#2E2E33'
edgeLabelBackground: '#242428'
pie1: '#B89C5C'
pie2: '#f59e0b'
pie3: '#22c55e'
pie4: '#d1bf95'
pie5: '#f97316'
pie6: '#ef4444'
pieTitleTextColor: '#F4F5F8'
pieSectionTextColor: '#F4F5F8'
pieLegendTextColor: '#F4F5F8'
pieStrokeColor: '#111113'
pieOuterStrokeColor: '#111113'
---
flowchart TD
A([Ninguna verificación descalificó una rama]) --> B{¿Quién usará la extensión?}
B -->|Usa S/4HANA| C([In-app: liquidador, gestor de reclamos, planificador])
B -->|Externo| D([Side-by-side: áreas nuevas, cuadrillas, usuario final])
B -->|Sin cierre| E{¿Cómo se consume el dato del core?}
E -->|Intensivo| F([Adentro: lectura frecuente y cambio en una transacción])
E -->|Ocasional| G([Afuera: consumo remoto por API o datos replicados])
E -->|Sin cierre| H{¿Qué tipo de solución es?}
H -->|Al core| I([In-app: aplicación independiente o proceso nuevo])
H -->|Hub o UI| J([Side-by-side: integración con otras soluciones, UI freestyle nativa])
H -->|Sin cierre| K{¿Qué estabilidad de ciclo de vida?}
K -->|Key user| L([Extensiones estables por diseño])
K -->|ABAP clásico| M([Esfuerzo de adaptación según la técnica usada])
class A inicio
class B,E,H,K decision
class C,D,F,G,I,J,L bueno
class M neutro
classDef inicio fill:#3a352b,stroke:#B89C5C,color:#ffffff
classDef decision fill:#473519,stroke:#f59e0b,color:#ffffff
classDef bueno fill:#193e2b,stroke:#22c55e,color:#ffffff
classDef neutro fill:#33363c,stroke:#9aa0aa,color:#ffffff
- Grupo objetivo. In-app aplica cuando quien usará la extensión ya trabaja dentro de S/4HANA: el liquidador, el gestor de reclamos, el planificador de mantenimiento. Side-by-side es la respuesta cuando el usuario no usa S/4HANA —o no quiere usarlo—: áreas nuevas, cuadrillas contratistas, y sobre todo el usuario final del servicio.
- Requisitos de integración. Si el dato se lee con alta frecuencia desde el core y el dato propio cambia en la misma transacción que el dato estándar, el lugar es adentro. Si el consumo es ocasional, vía API o incluso contra datos replicados, y no hace falta que ambos cambien en una sola transacción, el lugar es afuera.
- Escenario y requisitos funcionales. Aplicaciones independientes o procesos nuevos con anclaje fuerte en el core empujan hacia in-app. Los hubs de integración con otras soluciones cloud u on-premise, y el desarrollo de UI freestyle como interfaces móviles nativas, empujan hacia side-by-side.
- Estabilidad de ciclo de vida. El desarrollo ABAP clásico normalmente no es estable frente a actualizaciones porque interactúa con el core de muchas maneras, y el esfuerzo de adaptación depende de qué tan invasiva sea la técnica usada. Las extensiones de key user son estables por diseño.
El árbol, en el orden en que se recorre
El orden no es decorativo. Estas preguntas no se ponderan entre sí: se recorren, y la primera que da una respuesta clara cierra la discusión.
Un dato adicional en el maestro de instalación para el liquidador se resuelve en la pregunta 1. Un portal donde el cliente cargue la autolectura del medidor también se resuelve en la pregunta 1, en la dirección contraria. La mayoría de los pedidos cotidianos de facturación, reclamos y mantenimiento no llega a la pregunta 3.
Quién firma la rama elegida
El paso 5 es el que convierte un árbol en gobierno, y tiene un dueño documentado. SAP recomienda constituir un Solution Standardization Board dentro de la organización de TI del cliente, que reporte al comité directivo, revise los desarrollos propuestos que se desvían del enfoque cloud y de la estrategia de clean core, y deje registrada la lógica por la cual el desarrollo fue aprobado; esa documentación permite recordar por qué se hizo y facilita retirarlo cuando el estándar cubra la necesidad (SAP Learning, s.f.). Sin ese registro, el mismo pedido se vuelve a discutir en seis meses.
Para que el registro sea legible entre equipos conviene usar un vocabulario común. La SAP Application Extension Methodology existe justamente para que la organización defina una estrategia de extensión propia y para que todos los involucrados usen la misma terminología y lleguen rápido a un entendimiento común del caso de negocio y de la solución futura (SAP Help Portal, s.f.). Y conviene clasificar el resultado con el marco vigente: los niveles de clean core A–D que la actualización de agosto de 2025 de la guía de extensibilidad ABAP introdujo al retirar la clasificación binaria entre limpio y no limpio (SAP Community, 2025).
Un último matiz que el árbol debe permitir: la respuesta no siempre es una sola rama. Los enfoques híbridos modernos combinan un backend pro-code que sirve datos a un frontend low-code, precisamente para ganar velocidad sin perder gobernanza (Kellton, 2026).
En la próxima pieza de esta serie revisamos qué ocurre cuando el árbol se ignora en una sola dirección: el costo oculto de forzar todo adentro, más allá del límite de lo que in-app fue diseñado para sostener.
Fuentes
- SAP Help Portal — SAP Application Extension Methodology Overview: https://help.sap.com/docs/sap-btp-guidance-framework/sap-application-extension-methodology/sap-application-extension-methodology-overview
- SAP Learning — Choosing the Appropriate Extensibility Option: https://learning.sap.com/courses/expanding-sap-s-4hana-using-key-user-side-by-side-extensibility/choosing-the-appropriate-extensibility-option
- SAP Learning — Explaining the Extensibility Possibilities, Depending on the SAP S/4HANA Version: https://learning.sap.com/courses/expanding-sap-s-4hana-using-key-user-side-by-side-extensibility/explaining-the-extensibility-possibilities-depending-on-the-sap-s-4hana-version
- SAP Learning — Utilizing the Clean Core Strategy and Extensibility Tools: https://learning.sap.com/courses/exploring-sap-cloud-erp/utilizing-the-clean-core-strategy-and-extensibility-tools
- SAP Community (2024) — SAP S/4HANA APIs and Where to Find Them: https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/sap-s-4hana-apis-and-where-to-find-them/ba-p/13723939
- SAP Community (2024) — Explore Business Add-Ins (BAdIs) for SAP S/4HANA Cloud on SAP Business Accelerator Hub: https://community.sap.com/t5/technology-blog-posts-by-sap/explore-business-add-ins-badis-for-sap-s-4hana-cloud-on-sap-business/ba-p/13541140
- SAP Community (2024) — Extensibility: how to implement Custom Fields using Coding Block business context in SAP S/4HANA Cloud: https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/extensibility-how-to-implement-custom-fields-using-coding-block-business/ba-p/13573165
- SAP Community (2024) — In-App Extension / Key User Extension: https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/in-app-extension-key-user-extension/ba-p/13550312
- SAP Community (2025) — ABAP Extensibility Guide – Clean Core for SAP S/4HANA Cloud, August 2025 Update: 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
- Kellton (2026) — The Definitive Guide to SAP BTP Side-by-Side Extensions in 2026: https://www.kellton.com/kellton-tech-blog/sap-btp-side-by-side-extension-guide
¿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.
