View a markdown version of this page

Fonctionnement de la solution - Salle d'attente virtuelle sur AWS

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Fonctionnement de la solution

Cette section décrit les étapes d'un flux de travail de salle d'attente AWS virtuelle de haut niveau. Consultez le guide du développeur GitHub pour plus de détails sur la création, la personnalisation et l'intégration d'une salle d'attente pour votre site Web.

L'API publique de la salle d'attente peut être située derrière le périmètre de sécurité de votre site ou elle peut être disponible sans aucune autorisation. Selon l'approche que vous utilisez pour intégrer la salle d'attente au site Web, l'utilisateur devra peut-être d'abord s'authentifier sur le site Web avant d'être autorisé à accéder à la salle d'attente et à obtenir une position dans la file d'attente.

Le logiciel client doit disposer de l'ID d'événement pour entrer dans la salle d'attente et faire d'autres demandes. Un identifiant d'événement est un identifiant unique requis pour la plupart des demandes adressées au public ou au privé APIs. L'ID d'événement est défini lors de l'installation de la pile d'API principale. Pendant le fonctionnement, l'identifiant de l'événement peut être fourni sous forme de paramètre d'URL ou de cookie via la page de la salle d'attente ; il peut être fourni dans le cadre de demandes de jetons d'authentification ou il peut être distribué aux clients via un chemin de données différent.

Dans certains cas, le client a besoin à la fois de l'ID d'événement et de l'ID de demande pour effectuer certains appels d'API. L'ID de demande est un identifiant unique émis par la salle d'attente et représentant un client spécifique dans la file d'attente.

Les étapes suivantes décrivent le flux des demandes d'API pour entrer dans la file d'attente, attendre que la file progresse et quitter la salle d'attente avec un jeton d'accès au site Web.

L'utilisateur entre dans la salle d'attente :

  1. L'utilisateur voit apparaître un écran ou une page représentant le point d'entrée de la salle d'attente. Ils choisissent d'entrer dans la file d'attente et le logiciel client (navigateur, mobile, appareil) appelle l'API assign_queue_num publique pour demander une position dans la file d'attente.

  2. La demande d'API est immédiatement envoyée à la file d'attente Amazon SQS par API Gateway.

  3. L'appel assign_queue_num d'API revient lorsque la demande est placée dans la file d'attente. Le client reçoit un identifiant de demande unique qui peut être utilisé ultérieurement pour récupérer la position de la file d'attente, l'heure de la demande et un jeton d'accès.

  4. La fonction AssignQueueNum Lambda reçoit des lots contenant jusqu'à dix requêtes depuis la file d'attente SQS. Le service Lambda répartit les invocations pour traiter plusieurs lots de demandes.

  5. La fonction AssignQueueNum Lambda valide chaque message de son lot, incrémente le compteur de files d'attente dans Elasticache (Redis OSS) et stocke chaque demande dans Elasticache (Redis OSS) avec sa position de file d'attente associée.

  6. Chaque message est supprimé au fur et à mesure de son traitement. Les messages concernés par une condition d'erreur sont retraités une fois dans un lot ultérieur. Après une deuxième panne, ils sont envoyés à un système dead-letter-queue connecté à une CloudWatchalarme.

  7. Le client peut commencer à interroger l'queue_numAPI après avoir reçu l'ID de demande de l'assign_queue_numappel. Le client envoie l'ID d'événement et l'ID de demande à l'queue_numAPI et reçoit une position numérique dans la file d'attente ou une réponse indiquant que la demande n'a pas encore été traitée. Le client peut avoir besoin de passer cet appel plusieurs fois lors d'événements importants. La fonction GetQueueNum Lambda est invoquée par API Gateway et renvoie la position numérique du client dans la file d'attente depuis DynamoDB.

L'utilisateur attend dans la salle d'attente :

  1. Une fois que le client a trouvé sa position dans la file d'attente, il peut commencer à serving_num interroger l'API à intervalles réguliers. L'serving_numAPI est appelée avec l'ID d'événement et renvoie la position de service actuelle de la file d'attente. La réponse de l'serving_numAPI indique au client quand il peut passer de la salle d'attente au site cible où la transaction finale peut avoir lieu. La fonction GetServingNum Lambda renvoie la position de service actuelle de la salle d'attente.

  2. Lorsque la position de service est égale ou supérieure à la position de la file d'attente (demande) du client, celui-ci peut demander un jeton Web JSON (JWT) à l'API publique. Le jeton peut être utilisé avec le site cible pour finaliser la transaction. L'generate_tokenAPI est appelée avec l'ID d'événement et l'ID de demande. API Gateway appelle la fonction GenerateToken Lambda avec les paramètres.

  3. La fonction GenerateToken Lambda valide la demande et vérifie si ce jeton a déjà été généré. La fonction Lambda interroge la table DynamoDB pour trouver un jeton correspondant. S'il est trouvé, ce jeton est renvoyé à l'appelant et il n'est pas régénéré. Ce processus empêche l'utilisation d'un seul ID de demande pour générer plusieurs jetons différents avec de nouvelles dates d'expiration.

  4. Si le jeton n'est pas trouvé dans DynamoDB, la fonction Lambda récupère les clés pour créer le jeton et enregistre le jeton dans DynamoDB avec l'ID d'événement et l'ID de demande du client. La fonction Lambda écrit un événement dans pour EventBridge signaler qu'un nouveau jeton a été généré. La fonction Lambda incrémente un compteur Elasticache (Redis OSS) qui assure le suivi du nombre de jetons générés pour l'événement.

  5. S'il queue_pos_expiry est activé, le client peut demander le temps restant avant son expiration en appelant l'queue_pos_expiryAPI qui invoque la fonction GetQueuePositionExpiryTime Lambda.

L'utilisateur quitte la salle d'attente :

  1. Lorsque le client reçoit son jeton, il entre sur le site cible pour commencer sa transaction. Selon la manière dont votre infrastructure prend en charge une intégration avec JWT, le client devra peut-être présenter le jeton dans un en-tête de demande, un cookie ou d'une autre manière. L'autorisateur d'API Gateway peut être utilisé pour valider le jeton inclus dans la demande d'un client. Toutes les bibliothèques commerciales ou open source destinées à la validation et à la gestion JWTs peuvent être utilisées avec Virtual Waiting Room on AWS tokens. Si le jeton est valide, le client est autorisé à poursuivre sa transaction.

  2. Une fois que le client a terminé sa transaction, une API privée est appelée pour mettre à jour le statut du jeton du client et est terminée dans DynamoDB.

Expiration de la position dans la file

  1. Lorsque cette fonctionnalité est activée, l'ID de demande correspondant à une position de file d'attente particulière est éligible pour générer un jeton uniquement pendant un intervalle de temps spécifié.

Augmentez le compteur de service à l'expiration de la position de la file d'attente :

  1. Lorsque cette fonctionnalité est activée, le compteur de service est automatiquement incrémenté en fonction des positions de file d'attente expirées qui n'ont pas pu générer de jetons.