By mariogarcia El fallo que no parece un fallo
Una orquestación diaria consultaba inventario para generar órdenes de reposición cuando el stock caía bajo el nivel de seguridad. Un día, el filtro de la consulta quedó mal alineado con un cambio en el maestro de artículos, y la consulta empezó a devolver cero filas. La orquestación no falló: simplemente no había nada que procesar, así que terminó su ejecución en verde, como cualquier día sin reposiciones pendientes. El problema es que sí había reposiciones pendientes. Nadie lo notó hasta que un almacén se quedó sin un artículo crítico casi una semana después. 
Por qué Orchestrator no lo marca como error por diseño
Un data request que devuelve cero filas es, para el motor, un resultado válido — no una excepción. La lógica de negocio real (“cero filas aquí significa que algo está mal”) vive en la cabeza de quien diseñó el proceso, no en el framework. Si esa regla no se traduce a una validación explícita, el sistema no tiene forma de distinguir “no hay nada que hacer” de “algo se rompió antes de llegar aquí”.
La primera pieza: errores que ya dicen dónde mirar
Desde el Tool Release de mayo de 2024, cuando una excepción real ocurre en un Form Request, el detalle incluye el nombre del campo, el alias del data item y la tabla donde vive el valor — y para errores de grid, el número de fila exacto. La variable Simple Message Error traduce eso a un mensaje limpio para el usuario final, sin exponerle el detalle técnico crudo. Eso resuelve la mitad del problema: cuando algo falla de verdad, el diagnóstico es inmediato. Pero no resuelve el caso de la consulta que “funciona” y devuelve un resultado vacío que no debería ser posible.
La segunda pieza: hacer explícito lo que el negocio da por hecho
Para ese caso se añadió una Logic Extension justo después del data request de inventario: si el conteo de filas devueltas es cero, en vez de dejar que el proceso continúe silenciosamente, levanta un error de negocio a través de una llamada a BSFN, con un mensaje específico — “no se encontraron artículos bajo el nivel de seguridad para la selección indicada” — en vez de un genérico “0 rows returned” que nadie interpretaría como una alarma. La diferencia no es cosmética: un error de negocio explícito dispara notificación, aparece en el centro de mensajes, y alguien lo revisa el mismo día. Un resultado vacío silencioso no dispara nada.
Impacto medible
Desde que se implementó esta validación en los procesos críticos de reposición y facturación, el tiempo medio para detectar un fallo de configuración pasó de “días, cuando alguien nota la consecuencia” a “minutos, cuando llega la notificación”. No se trata de una feature exótica — es una línea de validación que cuesta minutos de construir y que decide si un problema se resuelve antes o después de que impacte al negocio. ¿Cuántos de tus procesos automatizados asumen que “sin resultado” siempre significa “todo bien”?