Open Office Hours Temporada 1: Sesión 8 - Logs & Runs: tu caja de herramientas para resolver problemas
Cómo usar los logs y los runs de MyRapidi para resolver problemas en tu integración
Cuando tu integración da un error, la primera pregunta siempre es la misma: ¿dónde miro? En MyRapidi, los logs y los runs te dan la respuesta. Muestran exactamente qué pasó, qué transferencia lo provocó, cuánto tardó y qué dice el mensaje de error. Una vez que sabes leerlos, resolver problemas es mucho más rápido.
Este artículo explica qué son los runs y los logs, cómo funcionan juntos y cómo usarlos para diagnosticar y corregir problemas en tu integración.
Resumen rápido
Mira la sesión completa
Este artículo se basa en la sesión 8 del programa de formación Open Office Hours de Rapidi. La sesión completa incluye un recorrido en vivo por los runs y los logs de MyRapidi, un ejemplo real de mensaje de error y una demostración de Albert en acción.
Diapositivas de la presentación
¿Qué es un run?
Un run es un único evento de ejecución. Cada vez que se dispara una programación o ejecutas una transferencia manualmente, MyRapidi crea un registro de run que agrupa todo lo que ocurrió en ese momento.
Por ejemplo, si tienes una programación que se ejecuta cada hora, verás una entrada de run por hora. Cada entrada muestra la fecha y la hora, los sistemas de origen y de destino, la descripción (nombre de la programación o de la transferencia), cuánto tardó y un icono de estado.
Los iconos de estado te lo indican de un vistazo:
- Marca de verificación verde: el run se completó sin problemas
- Icono rojo: algo falló y requiere tu atención
- Amarillo (en proceso): la transferencia todavía se está ejecutando
Los runs también distinguen dos tipos de ejecución. Una «S» junto a un run significa que lo lanzó el planificador. Una «M» significa que se ejecutó manualmente, por ejemplo después de actualizar un mapeo o porque querías probar algo.
Puedes llegar a la página de runs directamente desde Logs > Runs, o desde la página Schedules haciendo clic en el icono de runs junto a una programación concreta. La segunda opción es útil cuando quieres ver solo los runs de una programación.
¿Para qué sirven los runs?
Los runs cumplen cuatro funciones principales:
- Seguir las ejecuciones. Consulta cada run en orden cronológico con fecha, hora, origen y destino. Así tienes una visión completa de qué se ha ejecutado y cuándo.
- Detectar errores rápidamente. Los iconos de estado señalan al instante los runs fallidos. También puedes filtrar para mostrar solo los runs con errores y saltarte todo lo que se ejecutó sin incidencias.
- Medir la duración. Cada run muestra cuánto tardó. Si una transferencia que normalmente tarda 2 minutos de repente tarda 15, es una señal que vale la pena investigar. Aquí es donde los campos datetime y los filtros de tus transferencias marcan la diferencia, porque controlan cuántos datos se extraen en cada run.
- Saltar a las entradas de log. Desde cualquier run, puedes expandir el registro y ver la lista completa de entradas de log que le pertenecen. Es el camino más rápido para entender qué ocurrió realmente.
¿Qué son los logs?
Una entrada de log es un registro detallado de lo que ocurrió dentro del run de una transferencia. Piensa en el run como el elemento principal y en las entradas de log como el detalle que contiene.
Cada entrada de log te muestra el nombre de la transferencia, los sistemas de origen y de destino, cuántos registros se leyeron, insertaron, actualizaron y eliminaron, además de los posibles mensajes de error. Si tienes una programación con cinco transferencias, verás cinco entradas de log dentro de un solo run.
Los logs sirven para:
- Diagnosticar errores: las entradas en rojo y los indicadores de error señalan exactamente dónde falló algo y qué sistema envió el error.
- Auditar el número de registros: puedes comprobar cuántos registros se procesaron y verificar que las cifras coinciden con lo que esperabas.
- Filtrar y buscar: filtra por transferencia, programación, rango de fechas, conexión o estado de error para encontrar justo lo que necesitas sin desplazarte por páginas y páginas de entradas.
- Rastrear un run completo: sigue un run a través de todas sus entradas de log para reconstruir el panorama completo de lo que ocurrió y en qué orden.
Cómo encontrar y diagnosticar errores
Cuando algo falla, este es el proceso que debes seguir:
-
Ve a Runs. Busca el icono rojo de error. También puedes usar el filtro de estado de error para mostrar solo los runs fallidos.
-
Expande el run. Haz clic en la flecha para expandirlo. Verás todas las entradas de log de esa ejecución agrupadas por transferencia. La que tiene el error aparecerá resaltada en rojo.
-
Lee el mensaje de error. Cada entrada muestra el código de error y su descripción. Algunos sistemas te dan un mensaje largo y detallado que apunta directamente al registro. Otros te dan algo breve y críptico. En cualquier caso, el log también te indica qué conexión envió el error, para que sepas si tienes que mirar en el sistema de origen o en el de destino.
-
Pregunta a Albert. Si el mensaje de error no está claro, haz clic en el icono de persona a la derecha de la entrada de log. Se abrirá un chat con Albert, el asistente de IA de Rapidi, con el mensaje de error ya cargado. Albert está conectado a la wiki de Rapidi y puede sugerirte qué significa el error y qué revisar a continuación.
Si Albert no te da una respuesta clara, busca directamente en la wiki de Rapidi con palabras clave del mensaje de error. Si aun así no puedes resolverlo, ponte en contacto con el soporte.
Algo que conviene saber: el mensaje de error del log procede del sistema de destino, no de Rapidi. Así que, si envías datos de Business Central a Salesforce y algo falla, el error que ves es lo que Salesforce devolvió. Eso te indica dónde centrar tu atención.
La fórmula Message: añade contexto a tus logs
Algunos mensajes de error no indican qué registro concreto causó el problema. Cuando eso ocurre, la fórmula Message puede ayudarte.
La fórmula Message es un ajuste que añades a una transferencia. Le indica a MyRapidi que incluya el valor de un campo concreto en la salida del log. Por ejemplo, si estás transfiriendo clientes, podrías añadir a la fórmula el campo del número de cliente. Así, cada vez que se ejecute esa transferencia, el log mostrará el número de cliente junto a cada registro, lo que facilita mucho localizar el registro que tiene un problema.
Puedes añadir varios campos a la fórmula si necesitas más contexto. Esto resulta especialmente útil en transferencias en las que los mensajes de error del sistema conectado son poco precisos.
Filtrar runs y logs
La página de runs y la página de logs tienen el mismo conjunto de filtros. Puedes filtrar por:
- Rango de fecha y hora
- Programación
- Grupo
- Transferencia
- Conexión de origen o de destino
- Estado (completado o con error)
- Búsqueda por palabra clave
Si vas a la página Schedules y haces clic en el icono de runs de una programación concreta, la página de runs se abrirá ya filtrada por esa programación. A partir de ahí puedes añadir más filtros para acotar aún más los resultados.
Mira todas las sesiones e inscríbete en las próximas: rapidionline.com/resources/open-office-hours
Open Office Hours
Cada semana, nuestros especialistas en integración imparten una sesión de formación gratuita de 30 minutos sobre un tema concreto de MyRapidi.
Consulta el calendario completo de la temporada 1: rapidionline.com/product-updates/open-office-hours-season-1
Preguntas frecuentes
Mi mensaje de error es muy corto y no explica qué salió mal. ¿Qué debo hacer?
Los mensajes de error crípticos son habituales, y su origen depende del sistema. Algunos ERP y CRM devuelven códigos muy breves sin mucho contexto. La forma más rápida de resolverlo es hacer clic en el icono de Albert a la derecha de la entrada de log. Albert abre un chat con el error ya cargado y puede sugerirte qué significa y qué revisar. Si eso no ayuda, copia el mensaje de error y búscalo en la wiki de Rapidi. Como último paso, ponte en contacto con el soporte y facilita la entrada de log completa.
¿Cómo sé si los errores vienen del sistema de origen o del sistema de destino?
Cada entrada de log muestra una etiqueta «error on connection» que te indica exactamente qué sistema envió el error. Si estás enviando datos de Business Central a Salesforce y Salesforce rechaza un registro, el log indicará que el error vino de la conexión de Salesforce. Eso te dice dónde mirar. Si el error viene del origen, lo más probable es que el registro no exista o tenga algún problema en el momento de la lectura. Si viene del destino, el sistema receptor no aceptó los datos, lo que suele apuntar a una regla de validación de un campo, a un campo obligatorio que falta o a un formato de datos que no coincide.
Se producen errores, pero nadie se da cuenta hasta que algo falla más adelante en el proceso. ¿Cómo podemos detectarlos antes?
Es uno de los problemas de integración más comunes. En MyRapidi, la página de runs muestra un icono de estado rojo cada vez que falla una transferencia, así que revisarla con regularidad es el primer paso. Acostumbrarte a revisar los runs al principio de cada día te lleva menos de un minuto. También puedes usar el filtro de estado de error para mostrar solo los runs fallidos, así no tienes que desplazarte por todo. En los equipos que usan Continue on Error, los errores de datos se guardan por separado en Logs > Data Errors y no aparecen en el estado principal del run, por lo que esa página necesita su propia revisión periódica. También hay notificaciones por correo electrónico para los errores de datos — ponte en contacto con el soporte de Rapidi para que las configuren en tu servicio.
Los mismos registros fallan en cada run. ¿Por qué no desaparece el error después de revisar el log?
Ver una entrada de log no soluciona el problema de fondo. Si los mismos registros fallan una y otra vez, el problema está en los propios datos o en la configuración del sistema, no en el log. Entre las causas habituales están un campo obligatorio en el sistema de destino que está vacío en el origen, un formato de datos que no coincide con lo que espera el sistema receptor o una regla de validación del sistema de destino que el registro no cumple. Usa la descripción del error del log y la fórmula Message (si la tienes configurada) para identificar el registro concreto y, después, corrígelo en el sistema de origen o de destino. Si el error es sistemático en muchos registros, revisa los mapeos de campos en la configuración de la transferencia.
Mis transferencias tardan mucho más de lo habitual. ¿Por dónde empiezo a buscar el problema?
Empieza por la página de runs y fíjate en la columna de duración. Compara los runs recientes con los más antiguos para ver cuándo empezó la ralentización. La causa más común de las transferencias lentas es que el filtro datetime de la transferencia está extrayendo demasiados datos, ya sea porque está mal configurado o porque alguien lo cambió. Comprueba que tus transferencias usan correctamente los campos datetime, de modo que en cada run solo se extraigan los registros nuevos o actualizados, y no el conjunto de datos completo. Si la duración parece normal pero la programación en conjunto va más lenta, comprueba si otra transferencia de la misma programación es el cuello de botella: expande el run y compara los tiempos de cada transferencia.