Worker

El Container Killer Worker es un servicio automatizado que se encarga de eliminar contenedores vacíos del sistema de inventario. Su objetivo principal es mantener limpio el inventario, eliminando contenedores que ya no contienen productos y que no están en ubicaciones de recepción.

Proceso Eliminación de Contenedores Vacíos

Este proceso identifica y elimina contenedores que han quedado sin productos (stock cero) después de transacciones de salida en el inventario.

Input/Output del Mensaje

Estructura de Entrada:

interface OutputTransactionEvent {
  type: 'OutputTransaction';
  data: Array<{
    containerName?: string; // Identificador del contenedor (LPN)
    stock: number;          // Nivel de stock actual
  }>;
  context: {
    country: string;        // Código de país
    warehouse: string;      // Identificador del almacén
  };
}

Estructura de Salida:

interface Container {
  name: string;           // Nombre del contenedor
  location: {
    type: string;         // Tipo de ubicación (ej. "Receipt", "Storage")
    // Otros detalles de ubicación
  };
  // Otros atributos del contenedor
}

Flujo de Procesamiento

1. Recepción de Mensajes:

   • El worker consulta la cola SQS para obtener hasta 10 mensajes.
   • Cada mensaje contiene información sobre transacciones de salida de inventario.

2. Validación del Mensaje:

   • Se valida que el mensaje cumpla con el esquema esperado utilizando Zod.
   • Se verifica que el mensaje sea de tipo ‘OutputTransaction’.
   • Se validan los campos obligatorios y sus formatos (ej. formato del nombre del contenedor).

3. Filtrado de Contenedores:

   • Se filtran los contenedores que tienen stock cero.
   • Se descartan los contenedores nulos o indefinidos.
   • Se eliminan duplicados mediante un Set.

4. Procesamiento de Cada Contenedor:

   • Para cada contenedor filtrado: a. Se obtiene la información del contenedor desde el servicio de contenedores. b. Se consulta el número de productos en el contenedor desde el servicio de inventario. c. Se verifica que el contenedor realmente no tenga productos. d. Se verifica que el contenedor no esté en una ubicación de tipo “Receipt”. e. Si se cumplen todas las condiciones, se elimina el contenedor.

5. Manejo de Resultados:

   • Se registran los resultados del procesamiento (éxito o error).
   • Se eliminan los mensajes procesados correctamente de la cola SQS.
   • Se mantienen en la cola los mensajes que no se pudieron procesar debido a errores inesperados.

Adaptadores y Puertos Involucrados

Puertos (Interfaces):

• QueueService: Para interactuar con la cola de mensajes.
• ContainerService: Para obtener información y eliminar contenedores.
• InventoryService: Para verificar el número de productos en un contenedor.

Adaptadores (Implementaciones):

• AwsQueueService: Implementación de QueueService utilizando AWS SQS.
• HttpContainerService: Implementación de ContainerService utilizando HTTP.
• HttpInventoryService: Implementación de InventoryService utilizando HTTP.

Reglas de Negocio Aplicadas

1. Regla de Contenedor Vacío: Solo se eliminan contenedores que no tienen productos (stock cero).
2. Regla de Ubicación: No se eliminan contenedores que están en ubicaciones de tipo “Receipt”.
3. Regla de Validación: Los nombres de los contenedores deben seguir el formato XX-LPN-XXXXXXXX (ej. MX-LPN-12345678).

Errores y Excepciones Posibles

1. ValidationError: Error de validación del formato del mensaje.
2. UnprocessableEventMessage: El mensaje no puede ser procesado (ej. no hay contenedores válidos, el contenedor tiene productos, el contenedor está en una ubicación de Receipt).
3. ContainerNotFoundError: No se encuentra el contenedor especificado.
4. ContainerServiceError: Error al interactuar con el servicio de contenedores.
5. InventoryServiceError: Error al interactuar con el servicio de inventario.
6. GettingQueueMessageError: Error al recibir mensajes de la cola.
7. DeleteQueueMessageError: Error al eliminar mensajes de la cola.
8. UnexpectedError: Errores inesperados durante el procesamiento.

Manejo de Errores

El worker implementa un sofisticado sistema de manejo de errores utilizando el patrón Either:

• Los errores de validación, mensajes no procesables y contenedores no encontrados se registran como advertencias y se eliminan de la cola.
• Los errores inesperados y errores de servicio se registran como errores y los mensajes permanecen en la cola para reintentos posteriores.
• Se utiliza el patrón Either para manejar los flujos de éxito y error de manera funcional, evitando el uso excesivo de bloques try-catch.