View a markdown version of this page

Come funziona la soluzione - Sala d'attesa virtuale su AWS

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Come funziona la soluzione

Questa sezione descrive le fasi di un flusso di lavoro di AWS Virtual Waiting Room ad alto livello. Consulta la Guida per gli sviluppatori GitHub per maggiori dettagli sulla creazione, la personalizzazione e l'integrazione di una sala d'attesa per il tuo sito web.

L'API pubblica della sala d'attesa può essere posizionata dietro la sicurezza perimetrale del sito oppure può essere disponibile senza alcuna autorizzazione. A seconda dell'approccio utilizzato per integrare la sala d'attesa con il sito Web, all'utente potrebbe essere richiesto di autenticarsi prima sul sito Web prima di poter accedere alla sala d'attesa e ottenere una posizione in coda.

Il software client deve disporre dell'Event ID per entrare nella sala d'attesa ed effettuare altre richieste. Un Event ID è un ID univoco richiesto per la maggior parte delle richieste rivolte al pubblico e al privato APIs. L'ID evento viene impostato durante l'installazione dello stack API principale. Durante il funzionamento, l'Event ID può essere fornito come parametro URL o cookie tramite la pagina della sala d'attesa; può essere fornito come parte delle richieste di token di autenticazione o può essere distribuito ai client attraverso un percorso dati diverso.

In alcuni casi il client necessita sia dell'ID evento che dell'ID richiesta per effettuare determinate chiamate API. Il Request ID è un ID univoco rilasciato dalla sala d'attesa che rappresenta uno specifico cliente in fila.

I passaggi seguenti descrivono il flusso di richieste API per l'ingresso in coda, l'attesa che la coda proceda e l'uscita dalla sala d'attesa con un token di accesso al sito Web.

L'utente entra nella sala d'attesa:

  1. All'utente viene presentata una schermata o una pagina che rappresenta il punto di ingresso della sala d'attesa. Scelgono di entrare in coda e il software client (browser, dispositivo mobile, dispositivo) chiama l'API assign_queue_num pubblica per richiedere una posizione in coda.

  2. La richiesta API viene immediatamente consegnata alla coda Amazon SQS tramite API Gateway.

  3. La chiamata assign_queue_num API ritorna quando la richiesta viene inserita nella coda. Il client riceve un ID di richiesta univoco che può essere utilizzato in seguito per recuperare la posizione della coda, l'ora della richiesta e un token di accesso.

  4. La funzione AssignQueueNum Lambda riceve batch composti da un massimo di dieci richieste dalla coda SQS. Il servizio Lambda suddivide le chiamate per elaborare più batch di richieste.

  5. La funzione AssignQueueNum Lambda convalida ogni messaggio nel relativo batch, incrementa il contatore di coda in Elasticache (Redis OSS) e archivia ogni richiesta in Elasticache (Redis OSS) con la posizione di coda associata.

  6. Ogni messaggio viene eliminato man mano che viene elaborato correttamente. I messaggi relativi a una condizione di errore vengono rielaborati una volta in un batch successivo. Dopo un secondo errore, vengono inviati a un dead-letter-queue dispositivo collegato a un CloudWatchallarme.

  7. Il client può iniziare a eseguire il polling dell'queue_numAPI dopo aver ricevuto l'ID della richiesta dalla assign_queue_num chiamata. Il client invia l'ID evento e l'ID richiesta all'queue_numAPI e riceve una posizione numerica in coda o una risposta che indica che la richiesta non è stata ancora elaborata. Il client potrebbe dover effettuare questa chiamata più di una volta durante eventi di grandi dimensioni. La funzione GetQueueNum Lambda viene richiamata da API Gateway e restituisce la posizione numerica del client nella coda da DynamoDB.

L'utente attende nella sala d'attesa:

  1. Dopo che il client ha raggiunto la sua posizione in coda, può iniziare a eseguire il polling dell'serving_numAPI a intervalli regolari. L'serving_numAPI viene chiamata con l'ID evento e restituisce la posizione di servizio corrente della coda. La risposta dell'serving_numAPI indica al cliente quando può spostarsi dalla sala d'attesa al sito di destinazione effettivo dove può avvenire la transazione finale. La funzione GetServingNum Lambda restituisce l'attuale posizione di servizio della sala d'attesa.

  2. Quando la posizione di servizio è uguale o superiore alla posizione di coda (richiesta) del client, il client può richiedere un JSON Web Token (JWT) dall'API pubblica. Il token può essere utilizzato con il sito di destinazione per finalizzare la transazione. L'generate_tokenAPI viene chiamata con l'ID evento e l'ID della richiesta. API Gateway richiama la funzione GenerateToken Lambda con i parametri.

  3. La funzione GenerateToken Lambda convalida la richiesta e verifica se questo token è stato generato in precedenza. La funzione Lambda interroga la tabella DynamoDB per un token corrispondente. Se trovato, quel token viene restituito al chiamante e non viene rigenerato. Questo processo impedisce l'utilizzo di un singolo ID di richiesta per generare più token diversi con nuovi tempi di scadenza.

  4. Se il token non viene trovato in DynamoDB, la funzione Lambda recupera le chiavi per creare il token e salva il token in DynamoDB con l'ID evento e l'ID di richiesta del client. La funzione Lambda scrive un evento su per EventBridge segnalare che è stato generato un nuovo token. La funzione Lambda incrementa un contatore Elasticache (Redis OSS) che tiene traccia del numero di token generati per l'evento.

  5. Se queue_pos_expiry è attivata, il client può interrogare il tempo rimanente prima della scadenza chiamando l'queue_pos_expiryAPI che richiama la funzione GetQueuePositionExpiryTime Lambda.

L'utente esce dalla sala d'attesa:

  1. Quando il client riceve il token, entra nel sito di destinazione per iniziare la transazione. A seconda del modo in cui l'infrastruttura supporta l'integrazione con JWT, il client potrebbe dover presentare il token in un'intestazione di richiesta, un cookie o in un altro modo. L'autorizzatore per API Gateway può essere utilizzato per convalidare il token incluso nella richiesta di un client. Qualsiasi libreria commerciale o open source per la convalida e la gestione JWTs può essere utilizzata con Virtual Waiting Room sui token. AWS Se il token è valido, il cliente può continuare la transazione.

  2. Dopo che il cliente ha completato la transazione, viene chiamata un'API privata per aggiornare lo stato del token del client e viene completata in DynamoDB.

Scadenza della posizione in coda:

  1. Quando questa funzione è attivata, l'ID di richiesta corrispondente a una particolare posizione in coda è idoneo a generare un token solo per un intervallo di tempo specificato.

Incrementa il contatore di servitù alla scadenza della posizione di coda:

  1. Quando questa funzione è attivata, il contatore di servizio viene automaticamente incrementato in base alle posizioni di coda scadute che non sono state in grado di generare token.