SUM Trigger Simulation — Cómo anticipar problemas de downtime antes de una conversión productiva a S/4HANA
No necesariamente porque SUM falle. El problema puede estar en algo mucho más difícil de reproducir fuera de producción: el comportamiento real de los usuarios, las interfaces, los jobs y las transacciones mientras la conversión se está ejecutando.
En proyectos que utilizan estrategias downtime-optimized, esto se vuelve especialmente importante. Durante determinadas fases de la conversión, SUM utiliza triggers sobre las tablas para controlar cambios, registrar modificaciones o impedir escrituras.
La pregunta es simple. ¿Qué pasa cuando un proceso productivo intenta modificar una de esas tablas?
La respuesta muchas veces aparece demasiado tarde.
En una conversión S/4HANA solemos ejecutar varios ciclos antes de producción.
Sandbox, DEV, QAS, Preproducción, Mock conversion. Con cada iteración intentamos mejorar el procedimiento y reducir el downtime.
El problema es que ninguno de esos sistemas reproduce perfectamente el comportamiento productivo. En producción tenemos simultáneamente usuarios, interfaces, batch jobs, RFCs, procesos externos y cargas que muchas veces no aparecen con la misma intensidad durante un ensayo, por eso puede pasar algo bastante incómodo.
El downtime medido en QAS es bueno, el Load Verification parece controlado, pero cuando ejecutamos el escenario contra producción aparecen transacciones afectadas, problemas de performance o un volumen de cambios mucho mayor al esperado.
SUM Trigger Simulation intenta justamente adelantar ese momento de descubrimiento.
Qué es SUM Trigger Simulation
Trigger Simulation es una funcionalidad de Software Update Manager que permite crear y administrar triggers similares a los utilizados durante una conversión S/4HANA. Según la documentación publicada por SAP, se requiere SUM SP26 o superior.
También es necesario disponer de la clasificación de tablas contenida en PUTTB_SHD.ZIP, generada a partir de una conversión S/4HANA ya completada. Con esa información, SUM puede recrear sobre el sistema los distintos comportamientos que tendrán las tablas durante la conversión. Esto permite estudiar el impacto antes del ciclo definitivo.
Los principales tipos de triggers
En un escenario downtime-optimized podemos encontrarnos principalmente con tres tipos.
UKR
Son triggers de registro.
Las operaciones de modificación sobre la tabla continúan estando permitidas, pero los cambios se registran para poder replicarlos posteriormente al sistema destino.
Esto incluye operaciones INSERT, UPDATE y DELETE.
FREEZE
En este caso la tabla queda protegida contra modificaciones.
Las lecturas pueden continuar, pero las operaciones DML quedan restringidas.
Este es uno de los escenarios que puede generar problemas cuando un proceso de negocio intenta actualizar una tabla durante la ventana de conversión.
SNAPSHOT
Estos triggers se utilizan para mantener una imagen consistente de determinados datos involucrados en la conversión.
Permiten conservar el estado necesario para reconstruir correctamente la información en el destino.
FREEZE_LOG, la parte más interesante
Dentro del mecanismo FREEZE existen diferentes modos.
El que considero más útil para una evaluación preventiva es FREEZE_LOG.
En este modo las operaciones DML no se bloquean inmediatamente.
El sistema permite la operación, pero registra el acceso.
Esto permite observar qué ocurriría durante una conversión real sin generar inicialmente un impacto funcional sobre el usuario.
El primer acceso relevante queda registrado en la tabla UPGILLACCESS.
Después podemos analizar qué tabla fue accedida, en qué momento y correlacionarlo con el proceso, usuario o transacción responsable.
Hay una particularidad importante.
UPGILLACCESS no se consulta normalmente desde herramientas ABAP como SE16.
El análisis debe hacerse desde herramientas de base de datos como HANA Studio, SQL Console u otra herramienta SQL equivalente.
Qué deberíamos medir
La herramienta tiene sentido solamente si definimos previamente qué queremos observar.
Yo separaría el análisis en tres grupos.
1. Procesos que escriben sobre tablas afectadas
Primero tenemos que identificar tablas con FREEZE triggers que reciben operaciones INSERT, UPDATE o DELETE durante la actividad normal.
El objetivo no debería ser solamente generar una lista de tablas.
Necesitamos correlacionarlas con procesos de negocio.
Por ejemplo
tabla afectada
transacción
usuario técnico o funcional
job
interfaz
horario
frecuencia
Eso nos permite responder una pregunta mucho más útil.
¿Qué proceso productivo puede fallar cuando esa tabla quede realmente congelada?
Con esa información podemos decidir si el proceso debe detenerse durante la conversión, cambiarse de horario, incluirse dentro del downtime o tratarse de otra manera.
2. Impacto sobre performance
Los triggers también pueden modificar el comportamiento de determinadas consultas.
Por eso conviene seleccionar previamente las transacciones y procesos críticos.
Por ejemplo
cierres
MRP
facturación
interfaces de alto volumen
batch jobs críticos
reportes intensivos
procesos Z importantes
Primero deberíamos medir una baseline sin triggers.
Luego repetir la medición con Trigger Simulation activa.
Y comparar.
Tiempo total.
CPU.
Lecturas.
Duración SQL.
Volumen procesado.
Locks.
Waits.
No alcanza con saber que la transacción sigue funcionando.
También necesitamos saber si pasa de ejecutar en 5 segundos a ejecutar en 45.
En sistemas grandes esta parte debería revisarse junto con alguien con experiencia real en performance de base de datos.
3. Volumen de cambios generado
El tercer punto es entender cuántos cambios se producen mientras los triggers están activos.
En escenarios con Change Record and Replay, esos cambios posteriormente deben aplicarse en el destino.
Por lo tanto, cuanto mayor sea el volumen generado durante la fase de uptime, mayor puede ser también el trabajo requerido para sincronizar el estado final.
Esto puede afectar indirectamente el downtime.
Por eso no alcanza con medir solamente cuánto tarda la migración inicial.
También hay que medir cuánto delta genera realmente el sistema productivo durante ese período.
Cómo incorporaría Trigger Simulation al proyecto
No esperaría al último ensayo.
Lo incorporaría relativamente temprano dentro del plan de conversión.
Un enfoque razonable sería el siguiente.
Primero ejecutar la simulación en QAS o preproducción.
Ahí el equipo técnico puede familiarizarse con la herramienta, validar el procedimiento y aprender a analizar los resultados.
Después realizar un Day in the Life Test con los procesos críticos.
Una vez entendido el comportamiento, planificar una simulación controlada en producción.
La creación de triggers puede realizarse inicialmente en modo inactivo.
SUM permite controlar las fases de creación, activación y eliminación.
Esto permite separar la preparación de la ventana efectiva de observación.
Durante la simulación productiva utilizaría primero modos de logging.
La idea inicial debería ser observar.
No bloquear.
Después de obtener datos podemos identificar los procesos realmente conflictivos.
Un ejemplo simple
Supongamos que durante Trigger Simulation aparece actividad sobre una tabla con FREEZE trigger.
Analizando UPGILLACCESS descubrimos que la modificación proviene de un job Z ejecutado cada veinte minutos.
En QAS nunca apareció el problema porque ese job solamente existe en producción.
Durante una conversión real, el job podría fallar.
Sin Trigger Simulation, probablemente lo descubriríamos durante el Load Verification o directamente en el cutover.
Con la simulación podemos definir previamente una acción.
Detener el job durante determinada fase.
Cambiar su planificación.
Modificar temporalmente el proceso.
O incluirlo explícitamente dentro del runbook de conversión.
Ese es el verdadero valor de la herramienta.
No hacer la migración más rápida automáticamente.
Hacerla más predecible.
Lo que Trigger Simulation no resuelve
Hay que evitar venderla como una garantía de downtime.
No lo es.
El tiempo final sigue dependiendo de muchos factores.
Volumen de datos.
Performance de origen y destino.
Throughput.
Red.
SUM phases.
Procesos de conversión.
Cantidad de cambios.
Custom code.
Simplification Items.
Errores inesperados.
Además, activar triggers sobre un sistema productivo no es una actividad trivial.
Aunque utilicemos modos de logging, deberíamos definir previamente monitoreo, criterios de abort, responsables y una ventana controlada.
Mi recomendación
En proyectos S/4HANA donde se utilicen opciones downtime-optimized, incorporaría Trigger Simulation como una actividad formal del plan de migración.
No como una herramienta de troubleshooting utilizada al final.
La secuencia podría ser algo parecido a
Mock Conversion
→ Day in the Life Test
→ Trigger Simulation en preproducción
→ baseline de performance
→ Trigger Simulation controlada en producción
→ análisis de UPGILLACCESS
→ ajuste de procesos
→ Load Verification
→ conversión productiva
La diferencia parece pequeña.
Pero conceptualmente es importante.
Pasamos de esperar que los ensayos encuentren todos los problemas a buscar deliberadamente aquellos problemas que solamente aparecen con carga productiva.