No necesariamente porque SUM falle. El problema puede estar en algo mucho m\u00e1s dif\u00edcil de reproducir fuera de producci\u00f3n: el comportamiento real de los usuarios, las interfaces, los jobs y las transacciones mientras la conversi\u00f3n se est\u00e1 ejecutando.<\/p>\n\n\n\n
En proyectos que utilizan estrategias downtime-optimized, esto se vuelve especialmente importante. Durante determinadas fases de la conversi\u00f3n, SUM utiliza triggers sobre las tablas para controlar cambios, registrar modificaciones o impedir escrituras.<\/p>\n\n\n\n
La pregunta es simple. \u00bfQu\u00e9 pasa cuando un proceso productivo intenta modificar una de esas tablas?<\/p>\n\n\n\n
La respuesta muchas veces aparece demasiado tarde.<\/p>\n\n\n\n
En una conversi\u00f3n S\/4HANA solemos ejecutar varios ciclos antes de producci\u00f3n.<\/p>\n\n\n\n
Sandbox, DEV, QAS, Preproducci\u00f3n, Mock conversion. Con cada iteraci\u00f3n intentamos mejorar el procedimiento y reducir el downtime.<\/p>\n\n\n\n
El problema es que ninguno de esos sistemas reproduce perfectamente el comportamiento productivo. En producci\u00f3n tenemos simult\u00e1neamente 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\u00f3modo.<\/p>\n\n\n\n
El downtime medido en QAS es bueno, el Load Verification parece controlado, pero cuando ejecutamos el escenario contra producci\u00f3n aparecen transacciones afectadas, problemas de performance o un volumen de cambios mucho mayor al esperado.<\/p>\n\n\n\n
SUM Trigger Simulation intenta justamente adelantar ese momento de descubrimiento.<\/p>\n\n\n\n
Trigger Simulation es una funcionalidad de Software Update Manager que permite crear y administrar triggers similares a los utilizados durante una conversi\u00f3n S\/4HANA. Seg\u00fan la documentaci\u00f3n publicada por SAP, se requiere SUM SP26 o superior.<\/p>\n\n\n\n
Tambi\u00e9n es necesario disponer de la clasificaci\u00f3n de tablas contenida en En un escenario downtime-optimized podemos encontrarnos principalmente con tres tipos.<\/p>\n\n\n\n Son triggers de registro.<\/p>\n\n\n\n Las operaciones de modificaci\u00f3n sobre la tabla contin\u00faan estando permitidas, pero los cambios se registran para poder replicarlos posteriormente al sistema destino.<\/p>\n\n\n\n Esto incluye operaciones INSERT, UPDATE y DELETE.<\/p>\n\n\n\n En este caso la tabla queda protegida contra modificaciones.<\/p>\n\n\n\n Las lecturas pueden continuar, pero las operaciones DML quedan restringidas.<\/p>\n\n\n\n Este es uno de los escenarios que puede generar problemas cuando un proceso de negocio intenta actualizar una tabla durante la ventana de conversi\u00f3n.<\/p>\n\n\n\n Estos triggers se utilizan para mantener una imagen consistente de determinados datos involucrados en la conversi\u00f3n.<\/p>\n\n\n\n Permiten conservar el estado necesario para reconstruir correctamente la informaci\u00f3n en el destino.<\/p>\n\n\n\n Dentro del mecanismo FREEZE existen diferentes modos.<\/p>\n\n\n\n El que considero m\u00e1s \u00fatil para una evaluaci\u00f3n preventiva es En este modo las operaciones DML no se bloquean inmediatamente.<\/p>\n\n\n\n El sistema permite la operaci\u00f3n, pero registra el acceso.<\/p>\n\n\n\n Esto permite observar qu\u00e9 ocurrir\u00eda durante una conversi\u00f3n real sin generar inicialmente un impacto funcional sobre el usuario.<\/p>\n\n\n\n El primer acceso relevante queda registrado en la tabla Despu\u00e9s podemos analizar qu\u00e9 tabla fue accedida, en qu\u00e9 momento y correlacionarlo con el proceso, usuario o transacci\u00f3n responsable.<\/p>\n\n\n\n Hay una particularidad importante.<\/p>\n\n\n\n El an\u00e1lisis debe hacerse desde herramientas de base de datos como HANA Studio, SQL Console u otra herramienta SQL equivalente.<\/p>\n\n\n\n La herramienta tiene sentido solamente si definimos previamente qu\u00e9 queremos observar.<\/p>\n\n\n\n Yo separar\u00eda el an\u00e1lisis en tres grupos.<\/p>\n\n\n\n Primero tenemos que identificar tablas con FREEZE triggers que reciben operaciones INSERT, UPDATE o DELETE durante la actividad normal.<\/p>\n\n\n\n El objetivo no deber\u00eda ser solamente generar una lista de tablas.<\/p>\n\n\n\n Necesitamos correlacionarlas con procesos de negocio.<\/p>\n\n\n\n Por ejemplo<\/p>\n\n\n\n tabla afectada Eso nos permite responder una pregunta mucho m\u00e1s \u00fatil.<\/p>\n\n\n\n \u00bfQu\u00e9 proceso productivo puede fallar cuando esa tabla quede realmente congelada?<\/p>\n\n\n\n Con esa informaci\u00f3n podemos decidir si el proceso debe detenerse durante la conversi\u00f3n, cambiarse de horario, incluirse dentro del downtime o tratarse de otra manera.<\/p>\n\n\n\n Los triggers tambi\u00e9n pueden modificar el comportamiento de determinadas consultas.<\/p>\n\n\n\n Por eso conviene seleccionar previamente las transacciones y procesos cr\u00edticos.<\/p>\n\n\n\n Por ejemplo<\/p>\n\n\n\n cierres Primero deber\u00edamos medir una baseline sin triggers.<\/p>\n\n\n\n Luego repetir la medici\u00f3n con Trigger Simulation activa.<\/p>\n\n\n\n Y comparar.<\/p>\n\n\n\n Tiempo total.<\/p>\n\n\n\n CPU.<\/p>\n\n\n\n Lecturas.<\/p>\n\n\n\n Duraci\u00f3n SQL.<\/p>\n\n\n\n Volumen procesado.<\/p>\n\n\n\n Locks.<\/p>\n\n\n\n Waits.<\/p>\n\n\n\n No alcanza con saber que la transacci\u00f3n sigue funcionando.<\/p>\n\n\n\n Tambi\u00e9n necesitamos saber si pasa de ejecutar en 5 segundos a ejecutar en 45.<\/p>\n\n\n\n En sistemas grandes esta parte deber\u00eda revisarse junto con alguien con experiencia real en performance de base de datos.<\/p>\n\n\n\n El tercer punto es entender cu\u00e1ntos cambios se producen mientras los triggers est\u00e1n activos.<\/p>\n\n\n\n En escenarios con Change Record and Replay, esos cambios posteriormente deben aplicarse en el destino.<\/p>\n\n\n\n Por lo tanto, cuanto mayor sea el volumen generado durante la fase de uptime, mayor puede ser tambi\u00e9n el trabajo requerido para sincronizar el estado final.<\/p>\n\n\n\n Esto puede afectar indirectamente el downtime.<\/p>\n\n\n\n Por eso no alcanza con medir solamente cu\u00e1nto tarda la migraci\u00f3n inicial.<\/p>\n\n\n\n Tambi\u00e9n hay que medir cu\u00e1nto delta genera realmente el sistema productivo durante ese per\u00edodo.<\/p>\n\n\n\n No esperar\u00eda al \u00faltimo ensayo.<\/p>\n\n\n\n Lo incorporar\u00eda relativamente temprano dentro del plan de conversi\u00f3n.<\/p>\n\n\n\n Un enfoque razonable ser\u00eda el siguiente.<\/p>\n\n\n\n Primero ejecutar la simulaci\u00f3n en QAS o preproducci\u00f3n.<\/p>\n\n\n\n Ah\u00ed el equipo t\u00e9cnico puede familiarizarse con la herramienta, validar el procedimiento y aprender a analizar los resultados.<\/p>\n\n\n\n Despu\u00e9s realizar un Day in the Life Test con los procesos cr\u00edticos.<\/p>\n\n\n\n Una vez entendido el comportamiento, planificar una simulaci\u00f3n controlada en producci\u00f3n.<\/p>\n\n\n\n La creaci\u00f3n de triggers puede realizarse inicialmente en modo inactivo.<\/p>\n\n\n\n SUM permite controlar las fases de creaci\u00f3n, activaci\u00f3n y eliminaci\u00f3n.<\/p>\n\n\n\n Esto permite separar la preparaci\u00f3n de la ventana efectiva de observaci\u00f3n.<\/p>\n\n\n\n Durante la simulaci\u00f3n productiva utilizar\u00eda primero modos de logging.<\/p>\n\n\n\n La idea inicial deber\u00eda ser observar.<\/p>\n\n\n\n No bloquear.<\/p>\n\n\n\n Despu\u00e9s de obtener datos podemos identificar los procesos realmente conflictivos.<\/p>\n\n\n\n Supongamos que durante Trigger Simulation aparece actividad sobre una tabla con FREEZE trigger.<\/p>\n\n\n\n Analizando En QAS nunca apareci\u00f3 el problema porque ese job solamente existe en producci\u00f3n.<\/p>\n\n\n\n Durante una conversi\u00f3n real, el job podr\u00eda fallar.<\/p>\n\n\n\n Sin Trigger Simulation, probablemente lo descubrir\u00edamos durante el Load Verification o directamente en el cutover.<\/p>\n\n\n\n Con la simulaci\u00f3n podemos definir previamente una acci\u00f3n.<\/p>\n\n\n\n Detener el job durante determinada fase.<\/p>\n\n\n\n Cambiar su planificaci\u00f3n.<\/p>\n\n\n\n Modificar temporalmente el proceso.<\/p>\n\n\n\n O incluirlo expl\u00edcitamente dentro del runbook de conversi\u00f3n.<\/p>\n\n\n\n Ese es el verdadero valor de la herramienta.<\/p>\n\n\n\n No hacer la migraci\u00f3n m\u00e1s r\u00e1pida autom\u00e1ticamente.<\/p>\n\n\n\n Hacerla m\u00e1s predecible.<\/p>\n\n\n\n Hay que evitar venderla como una garant\u00eda de downtime.<\/p>\n\n\n\n No lo es.<\/p>\n\n\n\n El tiempo final sigue dependiendo de muchos factores.<\/p>\n\n\n\n Volumen de datos.<\/p>\n\n\n\n Performance de origen y destino.<\/p>\n\n\n\n Throughput.<\/p>\n\n\n\n Red.<\/p>\n\n\n\n SUM phases.<\/p>\n\n\n\n Procesos de conversi\u00f3n.<\/p>\n\n\n\n Cantidad de cambios.<\/p>\n\n\n\n Custom code.<\/p>\n\n\n\n Simplification Items.<\/p>\n\n\n\n Errores inesperados.<\/p>\n\n\n\n Adem\u00e1s, activar triggers sobre un sistema productivo no es una actividad trivial.<\/p>\n\n\n\n Aunque utilicemos modos de logging, deber\u00edamos definir previamente monitoreo, criterios de abort, responsables y una ventana controlada.<\/p>\n\n\n\n En proyectos S\/4HANA donde se utilicen opciones downtime-optimized, incorporar\u00eda Trigger Simulation como una actividad formal del plan de migraci\u00f3n.<\/p>\n\n\n\n No como una herramienta de troubleshooting utilizada al final.<\/p>\n\n\n\n La secuencia podr\u00eda ser algo parecido a<\/p>\n\n\n\n Mock Conversion La diferencia parece peque\u00f1a.<\/p>\n\n\n\n Pero conceptualmente es importante.<\/p>\n\n\n\n Pasamos de esperar que los ensayos encuentren todos los problemas a buscar deliberadamente aquellos problemas que solamente aparecen con carga productiva.<\/p>\n","protected":false},"excerpt":{"rendered":" SUM Trigger Simulation \u2014 C\u00f3mo anticipar problemas de downtime antes de una conversi\u00f3n productiva a S\/4HANA No necesariamente porque SUM falle. El problema puede estar en algo mucho m\u00e1s dif\u00edcil de reproducir fuera de producci\u00f3n: el comportamiento real de los usuarios, las interfaces, los jobs y las transacciones mientras la conversi\u00f3n se est\u00e1 ejecutando. En […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-127","post","type-post","status-publish","format-standard","hentry","category-sin-categoria"],"_links":{"self":[{"href":"https:\/\/dedelberg.com.ar\/index.php\/wp-json\/wp\/v2\/posts\/127","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dedelberg.com.ar\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dedelberg.com.ar\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dedelberg.com.ar\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dedelberg.com.ar\/index.php\/wp-json\/wp\/v2\/comments?post=127"}],"version-history":[{"count":1,"href":"https:\/\/dedelberg.com.ar\/index.php\/wp-json\/wp\/v2\/posts\/127\/revisions"}],"predecessor-version":[{"id":128,"href":"https:\/\/dedelberg.com.ar\/index.php\/wp-json\/wp\/v2\/posts\/127\/revisions\/128"}],"wp:attachment":[{"href":"https:\/\/dedelberg.com.ar\/index.php\/wp-json\/wp\/v2\/media?parent=127"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dedelberg.com.ar\/index.php\/wp-json\/wp\/v2\/categories?post=127"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dedelberg.com.ar\/index.php\/wp-json\/wp\/v2\/tags?post=127"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}PUTTB_SHD.ZIP<\/code>, generada a partir de una conversi\u00f3n S\/4HANA ya completada. Con esa informaci\u00f3n, SUM puede recrear sobre el sistema los distintos comportamientos que tendr\u00e1n las tablas durante la conversi\u00f3n. Esto permite estudiar el impacto antes del ciclo definitivo.<\/p>\n\n\n\nLos principales tipos de triggers<\/h2>\n\n\n\n
UKR<\/h3>\n\n\n\n
FREEZE<\/h3>\n\n\n\n
SNAPSHOT<\/h3>\n\n\n\n
FREEZE_LOG, la parte m\u00e1s interesante<\/h2>\n\n\n\n
FREEZE_LOG<\/code>.<\/p>\n\n\n\nUPGILLACCESS<\/code>.<\/p>\n\n\n\nUPGILLACCESS<\/code> no se consulta normalmente desde herramientas ABAP como SE16.<\/p>\n\n\n\nQu\u00e9 deber\u00edamos medir<\/h2>\n\n\n\n
1. Procesos que escriben sobre tablas afectadas<\/h2>\n\n\n\n
transacci\u00f3n
usuario t\u00e9cnico o funcional
job
interfaz
horario
frecuencia<\/p>\n\n\n\n2. Impacto sobre performance<\/h2>\n\n\n\n
MRP
facturaci\u00f3n
interfaces de alto volumen
batch jobs cr\u00edticos
reportes intensivos
procesos Z importantes<\/p>\n\n\n\n3. Volumen de cambios generado<\/h2>\n\n\n\n
C\u00f3mo incorporar\u00eda Trigger Simulation al proyecto<\/h2>\n\n\n\n
Un ejemplo simple<\/h2>\n\n\n\n
UPGILLACCESS<\/code> descubrimos que la modificaci\u00f3n proviene de un job Z ejecutado cada veinte minutos.<\/p>\n\n\n\nLo que Trigger Simulation no resuelve<\/h2>\n\n\n\n
Mi recomendaci\u00f3n<\/h2>\n\n\n\n
\u2192 Day in the Life Test
\u2192 Trigger Simulation en preproducci\u00f3n
\u2192 baseline de performance
\u2192 Trigger Simulation controlada en producci\u00f3n
\u2192 an\u00e1lisis de UPGILLACCESS<\/code>
\u2192 ajuste de procesos
\u2192 Load Verification
\u2192 conversi\u00f3n productiva<\/p>\n\n\n\n