Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Cómo funciona la solución En esta sección se describen los pasos del flujo de trabajo de una sala de espera AWS virtual a un alto nivel. Consulte la [Guía para desarrolladores GitHub](https://github.com/aws-solutions/aws-virtual-waiting-room/blob/main/docs/developer-guide.md) para obtener más información sobre cómo crear, personalizar e integrar una sala de espera para su sitio web. La API pública de la sala de espera puede estar ubicada detrás del perímetro de seguridad del sitio o puede estar disponible sin autorización alguna. Según el enfoque que utilices para integrar la sala de espera con el sitio web, es posible que el usuario deba autenticarse primero en el sitio web antes de poder acceder a la sala de espera y obtener un puesto en la cola. El software cliente debe tener el identificador del evento para entrar en la sala de espera y realizar otras solicitudes. El identificador de evento es un identificador único que se requiere para la mayoría de las solicitudes tanto públicas como privadas APIs. El ID de evento se establece durante la instalación de la pila de API principal. Durante el funcionamiento, el ID del evento se puede proporcionar como parámetro de URL o cookie a través de la página de la sala de espera; se puede proporcionar como parte de las solicitudes de autenticación o se puede distribuir a los clientes a través de una ruta de datos diferente. Hay casos en los que el cliente necesita tanto el ID del evento como el ID de la solicitud para realizar determinadas llamadas a la API. El ID de solicitud es un identificador único emitido desde la sala de espera que representa a un cliente específico en la fila. En los siguientes pasos se describe el flujo de solicitudes de la API para entrar en una cola, esperar a que la cola avance y salir de la sala de espera con un token de acceso al sitio web. **El usuario entra en la sala de espera:** 1. Al usuario se le presenta una pantalla o página que representa el punto de entrada a la sala de espera. Eligen entrar en la cola y el software del cliente (navegador, móvil, dispositivo) llama a la API `assign_queue_num` pública para solicitar una posición en la cola. 1. API Gateway envía inmediatamente la solicitud de API a la cola de Amazon SQS. 1. La llamada a la `assign_queue_num` API se devuelve cuando la solicitud se coloca en la cola. El cliente recibe un identificador de solicitud único que se puede utilizar más adelante para recuperar la posición de la cola, la hora de la solicitud y un token de acceso. 1. La función `AssignQueueNum` Lambda recibe lotes de hasta diez solicitudes de la cola de SQS. El servicio Lambda distribuye las invocaciones para procesar varios lotes de solicitudes. 1. La función `AssignQueueNum` Lambda valida cada mensaje de su lote, incrementa el contador de colas en Elasticache (Redis OSS) y almacena cada solicitud en ElastiCache (Redis OSS) con su posición de cola asociada. 1. Cada mensaje se elimina a medida que se procesa correctamente. Los mensajes que presentan una condición de error se vuelven a procesar una vez en un lote posterior. Tras un segundo error, se envían a una [CloudWatchalarma dead-letter-queue](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) conectada. 1. El cliente puede empezar a sondear la `queue_num` API después de recibir el ID de solicitud de la `assign_queue_num` llamada. El cliente envía el ID de evento y el ID de solicitud a la `queue_num` API y recibe una posición numérica en la cola o una respuesta que indica que la solicitud aún no se ha procesado. Es posible que el cliente necesite realizar esta llamada más de una vez durante eventos grandes. API Gateway invoca la función `GetQueueNum` Lambda y devuelve la posición numérica del cliente en la cola desde DynamoDB. **El usuario espera en la sala de espera:** 1. Una vez que el cliente ocupe su posición en la cola, puede empezar a sondear la `serving_num` API a intervalos regulares. Se llama a la `serving_num` API con el ID del evento y devuelve la posición de servicio actual de la cola. La respuesta de la `serving_num` API indica al cliente cuándo puede pasar de la sala de espera al sitio de destino real, donde se puede realizar la transacción final. La función `GetServingNum` Lambda devuelve la posición de servicio actual de la sala de espera. 1. Cuando la posición de servicio es igual o superior a la posición en la cola (solicitud) del cliente, el cliente puede solicitar un token web JSON (JWT) desde la API pública. El token se puede usar con el sitio de destino para finalizar la transacción. Se llama a la `generate_token` API con el ID de evento y el ID de solicitud. API Gateway invoca la función `GenerateToken` Lambda con los parámetros. 1. La función `GenerateToken` Lambda valida la solicitud y comprueba si este token se ha generado previamente. La función Lambda consulta la tabla de DynamoDB en busca de un token coincidente. Si se encuentra, ese token se devuelve a la persona que llama y no se regenera. Este proceso evita que se utilice un único identificador de solicitud para generar varios tokens diferentes con nuevos tiempos de caducidad. 1. Si el token no se encuentra en DynamoDB, la función Lambda recupera las claves para crear el token y lo guarda en DynamoDB con el ID de evento y el ID de solicitud del cliente. La función Lambda escribe un evento EventBridge para indicar que se ha generado un nuevo token. La función Lambda incrementa un contador de Elasticache (Redis OSS) que realiza un seguimiento del número de tokens generados para el evento. 1. Si `queue_pos_expiry` está activada, el cliente puede consultar el tiempo restante antes de que caduque llamando a la `queue_pos_expiry` API que invoca la función Lambda`GetQueuePositionExpiryTime`. **El usuario sale de la sala de espera:** 1. Cuando el cliente recibe su token, entra en el sitio de destino para comenzar su transacción. En función de cómo su infraestructura soporte la integración con JWT, es posible que el cliente deba presentar el token en un encabezado de solicitud, en una cookie o de otra forma. El autorizador de API Gateway se puede utilizar para validar el token incluido en la solicitud de un cliente. JWTs Se puede usar cualquier biblioteca comercial o de código abierto para validar y administrar con Virtual Waiting Room en los tokens. AWS Si el token es válido, el cliente puede continuar con la transacción. 1. Una vez que el cliente completa la transacción, se llama a una API privada para actualizar el estado del token del cliente y se completa en DynamoDB. **Caducidad de las posiciones de cola:** 1. Cuando esta función está activada, el ID de solicitud correspondiente a una posición de cola concreta solo puede generar un token durante un intervalo de tiempo específico. **Aumente el contador de servicio al expirar la posición de la cola:** 1. Cuando se activa esta función, el contador de servicio se incrementa automáticamente en función de las posiciones de cola caducadas que no pudieron generar fichas.