Aplicaciones personalizadas (Z-Apps)

El nombre procede de la regla de nomenclatura de ABAP: sin un espacio de nombres con prefijo registrado, los objetos de repositorio creados en los sistemas del cliente deben empezar por Y o Z. "Z-app" se ha convertido en la forma abreviada de designar cualquier aplicación que el cliente crea y posee, sea cual sea su tecnología:

• apps freestyle SAPUI5 para tareas que ninguna app estándar cubre;
• apps de SAP Fiori elements sobre vistas CDS y servicios personalizados;
• copias de apps entregadas por SAP, renombradas en el espacio de nombres Z y modificadas;
• transacciones, informes o aplicaciones Web Dynpro ABAP personalizados que se inician desde el launchpad;
• apps side-by-side en SAP BTP que amplían procesos de SAP S/4HANA.

Algunas organizaciones registran su propio espacio de nombres con prefijo en lugar de usar Z o Y, lo que evita conflictos de nombres entre proyectos. El rasgo que la define es la propiedad, no la letra: una Z-app es cualquier aplicación cuyo ciclo de vida es responsabilidad del cliente, no de SAP.

Una app personalizada típica en el propio stack afecta a todas las capas situadas por debajo del launchpad:

1. Datos y lógica: vistas CDS y, en las aplicaciones transaccionales, un business object creado con el ABAP RESTful application programming model; las apps más antiguas usan ABAP clásico.
2. Servicio: un servicio OData, publicado mediante un service binding de RAP o, en las apps más antiguas, creado en el Gateway Service Builder (SEGW) y activado en /IWFND/MAINT_SERVICE.
3. UI: una app de SAP Fiori elements o freestyle SAPUI5, desplegada en el repositorio ABAP de SAPUI5, donde cada app se almacena como una aplicación BSP con un nombre Z o Y.
4. Contenido del launchpad: un tile y un target mapping en un technical catalog creado con el launchpad app manager (/UI2/FLPAM), referenciado en un business catalog y asignado mediante un rol en PFCG.
5. Transporte: todos los objetos viajan juntos por el entorno de transportes.

Cada uno de los cinco pasos crea un objeto que el cliente debe mantener coherente más adelante. Por tanto, una app SAP Fiori personalizada es un pequeño producto con varias piezas móviles, no un único archivo.

• Ajuste exacto: una app personalizada puede modelar un paso del proceso tal como trabaja realmente el negocio, incluidos pasos que SAP no entrega.
• Diferenciación: los procesos que distinguen a una empresa son los que menos probabilidades tienen de estar cubiertos por apps estándar.
• La misma experiencia de usuario: creada con SAP Fiori elements o SAPUI5, una app personalizada tiene el mismo aspecto y comportamiento que las apps de SAP y usa el mismo launchpad, los mismos roles y la misma navegación.
• Opciones modernas y compatibles con los upgrades: las apps creadas con ABAP Cloud sobre API liberadas, o side-by-side en SAP BTP, pueden mantenerse estables en los upgrades.

Ejemplo: Alder Manufacturing crea una pequeña app para que sus compradores confirmen las franjas de entrega de Bright Freight, un paso que ninguna app estándar ofrece, y la enlaza desde el pedido de compra. Donde termina el estándar pero no el proceso, una app personalizada suele ser la forma más directa de cubrir la carencia.

• La responsabilidad nunca termina. Cada upgrade de SAPUI5, release del back-end y revisión de seguridad afecta a la app. Alguien tiene que probarla, corregirla y saber por qué existe.
• Las dependencias determinan el coste. Las apps que usan objetos de SAP no liberados caen en los niveles inferiores de clean core y pueden fallar durante los upgrades; las apps sobre API liberadas conllevan mucho menos riesgo.
• El conocimiento se va con las personas. Muchas apps personalizadas las creó un único desarrollador o partner; cuando se marchan, la finalidad y la lógica de la app suelen ser difíciles de reconstruir.
• Las copias se desvían. Una app de SAP copiada no recibe las correcciones ni las mejoras de SAP, y la distancia aumenta con cada release.
• Lagunas de inventario. Con frecuencia las organizaciones no saben cuántas apps personalizadas ejecutan ni quién las usa, una queja frecuente en las comunidades de profesionales.

Estos límites no son defectos técnicos; son el precio de poseer software que SAP no mantiene.

Recorra la escalera de extensión de arriba abajo y deténgase en el primer peldaño que encaje:

1. Estándar: busque en la SAP Fiori Apps Reference Library una app o un sucesor que cubra la necesidad.
2. Extensibilidad key user: un campo, una comprobación o un valor por defecto que faltan corresponden a este nivel, no a una app nueva.
3. Variante de app en lugar de copia: para modificar una app entregada por SAP, un adaptation project de SAPUI5 crea una variante que sigue recibiendo las actualizaciones de SAP; SAP lo admite en Public Edition desde la release 2402.
4. Extensibilidad para desarrolladores en el propio stack: una app nueva sobre API liberadas con ABAP Cloud.
5. Side-by-side en SAP BTP: cuando la app abarca varios sistemas, necesita sus propios datos o tiene un ciclo de vida distinto.

Un error frecuente es copiar una app estándar para cambiar dos campos; la solución es un adaptation project o la extensibilidad key user. Una app personalizada está justificada cuando falta el propio paso del proceso, no cuando falta un campo.

• On-premise y Private Edition: están disponibles tanto ABAP clásico como ABAP Cloud, por lo que las apps personalizadas van desde un clean core completo hasta modificaciones profundas. Los límites los fija el gobierno, no el sistema.
• SAP S/4HANA Cloud Public Edition: la extensibilidad para desarrolladores permite a los clientes crear apps SAP Fiori personalizadas en un subconjunto de ABAP optimizado para la nube y solo sobre API liberadas; el desarrollo Z clásico con acceso sin restricciones no es posible.
• SAP BTP: las apps side-by-side residen en su propia subcuenta y con su propio ciclo de vida, y solo acceden a SAP S/4HANA mediante API.

La cuestión de la propiedad es la misma en todas las opciones; lo que difiere es cuánto restringe la plataforma aquello de lo que puede depender una app personalizada.