Dos caminos: sí o no
«¿El monto supera el millón?» Todo lo que cumple va por un lado; todo lo que no, por el otro.
Es la que vas a usar el 80% de las veces.
Hasta ahora tu flujo hacía lo mismo con todo lo que le llegaba. Pero el trabajo real no es así: si el pedido es grande, avisa al jefe; si el cliente ya pagó, no le mandes el recordatorio; si falta un dato, apártalo para revisarlo.
Para eso están las condiciones: nodos que miran el dato y mandan el flujo por un camino o por otro.
[Si el monto > 1.000.000]
/ \
[Llega pedido] -> [SI] [NO]
| |
[Avisa al jefe] [Sigue normal]
| |
+----------> [Registra] <--+Los dos caminos pueden volver a juntarse, o no. Depende de si el resto del proceso es igual para ambos.
Según cuántos caminos necesites:
«¿El monto supera el millón?» Todo lo que cumple va por un lado; todo lo que no, por el otro.
Es la que vas a usar el 80% de las veces.
«Según la ciudad: Bogotá por aquí, Medellín por allá, el resto por el tercero.»
Hay un nodo para eso, y siempre conviene dejar una salida para «lo que no encaja en ninguno».
⚠️ Deja SIEMPRE previsto qué pasa con lo que no cumple ninguna condición. Si tu flujo contempla Bogotá y Medellín y llega un pedido de Cali, ese pedido desaparece sin dejar rastro: no da error, simplemente no va por ningún camino. Es de los fallos más difíciles de detectar, porque nada avisa.
Cuando hay varias condiciones encadenadas, se evalúan en orden y gana la primera que se cumple. Si las pones mal, el flujo funciona sin dar ningún error... y hace lo que no querías.
MAL:
si compra >= 100.000 -> descuento 5%
si compra >= 500.000 -> descuento 10%
Una compra de 800.000 entra por la PRIMERA y se lleva el 5%.
Nunca llega a la segunda. Y no hay ningun error.
BIEN:
si compra >= 500.000 -> descuento 10%
si compra >= 100.000 -> descuento 5%De mayor a menor. Es el mismo error que se ve en cualquier lenguaje de programacion, y aqui es igual de silencioso.
A veces no necesitas dos caminos, solo descartar lo que no sirve. Un nodo de filtro deja pasar lo que cumple la condición y detiene el resto.
Es lo que usas para «solo los que están en mora», «solo los pedidos de esta semana», «solo los registros que tienen correo».
Filtra lo antes posible. Si de 500 filas solo te interesan 8, filtra en el segundo nodo y no en el séptimo: todo lo que va después trabaja con 8 en vez de con 500. El flujo va más rápido y hay menos cosas que puedan fallar.
Ya lo viste en la lección anterior: un nodo se ejecuta una vez por cada elemento que recibe. Eso es una ventaja hasta que son quinientos.
Si quieres un correo con la lista de los 30 pendientes y no 30 correos, hay que agrupar los elementos antes del nodo de envío.
Con muchos registros, algunos servicios se quejan si les llegan cientos de peticiones seguidas. Se pueden procesar en grupos, con una pausa entre tandas.
Un flujo que manda un mensaje por fila, sobre una hoja que crece cada mes, un día manda seiscientos. Piensa siempre en qué pasa cuando los datos crezcan diez veces.
No basta con probar el caso que esperas. Prueba los tres:
Un dato que claramente entra por el «sí». Comprueba que va por donde debe.
Uno que debe irse por el «no». Es el que más se olvida probar.
Si la condición es «mayor o igual a 100.000», prueba exactamente con 100.000. Ahí es donde aparecen los errores de «mayor» contra «mayor o igual».
Tienes dos condiciones: primero "compra >= 100.000 → 5%" y después "compra >= 500.000 → 10%". Llega una compra de 800.000. ¿Qué descuento recibe?
Tu flujo tiene caminos para Bogotá y Medellín. Llega un pedido de Cali. ¿Qué pasa?
Siguiente: Cuando algo falla: errores, pruebas y registro
Continuar ← Los datos que viajan entre nodos