Colas de trabajo

Una cola de trabajo es una lista de tareas pendientes que viven en Nexus y que uno o varios bots procesan uno a uno. Es el patrón estándar de RPA para procesar lotes de trabajo de forma robusta, paralela y con reintentos: facturas por validar, pagos por conciliar, correos por clasificar.

La idea es separar quién produce el trabajo de quién lo ejecuta:

• Un proceso (o un sistema externo) encola items — cada item es una unidad de trabajo con sus datos.
• Uno o más bots toman items de la cola, los procesan y marcan el resultado.

¿Por qué usar una cola y no un bucle normal?

Si tienes 5 000 facturas que procesar, un bucle simple las haría una tras otra en un solo bot, y si falla a mitad, pierdes el avance. Con una cola: varios bots procesan en paralelo, cada item se procesa exactamente una vez (Nexus lo bloquea al entregarlo), los que fallan se reintentan solos, y tienes visibilidad de cuántos van, cuántos fallaron y por qué.

¿Cuándo usar una cola?

Una cola brilla cuando el trabajo se puede partir en muchas unidades independientes que se procesan igual. Tu proceso es buen candidato si reconoces varias de estas señales:

• Volumen alto — cientos o miles de elementos (facturas, pagos, registros, documentos).
• Items independientes — procesar uno no depende del resultado de otro.
• Se beneficia de ir en paralelo — quieres terminar antes repartiendo el trabajo entre varios bots.
• Cada item puede fallar por su cuenta — y quieres reintentar solo los que fallan, no rehacer todo el lote.
• Necesitas visibilidad o cumplir un SLA — saber cuántos van, cuántos fallaron y por qué.
• Se produce y se consume en momentos distintos — algo encola durante el día y los bots procesan por la noche.

Procesos ideales

Proceso	Por qué encaja bien
Validación / registro de facturas	Miles de facturas, cada una independiente y reintentable.
Conciliación de pagos o transacciones	Alto volumen, paralelizable entre varios bots.
Altas de empleados, clientes o proveedores (onboarding)	Cada alta es un item; si un sistema falla, se reintenta solo ese.
Procesamiento de documentos (OCR + captura)	Muchos documentos; cada uno una transacción con su resultado.
Envío masivo de correos, certificados o notificaciones	Un item por destinatario; reintenta solo los que rebotan.
Extracción de datos de muchos registros o portales	Un item por registro a consultar.
Sincronización de pedidos entre sistemas (ERP ↔ tienda)	Un item por pedido; tolera reintentos.

Cuándo no hace falta una cola

• Una tarea única y lineal (generar un reporte, hacer una descarga): un proceso normal basta.
• Muy pocos items y rápidos: el sobrecoste de coordinar la cola no compensa.
• Pasos que deben ejecutarse en orden estricto compartiendo estado (no son unidades independientes).
• Interacción en tiempo real con una persona.

Checklist de 5 segundos

Usa una cola si respondes sí a la mayoría: ¿hay muchos items? ¿son independientes? ¿quieres reintentar solo los fallidos? ¿te ayudaría ejecutar varios bots a la vez? ¿necesitas ver el avance? Si casi todo es “no”, un playbook con un bucle normal es más simple.

Cómo se relaciona con el resto

Una cola pertenece a un entorno (igual que los agentes o las credenciales). Los bots la leen y escriben con las actividades del paquete Queue. El ciclo completo:

flowchart LR
  P["Proceso productor<br/>(dispatcher)"] -->|Add Queue Item| Q[("Cola<br/>en Nexus")]
  Q -->|Get Queue Item| C["Proceso consumidor<br/>(performer)"]
  C -->|Set Transaction Status| Q

• El productor (o dispatcher) llena la cola con Add Queue Item.
• El consumidor (o performer) toma items con Get Queue Item, los procesa y reporta el resultado con Set Transaction Status.

Crear una cola

1. Entra al entorno y abre la pestaña Colas.
2. Haz clic en Nueva cola.
3. Completa el formulario:

Campo	Qué es
Nombre	El identificador de la cola dentro del entorno (es el queueName que usarás en las actividades).
Descripción	Texto libre para que el equipo sepa qué procesa.
Max reintentos	Cuántas veces se reintenta un item que falla antes de darlo por perdido. Por defecto 3.
Auto-retry al fallar	Si está activo, un item marcado como failed (reintentable) vuelve a la cola automáticamente hasta agotar los reintentos. Por defecto activado.
Aceptar items automáticamente	Si está activo, los items nuevos quedan listos para procesarse sin aprobación manual. Por defecto activado.

El nombre debe coincidir exactamente con el queueName que pongas en las actividades del playbook, y la cola debe existir en el mismo entorno donde se ejecuta.

La vista de la cola

Al abrir una cola ves sus items y su estado en tiempo real: puedes filtrar por estado, ver el detalle de cada item (su contenido, su salida o su error) y consultar métricas como items/hora y tiempo por item. También puedes Agregar item manualmente para pruebas.

El ciclo de vida de un item

Cada item de la cola recorre estos estados:

Estado	Significado
new	Encolado, esperando que un bot lo tome.
in_progress	Un bot lo tomó y lo está procesando (bloqueado para esa ejecución).
successful	Procesado con éxito.
failed	Procesado con error y sin más reintentos disponibles.
retried	Falló pero se reintentó (se generó un nuevo intento).
abandoned	Descartado tras agotar los reintentos o por intervención.
review	Marcado para revisión manual.

El bloqueo atómico es la clave: cuando un bot toma un item con Get Queue Item, Nexus lo pasa a in_progress y ningún otro bot puede tomarlo. Por eso varios bots pueden leer la misma cola a la vez sin pisarse.

Reintentos

Cuando un item se marca como failed, el comportamiento depende de la cola y del playbook:

• Si la cola tiene Auto-retry activo y aún quedan reintentos (Max reintentos), el item vuelve a la cola para otro intento. El contador Attempts del item lleva la cuenta.
• Si se agotan los reintentos, el item queda failed/abandoned definitivamente.
• El playbook puede forzar un fallo sin reintento (cuando el error no tiene sentido reintentar, como un dato inválido) pasando retryable = false en Set Transaction Status.

Errores de negocio vs. errores del sistema

Distingue dos tipos de error al procesar un item:

• Error del sistema (la web se cayó, timeout): tiene sentido reintentar → failed con retryable = true (el valor por defecto).
• Error de negocio (el RUT es inválido, falta un campo): reintentar daría el mismo error → failed con retryable = false, o márcalo para review.

El patrón productor / consumidor

La forma habitual de usar colas son dos procesos:

1. Dispatcher (productor): lee el origen (un Excel, una consulta SQL, una API) y encola un item por cada unidad de trabajo con Add Queue Item. Suele lanzarse con un trigger programado.
2. Performer (consumidor): en un bucle, toma items con Get Queue Item hasta que la cola se vacía, procesa cada uno y reporta el resultado. Puedes ejecutar varios performers en paralelo (varios agentes) para acelerar.

El ejemplo completo de ambos playbooks está en la introducción del paquete Queue.

Siguientes pasos

• Paquete Queue — las actividades para producir y consumir colas.
• Entornos — dónde viven las colas.
• Triggers programados — para lanzar el dispatcher periódicamente.