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à.
# Utilizzo di Lambda con Amazon SQS
**Nota**
[Se desideri inviare dati a una destinazione diversa da una funzione Lambda o arricchire i dati prima di inviarli, consulta Amazon Pipes. EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes.html)
È possibile utilizzare una funzione Lambda per elaborare i messaggi in una coda Amazon Simple Queue Service (Amazon SQS). Lambda supporta sia [code standard](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues.html) che [code first-in, first-out (FIFO)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html) per gli [strumenti di mappatura dell'origine degli eventi](invocation-eventsourcemapping.md). Puoi anche utilizzare la modalità provisioned per allocare risorse di polling dedicate per le mappature delle sorgenti degli eventi Amazon SQS. [La funzione Lambda e la coda Amazon SQS devono trovarsi nella Regione AWS stessa posizione, anche se possono trovarsi in posizioni diverse. Account AWS](with-sqs-cross-account-example.md)
Durante l'elaborazione di messaggi Amazon SQS, è necessario implementare una logica di risposta batch parziale per evitare che i messaggi elaborati correttamente vengano ritentati quando alcuni messaggi di un batch falliscono. L'[utilità Batch Processor](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) di Powertools AWS Lambda semplifica questa implementazione gestendo automaticamente la logica di risposta batch parziale, riducendo i tempi di sviluppo e migliorando l'affidabilità.
**Topics**
+ [
## Informazioni sul comportamento di polling e batch per gli strumenti di mappatura dell'origine degli eventi di Amazon SQS
](#sqs-polling-behavior)
+ [
## Utilizzo della modalità provisioning con le mappature delle sorgenti degli eventi di Amazon SQS
](#sqs-provisioned-mode)
+ [
## Configurazione della modalità di provisioning per la mappatura delle sorgenti degli eventi Amazon SQS
](#sqs-configuring-provisioned-mode)
+ [
## Esempio di evento con messaggio di coda standard
](#example-standard-queue-message-event)
+ [
## Esempio di evento di messaggio di coda FIFO
](#sample-fifo-queues-message-event)
+ [
# Creazione e configurazione di uno strumento di mappatura dell'origine degli eventi Amazon SQS
](services-sqs-configure.md)
+ [
# Configurazione del comportamento di dimensionamento per gli strumenti di mappatura dell'origine degli eventi
](services-sqs-scaling.md)
+ [
# Gestione degli errori per un'origine eventi SQS in Lambda
](services-sqs-errorhandling.md)
+ [
# Parametri Lambda per gli strumenti di mappatura dell'origine degli eventi di Amazon SQS
](services-sqs-parameters.md)
+ [
# Utilizzo del filtro eventi con un'origine eventi Amazon SQS
](with-sqs-filtering.md)
+ [
# Tutorial: Utilizzo di Lambda con Amazon SQS
](with-sqs-example.md)
+ [
# Tutorial: utilizzo di una coda Amazon SQS tra più account come origine eventi
](with-sqs-cross-account-example.md)
## Informazioni sul comportamento di polling e batch per gli strumenti di mappatura dell'origine degli eventi di Amazon SQS
Con gli strumenti di mappatura dell'origine degli eventi di Amazon SQS, Lambda esegue il polling della coda e richiama la funzione [in modo sincrono](invocation-sync.md) con un evento. Ogni evento può contenere un batch di più messaggi dalla coda. Lambda riceve questi eventi un batch alla volta e richiama la funzione una volta per ogni batch. Quando la funzione elabora correttamente un batch, Lambda elimina i relativi messaggi dalla coda.
Quando Lambda legge un batch, i messaggi rimangono nella coda ma vengono nascosti per la durata del [timeout visibilità](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) della coda. Se la funzione elabora correttamente tutti i messaggi nel batch, Lambda elimina i messaggi dalla coda. Per impostazione predefinita, se la funzione rileva un errore durante l'elaborazione di un batch, una volta scaduto il timeout di visibilità tutti i messaggi in quel batch diventeranno nuovamente visibili nella coda. Per questo motivo, il codice della funzione deve riuscire a elaborare lo stesso messaggio più volte, senza intoppi indesiderati.
**avvertimento**
Gli strumenti di mappatura dell'origine degli eventi elaborano ogni evento almeno una volta e può verificarsi un'elaborazione duplicata dei record. Per evitare potenziali problemi legati agli eventi duplicati, ti consigliamo vivamente di rendere idempotente il codice della funzione. Per ulteriori informazioni, consulta [Come posso rendere idempotente la mia funzione Lambda](https://repost.aws/knowledge-center/lambda-function-idempotent) nel Knowledge Center. AWS
Per impedire a Lambda di elaborare un messaggio più volte, puoi configurare la mappatura dell'origine degli eventi per includere gli [errori degli elementi in batch](services-sqs-errorhandling.md#services-sqs-batchfailurereporting) nella risposta della funzione oppure puoi utilizzare l'[DeleteMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteMessage.html)API per rimuovere i messaggi dalla coda man mano che la funzione Lambda li elabora correttamente.
Per ulteriori informazioni sui parametri di configurazione supportati da Lambda per gli strumenti di mappatura dell'origine degli eventi di SQS, consulta [Creazione di uno strumento di mappatura dell'origine degli eventi SQS](services-sqs-configure.md#events-sqs-eventsource).
## Utilizzo della modalità provisioning con le mappature delle sorgenti degli eventi di Amazon SQS
Per i carichi di lavoro in cui è necessario ottimizzare il throughput dello strumento di mappatura dell'origine degli eventi, è possibile utilizzare la modalità provisioning. In modalità provisioning, vengono definiti i limiti minimi e massimi per la quantità di poller di eventi assegnati. Questi poller di eventi con provisioning sono dedicati allo strumento di mappatura dell'origine degli eventi e possono gestire picchi di messaggi imprevisti tramite un dimensionamento automatico reattivo. La mappatura delle sorgenti di eventi di Amazon SQS configurata con la modalità Provisioned è 3 volte più veloce (fino a 1.000 richiami simultanei al minuto) e supporta una contemporaneità 16 volte superiore (fino a 20.000 richiami simultanei) rispetto alla funzionalità di mappatura delle sorgenti di eventi di Amazon SQS predefinita. Ti consigliamo di utilizzare la modalità provisioned per i carichi di lavoro basati su eventi di Amazon SQS che hanno requisiti prestazionali rigorosi, come le società di servizi finanziari che elaborano i feed di dati di mercato, le piattaforme di e-commerce che forniscono consigli personalizzati in tempo reale e le società di gioco che gestiscono le interazioni tra giocatori dal vivo. L'utilizzo della modalità provisioning comporta costi aggiuntivi. [Per i prezzi dettagliati, consulta la pagina dei prezzi.AWS Lambda](https://aws.amazon.com/lambda/pricing/)
Ogni event poller in modalità provisioned può gestire fino all'1% MB/s del throughput, fino a 10 chiamate simultanee o fino a 10 chiamate API di polling di Amazon SQS al secondo. L'intervallo di valori accettati per il numero minimo di event poller (MinimumPollers) è compreso tra 2 e 200, con il valore predefinito di 2. L'intervallo di valori accettati per il numero massimo di event poller (MaximumPollers) è compreso tra 2 e 2.000, con il valore predefinito di 200. MaximumPollers deve essere maggiore o uguale a. MinimumPollers
### Determinazione dei sondaggi di eventi richiesti
Per stimare il numero di event poller necessari per garantire prestazioni ottimali di elaborazione dei messaggi quando si utilizza la modalità provisioned per SQS ESM, raccogli le seguenti metriche per la tua applicazione: eventi SQS di picco al secondo che richiedono un'elaborazione a bassa latenza, dimensione media del payload degli eventi SQS, durata media della funzione Lambda e dimensione del batch configurato.
Innanzitutto puoi stimare il numero di eventi SQS al secondo (EPS) supportati da un event poller per il tuo carico di lavoro utilizzando la seguente formula:
```
EPS per event poller =
minimum(
ceiling(1024 / average event size in KB),
ceiling(10 / average function duration in seconds) * batch size,
min(100, 10 * batch size)
)
```
Quindi, puoi calcolare il numero minimo di poller richiesti utilizzando la formula seguente. Questo calcolo garantisce la disponibilità di una capacità sufficiente per gestire i requisiti di traffico di picco.
```
Required event pollers = (Peak number of events per second in Queue) / EPS per event poller
```
Prendiamo in considerazione un carico di lavoro con una dimensione del batch predefinita di 10, una dimensione media degli eventi di 3 KB, una durata media della funzione di 100 ms e un requisito per gestire 1.000 eventi al secondo. In questo scenario, ogni event poller supporterà circa 100 eventi al secondo (EPS). Pertanto, è necessario impostare un numero minimo di poller su 10 per gestire adeguatamente i requisiti di traffico di picco. Se il carico di lavoro ha le stesse caratteristiche ma la durata media della funzione è di 1 secondo, ogni poller supporterà solo 10 EPS, il che richiede la configurazione di almeno 100 poller per supportare 1.000 eventi al secondo a bassa latenza.
Ti consigliamo di utilizzare una dimensione batch predefinita pari o superiore a 10 per massimizzare l'efficienza dei poller di eventi in modalità provisioned. Le dimensioni dei batch più elevate consentono a ciascun poller di elaborare più eventi per chiamata, migliorando la produttività e l'efficienza in termini di costi. Quando pianificate la capacità dei poller del vostro evento, tenete conto dei potenziali picchi di traffico e valutate la possibilità di impostare il valore MinimumPollers leggermente più alto del minimo calcolato per fornire un buffer. Inoltre, monitora le caratteristiche del carico di lavoro nel tempo, poiché le modifiche alla dimensione dei messaggi, alla durata delle funzioni o ai modelli di traffico potrebbero richiedere modifiche alla configurazione del poller degli eventi per mantenere prestazioni ed efficienza dei costi ottimali. Per una pianificazione precisa della capacità, consigliamo di testare il carico di lavoro specifico per determinare l'EPS effettivo che ogni event poller può generare.
## Configurazione della modalità di provisioning per la mappatura delle sorgenti degli eventi Amazon SQS
Puoi configurare la modalità di provisioning per la mappatura delle sorgenti degli eventi Amazon SQS utilizzando la console o l'API Lambda.
**Per configurare la modalità di provisioning per una mappatura delle sorgenti di eventi Amazon SQS esistente (console)**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegli la funzione con la mappatura delle sorgenti degli eventi di Amazon SQS per cui desideri configurare la modalità di provisioning.
1. Scegli la scheda **Configurazione**, quindi scegli **Trigger**.
1. **Scegli la mappatura delle sorgenti degli eventi Amazon SQS per cui desideri configurare la modalità di provisioning, quindi scegli Modifica.**
1. In **Configurazione dello strumento di mappatura dell'origine degli eventi**, scegli **Configura la modalità provisioning**.
+ Per **Minimum event poller**, inserisci un valore compreso tra 2 e 200. Se non si specifica un valore, Lambda sceglie un valore predefinito pari a 2.
+ Per **Maximum event poller**, inserisci un valore compreso tra 2 e 2.000. Questo valore deve essere maggiore o uguale al valore specificato in **Numero minimo di poller di eventi**. Se non si specifica un valore, Lambda assegna il valore predefinito 200.
1. Scegli **Save** (Salva).
È possibile configurare la modalità di provisioning a livello di codice utilizzando l'`ProvisionedPollerConfig`oggetto in. `EventSourceMappingConfiguration` Ad esempio, il seguente comando `UpdateEventSourceMapping` CLI configura un `MinimumPollers` valore di 5 e un `MaximumPollers` valore di 100.
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'
```
Dopo aver configurato la modalità provisioning, puoi osservare l'utilizzo dei poller di eventi per il tuo carico di lavoro monitorando il parametro `ProvisionedPollers`. Per ulteriori informazioni, consulta Metriche di mappatura della fonte degli eventi.
Per disabilitare la modalità provisioning e tornare alla modalità predefinita (su richiesta), puoi utilizzare il seguente comando CLI`UpdateEventSourceMapping`:
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{}'
```
**Nota**
La modalità provisioned non può essere utilizzata insieme all'impostazione della massima concorrenza. Quando si utilizza la modalità provisioned, è possibile controllare la massima concorrenza mediante il numero massimo di sondaggi di eventi.
Per ulteriori informazioni sulla configurazione della modalità provisioned, vedere. [Creazione e configurazione di uno strumento di mappatura dell'origine degli eventi Amazon SQS](services-sqs-configure.md)
## Esempio di evento con messaggio di coda standard
**Example Evento messaggio Amazon SQS (coda standard)**
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {
"myAttribute": {
"stringValue": "myValue",
"stringListValues": [],
"binaryListValues": [],
"dataType": "String"
}
},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
"awsRegion": "us-east-2"
},
{
"messageId": "2e1424d4-f796-459a-8184-9c92662be6da",
"receiptHandle": "AQEBzWwaftRI0KuVm4tP+/7q1rGgNqicHq...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082650636",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082650649"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
"awsRegion": "us-east-2"
}
]
}
```
Per impostazione predefinita, Lambda eseguirà il polling di un massimo di 10 messaggi contemporaneamente nella coda e invierà il batch alla funzione. Per evitare di richiamare la funzione con un piccolo numero di record, è possibile configurare l'origine eventi per memorizzare nel buffer i record per un massimo di 5 minuti definendo un periodo di batch. Prima di richiamare la funzione, Lambda continua a eseguire il polling dei messaggi dalla coda standard fino alla scadenza del periodo di batch, al raggiungimento della [quota della dimensione del payload di richiesta](gettingstarted-limits.md) o al raggiungimento della dimensione massima per la configurazione di un batch.
Se stai utilizzando un periodo di batch e la tua coda SQS contiene un traffico molto basso, Lambda potrebbe attendere fino a 20 secondi prima di richiamare la tua funzione. Lo stesso vale anche se imposti un periodo di batch inferiore a 20 secondi.
**Nota**
In Java, potresti riscontrare errori di puntatore null durante la deserializzazione di JSON. Ciò potrebbe essere dovuto al modo in cui "Records" e "eventSourceARN" vengono convertiti dal mappatore di oggetti JSON.
## Esempio di evento di messaggio di coda FIFO
Per le code FIFO, i record contengono attributi aggiuntivi correlati alla deduplicazione e al sequenziamento.
**Example Evento messaggio Amazon SQS (coda FIFO)**
```
{
"Records": [
{
"messageId": "11d6ee51-4cc7-4302-9e22-7cd8afdaadf5",
"receiptHandle": "AQEBBX8nesZEXmkhsmZeyIE8iQAMig7qw...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1573251510774",
"SequenceNumber": "18849496460467696128",
"MessageGroupId": "1",
"SenderId": "AIDAIO23YVJENQZJOL4VO",
"MessageDeduplicationId": "1",
"ApproximateFirstReceiveTimestamp": "1573251510774"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:fifo.fifo",
"awsRegion": "us-east-2"
}
]
}
```
# Creazione e configurazione di uno strumento di mappatura dell'origine degli eventi Amazon SQS
Per elaborare i messaggi Amazon SQS con Lambda, configura la coda con le impostazioni appropriate, quindi crea uno strumento di mappatura dell'origine degli eventi Lambda.
**Topics**
+ [
## Configurazione di una coda da utilizzare con Lambda
](#events-sqs-queueconfig)
+ [
## Impostazione delle autorizzazioni del ruolo di esecuzione Lambda
](#events-sqs-permissions)
+ [
## Creazione di uno strumento di mappatura dell'origine degli eventi SQS
](#events-sqs-eventsource)
## Configurazione di una coda da utilizzare con Lambda
Se non disponi già di una coda Amazon SQS esistente, [creane una](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-create-queue.html) da utilizzare come origine eventi per la funzione Lambda. [La funzione Lambda e la coda Amazon SQS devono trovarsi nella Regione AWS stessa posizione, anche se possono trovarsi in posizioni diverse. Account AWS](with-sqs-cross-account-example.md)
Per concedere alla funzione il tempo necessario per elaborare ogni batch di record, imposta il [timeout di visibilità](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) della coda di origine su un valore pari ad almeno sei volte il [timeout di configurazione](configuration-timeout.md) per la funzione. Il tempo aggiuntivo consente a Lambda di riprovare se l'esecuzione della funzione viene limitata durante l'elaborazione di un batch precedente.
**Nota**
Il timeout della funzione deve essere inferiore o uguale al timeout di visibilità della coda. Lambda convalida questo requisito quando si crea o si aggiorna una mappatura dell'origine degli eventi e restituisce un errore se il timeout della funzione supera il timeout di visibilità della coda.
Per impostazione predefinita, se Lambda rileva un errore in qualsiasi momento durante l'elaborazione di un batch, tutti i messaggi in quel batch ritorneranno nella coda. Dopo il [timeout di visibilità](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html), i messaggi diventano nuovamente visibili a Lambda. È possibile configurare lo strumento di mappatura dell'origine degli eventi in modo da utilizzare [risposte batch parziali](services-sqs-errorhandling.md#services-sqs-batchfailurereporting) per restituire alla coda solo i messaggi non riusciti. Se la funzione dovesse non riuscire più volte a elaborare un messaggio, Amazon SQS può inviarlo a una [coda DLQ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html). Ti consigliamo di impostare `maxReceiveCount` sulla [policy redrive](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html#policies-for-dead-letter-queues) della coda di origine su un valore pari almeno a 5. Ciò offre a Lambda alcune possibilità di riprovare prima di inviare i messaggi non riusciti direttamente alla coda DLQ.
## Impostazione delle autorizzazioni del ruolo di esecuzione Lambda
La policy [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html) AWS gestita include le autorizzazioni di cui Lambda ha bisogno per leggere dalla coda Amazon SQS. Puoi aggiungere questa policy gestita al [ruolo di esecuzione](lambda-intro-execution-role.md) della tua funzione.
Facoltativamente, se utilizzi una coda crittografata, devi anche aggiungere la seguente autorizzazione al tuo ruolo di esecuzione:
+ [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)
## Creazione di uno strumento di mappatura dell'origine degli eventi SQS
Creare una mappatura dell'origine eventi per indicare a Lambda di inviare le voci dalla coda a una funzione Lambda. È possibile creare più mappature delle origini eventi per elaborare elementi da più code con una singola funzione. Quando Lambda richiama la funzione di destinazione, l'evento può contenere più voci, fino a una *dimensione batch* massima configurabile.
Per configurare la tua funzione per la lettura da Amazon SQS, collega la policy [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html) AWS gestita al tuo ruolo di esecuzione. Quindi, crea uno strumento di mappatura dell'origine degli eventi **SQS** dalla console utilizzando i seguenti passaggi.
**Per aggiungere le autorizzazioni e creare un trigger**
1. Aprire la pagina [Functions](https://console.aws.amazon.com/lambda/home#/functions) (Funzioni) della console Lambda.
1. Scegliere il nome della funzione.
1. Quindi, seleziona la scheda **Configuration** (Configurazione) e poi **Permissions** (Autorizzazioni).
1. In **Nome del ruolo**, scegli il link al tuo ruolo di esecuzione. Questo ruolo si apre nella console IAM.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/execution-role.png)
1. Seleziona **Aggiungi autorizzazioni**, quindi seleziona **Collega policy**.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/attach-policies.png)
1. Inserisci `AWSLambdaSQSQueueExecutionRole` nel campo di ricerca. Aggiungi questa policy al tuo ruolo di esecuzione. Si tratta di una policy AWS gestita che contiene le autorizzazioni di cui la funzione ha bisogno per leggere da una coda Amazon SQS. Per ulteriori informazioni su questa politica, consulta il *AWS Managed* Policy [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html)Reference.
1. Torna alla funzione nella console Lambda. In **Panoramica delle funzioni**, scegliere **Aggiungi trigger**.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/add-trigger.png)
1. Scegliere un tipo di trigger.
1. Configurare le opzioni richieste, quindi scegliere **Add (Aggiungi)**.
Lambda supporta le seguenti opzioni di configurazione per le origini eventi di Amazon SQS:
**Coda SQS**
La coda Amazon SQS da cui leggere i record. [La funzione Lambda e la coda Amazon SQS devono trovarsi nella Regione AWS stessa posizione, anche se possono trovarsi in posizioni diverse. Account AWS](with-sqs-cross-account-example.md)
**Abilita trigger**
Lo stato dello strumento di mappatura dell'origine degli eventi. L'opzione **Enable trigger** (Abilita trigger) è selezionata per impostazione predefinita.
**Dimensione batch**
Il numero massimo di record da inviare alla funzione in ogni batch. Per una coda standard il numero di registri può arrivare fino a 10.000. Per una coda FIFO il massimo è 10. Per un batch di dimensioni superiori a 10, è inoltre necessario la finestra batch (`MaximumBatchingWindowInSeconds`) su almeno 1 secondo.
Configura il [timeout della funzione](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/configurations#timeouts) per consentire il tempo necessario all'elaborazione di un intero batch di elementi. Se gli elementi richiedono tempi di elaborazione più lunghi, scegli un batch di dimensioni più piccole. Un batch di grandi dimensioni può migliorare l'efficienza per i carichi di lavoro molto veloci o con costi di gestione molto elevati. Se si configura la [concorrenza riservata](configuration-concurrency.md) sulla funzione, impostare un minimo di cinque esecuzioni simultanee per ridurre le probabilità di errori di limitazione (della larghezza di banda della rete) quando Lambda richiama la funzione.
Lambda passa tutti i registri del batch alla funzione in una singola chiamata, purché la dimensione totale degli eventi non superi la [quota della dimensione del payload di invocazione](gettingstarted-limits.md) per una invocazione sincrona (6 MB). Per ogni registro, vengono generati metadati sia da Lambda che da Amazon SQS. Questi metadati aggiuntivi vengono conteggiati per la dimensione totale del payload e possono far sì che il numero totale di registri inviati in un batch sia inferiore alla dimensione del batch configurato. I campi di metadati inviati da Amazon SQS possono essere di lunghezza variabile. Per ulteriori informazioni sui campi di metadati di Amazon SQS, consulta la documentazione sul funzionamento delle [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)API nell'*Amazon Simple Queue* Service API Reference.
**Finestra batch**
Il tempo massimo in secondi per la raccolta dei record prima di richiamare la funzione. Questo parametro si applica solo alle code standard.
Se si utilizza un periodo batch superiore a 0 secondi, è necessario tenere conto dell'aumento del tempo di elaborazione nel [timeout di visibilità](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) della coda. Si consiglia di impostare il timeout di visibilità della coda ad un tempo sei volte maggiore rispetto al [timeout della funzione](configuration-timeout.md), più il valore di `MaximumBatchingWindowInSeconds`. Ciò consente alla funzione Lambda di elaborare ogni batch di eventi e riprovare in caso di errore di throttling.
Quando i messaggi diventano disponibili, Lambda avvia l'elaborazione dei messaggi in batch. Lambda inizia a elaborare cinque batch alla volta con cinque chiamate simultanee della funzione. Se i messaggi sono ancora disponibili, Lambda aggiunge fino a 300 richiami simultanei della funzione al minuto, fino a un massimo di 1.250 richiami simultanei. Quando si utilizza la modalità provisioned, ogni event poller può gestire fino all'1% MB/s del throughput, fino a 10 richiami simultanei o fino a 10 chiamate API di polling di Amazon SQS al secondo. Lambda ridimensiona il numero di event poller tra il minimo e il massimo configurati, aggiungendo rapidamente fino a 1.000 richiami simultanei al minuto per fornire un'elaborazione a bassa latenza degli eventi Amazon SQS. Puoi controllare la scalabilità e la concorrenza tramite queste impostazioni minime e massime del poller degli eventi. Per ulteriori informazioni sul ridimensionamento e sulla concorrenza delle funzioni, consulta. [Informazioni sulla scalabilità della funzione Lambda](lambda-concurrency.md)
Per elaborare più messaggi, puoi ottimizzare la funzione Lambda per un maggiore throughput. Per ulteriori informazioni, consulta [Comprendere la AWS Lambda scalabilità con le code standard di Amazon SQS.](https://aws.amazon.com/blogs/compute/understanding-how-aws-lambda-scales-when-subscribed-to-amazon-sqs-queues/#:~:text=If there are more messages,messages from the SQS queue.)
**Criteri di filtro**
Aggiungi i criteri di filtro per controllare gli eventi che Lambda invia alla funzione per l'elaborazione. Per ulteriori informazioni, consulta [Controllare gli eventi che Lambda invia alla funzione](invocation-eventfiltering.md).
**Simultaneità massima**
Il numero massimo di funzioni simultanee che l'origine eventi può richiamare. Non può essere utilizzato con la modalità Provisioned Mode abilitata. Per ulteriori informazioni, consulta [Configurazione della simultaneità massima per le origini eventi di Amazon SQS](services-sqs-scaling.md#events-sqs-max-concurrency).
**Modalità assegnata**
Se abilitata, alloca risorse di polling dedicate per la mappatura delle sorgenti degli eventi. È possibile configurare il numero minimo (2-200) e massimo (2-2000) di sondaggi di eventi. Ogni event poller può gestire fino all'1% MB/sec del throughput, fino a 10 chiamate simultanee o fino a 10 chiamate API di polling di Amazon SQS al secondo.
Nota: non è possibile utilizzare contemporaneamente Provisioned Mode e Maximum Concurrency. Quando la modalità Provisioned Mode è abilitata, utilizza l'impostazione del numero massimo di poller per controllare la concorrenza.
# Configurazione del comportamento di dimensionamento per gli strumenti di mappatura dell'origine degli eventi
Puoi controllare il comportamento di scalabilità delle mappature delle sorgenti degli eventi di Amazon SQS tramite impostazioni di massima concorrenza o abilitando la modalità provisioning. Si tratta di opzioni che si escludono a vicenda.
Per impostazione predefinita, Lambda ridimensiona automaticamente i poller di eventi in base al volume dei messaggi. Quando abiliti la modalità provisioned, allochi un numero minimo e massimo di risorse di polling dedicate che rimangono pronte a gestire i modelli di traffico previsti. Ciò consente di ottimizzare le prestazioni della mappatura delle sorgenti degli eventi in due modi:
+ Modalità standard (impostazione predefinita): Lambda gestisce automaticamente la scalabilità, a partire da un numero limitato di poller e aumentando o diminuendo in base al carico di lavoro.
+ Modalità provisioned: è possibile configurare risorse di polling dedicate con limiti minimi e massimi, che consentono una scalabilità 3 volte più veloce e una capacità di elaborazione fino a 16 volte superiore.
Per le code standard, Lambda utilizza il [long polling](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-short-and-long-polling.html#sqs-long-polling) per eseguire il polling di una coda fino a quando questa non diventa attiva. Quando sono disponibili dei messaggi, Lambda inizia a elaborare cinque batch alla volta con cinque chiamate simultanee della funzione. Se i messaggi sono ancora disponibili, Lambda aumenta il numero di processi che leggono i batch fino a 300 chiamate simultanee in più al minuto. Il numero massimo di richiami che una mappatura dell'origine degli eventi può elaborare contemporaneamente è 1.250. Quando il traffico è basso, Lambda ridimensiona l'elaborazione a cinque chiamate simultanee e può ottimizzarla fino a un minimo di 2 richiami simultanei per ridurre le chiamate Amazon SQS e i costi corrispondenti. Tuttavia, questa ottimizzazione non è disponibile quando si abilita l'impostazione della massima concorrenza.
Per le code FIFO, Lambda invia messaggi alla funzione nell'ordine in cui li riceve. Quando invii un messaggio a una coda FIFO, è necessario specificare un [ID gruppo di messaggi](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/using-messagegroupid-property.html). Amazon SQS garantisce che i messaggi dello stesso gruppo vengano consegnati a Lambda in ordine. Quando Lambda legge i messaggi in batch, ogni batch può contenere messaggi provenienti da più di un gruppo di messaggi, ma l'ordine dei messaggi viene mantenuto. Se la funzione restituisce un errore, questa esegue nuovamente tutti i tentativi necessari sui messaggi interessati, prima che Lambda riceva ulteriori messaggi dallo stesso gruppo.
Quando si utilizza la modalità provisioned, ogni event poller può gestire fino all'1% MB/sec del throughput, fino a 10 richiami simultanei o fino a 10 chiamate API di polling di Amazon SQS al secondo. Lambda ridimensiona il numero di event poller tra il minimo e il massimo configurati, aggiungendo rapidamente fino a 1.000 simultanee al minuto per fornire un'elaborazione coerente e a bassa latenza degli eventi Amazon SQS. L'utilizzo della modalità provisioning comporta costi aggiuntivi. [Per i prezzi dettagliati, consulta la pagina dei prezzi.AWS Lambda](https://aws.amazon.com/lambda/pricing/) Ogni event poller utilizza [lunghi sondaggi](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-short-and-long-polling.html) sulla coda SQS con un massimo di 10 sondaggi al secondo, il che comporta il costo delle richieste API SQS. Per ulteriori informazioni, consulta [i prezzi di Amazon SQS](https://aws.amazon.com/sqs/pricing/ ). Puoi controllare la scalabilità e la concorrenza tramite queste impostazioni minime e massime del poller di eventi, anziché utilizzare l'impostazione di concorrenza massima, poiché queste opzioni non possono essere utilizzate insieme.
**Nota**
Non è possibile utilizzare contemporaneamente l'impostazione di massima concorrenza e la modalità di provisioning. Quando la modalità provisioned è abilitata, puoi controllare la scalabilità e la concorrenza della mappatura delle sorgenti di eventi di Amazon SQS attraverso il numero minimo e massimo di event poller.
## Configurazione della simultaneità massima per le origini eventi di Amazon SQS
È possibile utilizzare l'impostazione di simultaneità massima per controllare il comportamento di dimensionamento delle origini eventi SQS. Tieni presente che non è possibile utilizzare la massima concorrenza con la modalità provisioning abilitata. L'impostazione della simultaneità massima limita il numero di istanze simultanee della funzione che l'origine dell'evento Amazon SQS può richiamare. La simultaneità massima è un'impostazione a livello di origine dell'evento. Se disponi di più origini degli eventi Amazon SQS mappate a una funzione, ogni origine di evento può avere un'impostazione di simultaneità massima separata. È possibile utilizzare la simultaneità massima per evitare che una coda utilizzi tutta la [simultaneità riservata](configuration-concurrency.md) della funzione o il resto della [quota di simultaneità dell'account](gettingstarted-limits.md). Non è previsto alcun addebito per la configurazione della simultaneità massima su un'origine di eventi Amazon SQS.
È importante sottolineare che la simultaneità massima e la simultaneità riservata sono due impostazioni indipendenti. Non è possibile impostare la simultaneità massima su un valore maggiore della simultaneità riservata della funzione. Dopo aver configurato la simultaneità massima, assicurati di non ridurre la simultaneità riservata della funzione a un valore inferiore alla simultaneità massima totale per tutte le origini di eventi Amazon SQS sulla funzione. Altrimenti, Lambda potrebbe limitare i messaggi.
Quando la quota di simultaneità del tuo account è impostata sul valore predefinito di 1.000, uno strumento di mappatura dell'origine degli eventi Amazon SQS può scalare per richiamare istanze di funzioni fino a questo valore, a meno che non si specifichi una simultaneità massima.
Se ricevi un aumento della quota di simultaneità predefinita del tuo account, Lambda potrebbe non essere in grado di richiamare istanze di funzioni simultanee fino alla tua nuova quota. Per impostazione predefinita, Lambda può scalare per richiamare fino a 1.250 istanze di funzioni simultanee per uno strumento di mappatura dell'origine degli eventi Amazon SQS. Se questo non è sufficiente per il tuo caso d'uso, contatta l' AWS assistenza per discutere di un aumento della contemporaneità di mappatura dei sorgenti degli eventi Amazon SQS del tuo account.
**Nota**
Per le code FIFO, le chiamate simultanee sono limitate dal numero di [gruppi di messaggi IDs](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/using-messagegroupid-property.html) () `messageGroupId` o dall'impostazione di concorrenza massima, a seconda di quale sia inferiore. Ad esempio, se avete sei gruppi di messaggi IDs e la concorrenza massima è impostata su 10, la funzione può avere un massimo di sei chiamate simultanee.
Puoi configurare la simultaneità massima sugli strumenti di mappatura dell'origine degli eventi Amazon SQS nuovi ed esistenti.
**Configurazione della simultaneità massima tramite la console Lambda**
1. Aprire la pagina [Functions](https://console.aws.amazon.com/lambda/home#/functions) (Funzioni) della console Lambda.
1. Scegliere il nome della funzione.
1. In **Function overview** (Panoramica delle funzioni), scegli **SQS**. Viene aperta la scheda **Configuration** (Configurazione).
1. Seleziona il trigger Amazon SQS e scegli **Edit** (Modifica).
1. In **Maximum concurrency** (Simultaneità massima), inserisci un numero compreso tra 2 e 1.000. Per disattivare la simultaneità massima, lascia la casella vuota.
1. Scegli **Save** (Salva).
**Configura la massima concorrenza utilizzando () AWS Command Line Interface AWS CLI**
Utilizza il comando [update-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html) con l’opzione `--scaling-config`. Esempio:
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--scaling-config '{"MaximumConcurrency":5}'
```
Per disattivare la simultaneità massima, inserisci un valore vuoto per `--scaling-config`:
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--scaling-config "{}"
```
**Configurazione della simultaneità massima tramite l'API Lambda**
Usa l'[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)azione [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)o con un [ScalingConfig](https://docs.aws.amazon.com/lambda/latest/api/API_ScalingConfig.html)oggetto.
# Gestione degli errori per un'origine eventi SQS in Lambda
Per gestire gli errori relativi a un'origine eventi SQS, Lambda utilizza automaticamente una strategia di riprova con una strategia di backoff. Puoi anche personalizzare il comportamento di gestione degli errori configurando lo strumento di mappatura dell'origine degli eventi SQS per restituire [risposte parziali in batch](#services-sqs-batchfailurereporting).
## Strategia di backoff per le chiamate non riuscite
Quando una chiamata non riesce, Lambda riprovare la chiamata mentre implementa una strategia di backoff. La strategia di backoff varia leggermente a seconda che Lambda abbia riscontrato l'errore a causa di un errore nel codice della funzione o a causa di una limitazione.
+ Se il **codice della funzione** ha causato l'errore, Lambda interromperà l'elaborazione e riproverà l'invocazione. Allo stesso tempo, Lambda si interrompe gradualmente, riducendo la quantità di simultaneità allocata allo strumento di mappatura dell'origine degli eventi di Amazon SQS. Una volta scaduto il timeout di visibilità della coda, il messaggio riapparirà nuovamente nella coda.
+ Se la chiamata non riesce a causa della **limitazione**, Lambda interrompe gradualmente i nuovi tentativi riducendo la quantità di simultaneità allocata allo strumento di mappatura dell'origine degli eventi di Amazon SQS. Lambda continua a riprovare il messaggio fino a quando il timestamp del messaggio non supera il timeout di visibilità della coda e a quel punto Lambda elimina il messaggio.
## Implementazione di risposte batch parziali
Per impostazione predefinita, se la funzione rileva un errore durante l'elaborazione di un batch, tutti i messaggi in quel batch diventano nuovamente visibili nella coda, inclusi i messaggi che Lambda ha elaborato correttamente. Di conseguenza, la tua funzione potrebbe elaborare lo stesso messaggio più volte.
Per evitare di rielaborare tutti i messaggi correttamente elaborati in un batch con errori, puoi configurare lo strumento di mappatura dell'origine degli eventi in modo da rendere nuovamente visibili solo i messaggi con errori. Questa operazione è nota come risposta batch parziale. Per attivare le risposte parziali in batch, specifica l'[FunctionResponseTypes](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html#lambda-UpdateEventSourceMapping-request-FunctionResponseTypes)azione durante `ReportBatchItemFailures` la configurazione della mappatura della fonte dell'evento. Ciò consente alla funzione di restituire un completamento parziale, riducendo così il numero di tentativi non necessari sui registri.
**Nota**
L'[utilità Batch Processor](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) di Powertools AWS Lambda gestisce automaticamente tutta la logica di risposta batch parziale. Questa utilità semplifica l'implementazione dei modelli di elaborazione in batch e riduce il codice personalizzato necessario per gestire correttamente gli errori degli articoli in batch. È disponibile per Python, Java, Typescript e.NET.
Se `ReportBatchItemFailures` è attivata, Lambda non [riduce il polling dei messaggi](#services-sqs-backoff-strategy) quando le invocazioni delle funzioni hanno esito negativo. Se prevedi che alcuni messaggi falliscano e non desideri che tali errori influiscano sulla velocità di elaborazione dei messaggi, utilizza `ReportBatchItemFailures`.
**Nota**
Quando utilizzi le risposte batch, tieni presente quanto segue:
Se la funzione restituisce un'eccezione, l'intero batch viene considerato completamente non riuscito.
Se si utilizza questa caratteristica con una coda FIFO, la funzione dovrebbe interrompere l'elaborazione dei messaggi dopo il primo errore e restituire tutti i messaggi di errore e non elaborati in `batchItemFailures`. Ciò aiuta a preservare l'ordine dei messaggi nella coda.
**Attivazione di report batch parziali**
1. Rivedi le [best practice per l'implementazione di risposte batch parziali](https://docs.aws.amazon.com/prescriptive-guidance/latest/lambda-event-filtering-partial-batch-responses-for-sqs/best-practices-partial-batch-responses.html).
1. Per attivare `ReportBatchItemFailures` per la tua funzione, esegui il comando riportato di seguito. Per recuperare l'UUID della mappatura della sorgente degli eventi, esegui il comando. [list-event-source-mappings](https://docs.aws.amazon.com/cli/latest/reference/lambda/list-event-source-mappings.html) AWS CLI
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--function-response-types "ReportBatchItemFailures"
```
1. Aggiorna il codice della funzione per rilevare tutte le eccezioni e restituire i messaggi con errori in una risposta `batchItemFailures` in JSON. La `batchItemFailures` risposta deve includere un elenco di messaggi IDs, sotto forma di valori JSON. `itemIdentifier`
Ad esempio, supponiamo di avere un batch di cinque messaggi, IDs `id1`, `id2` `id3``id4`, e. `id5` La tua funzione elabora correttamente `id1`, `id3`, e `id5`. Per rendere i messaggi `id2` e `id4` di nuovo visibili nella coda, la funzione dovrebbe restituire la seguente risposta:
```
{
"batchItemFailures": [
{
"itemIdentifier": "id2"
},
{
"itemIdentifier": "id4"
}
]
}
```
Di seguito sono riportati alcuni esempi di codice di funzione che restituiscono l'elenco dei messaggi non riusciti IDs nel batch:
------
#### [ .NET ]
**SDK per .NET**
C'è altro su GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Segnalazione di errori di elementi batch di SQS con Lambda tramite .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using Amazon.Lambda.Core;
using Amazon.Lambda.SQSEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace sqsSample;
public class Function
{
public async Task FunctionHandler(SQSEvent evnt, ILambdaContext context)
{
List batchItemFailures = new List();
foreach(var message in evnt.Records)
{
try
{
//process your message
await ProcessMessageAsync(message, context);
}
catch (System.Exception)
{
//Add failed message identifier to the batchItemFailures list
batchItemFailures.Add(new SQSBatchResponse.BatchItemFailure{ItemIdentifier=message.MessageId});
}
}
return new SQSBatchResponse(batchItemFailures);
}
private async Task ProcessMessageAsync(SQSEvent.SQSMessage message, ILambdaContext context)
{
if (String.IsNullOrEmpty(message.Body))
{
throw new Exception("No Body in SQS Message.");
}
context.Logger.LogInformation($"Processed message {message.Body}");
// TODO: Do interesting work based on the new message
await Task.CompletedTask;
}
}
```
------
#### [ Go ]
**SDK per Go V2**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Segnalazione di errori di elementi batch di SQS con Lambda tramite Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(ctx context.Context, sqsEvent events.SQSEvent) (map[string]interface{}, error) {
batchItemFailures := []map[string]interface{}{}
for _, message := range sqsEvent.Records {
if len(message.Body) > 0 {
// Your message processing condition here
fmt.Printf("Successfully processed message: %s\n", message.Body)
} else {
// Message processing failed
fmt.Printf("Failed to process message %s\n", message.MessageId)
batchItemFailures = append(batchItemFailures, map[string]interface{}{"itemIdentifier": message.MessageId})
}
}
sqsBatchResponse := map[string]interface{}{
"batchItemFailures": batchItemFailures,
}
return sqsBatchResponse, nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK per Java 2.x**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Segnalazione di errori di elementi batch di SQS con Lambda tramite Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.SQSEvent;
import com.amazonaws.services.lambda.runtime.events.SQSBatchResponse;
import java.util.ArrayList;
import java.util.List;
public class ProcessSQSMessageBatch implements RequestHandler {
@Override
public SQSBatchResponse handleRequest(SQSEvent sqsEvent, Context context) {
List batchItemFailures = new ArrayList();
for (SQSEvent.SQSMessage message : sqsEvent.getRecords()) {
try {
//process your message
} catch (Exception e) {
//Add failed message identifier to the batchItemFailures list
batchItemFailures.add(new SQSBatchResponse.BatchItemFailure(message.getMessageId()));
}
}
return new SQSBatchResponse(batchItemFailures);
}
}
```
------
#### [ JavaScript ]
**SDK per JavaScript (v3)**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Segnalazione degli errori degli elementi batch SQS utilizzando Lambda. JavaScript
```
// Node.js 20.x Lambda runtime, AWS SDK for Javascript V3
export const handler = async (event, context) => {
const batchItemFailures = [];
for (const record of event.Records) {
try {
await processMessageAsync(record, context);
} catch (error) {
batchItemFailures.push({ itemIdentifier: record.messageId });
}
}
return { batchItemFailures };
};
async function processMessageAsync(record, context) {
if (record.body && record.body.includes("error")) {
throw new Error("There is an error in the SQS Message.");
}
console.log(`Processed message: ${record.body}`);
}
```
Segnalazione degli errori degli elementi batch SQS utilizzando Lambda. TypeScript
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import { SQSEvent, SQSBatchResponse, Context, SQSBatchItemFailure, SQSRecord } from 'aws-lambda';
export const handler = async (event: SQSEvent, context: Context): Promise => {
const batchItemFailures: SQSBatchItemFailure[] = [];
for (const record of event.Records) {
try {
await processMessageAsync(record);
} catch (error) {
batchItemFailures.push({ itemIdentifier: record.messageId });
}
}
return {batchItemFailures: batchItemFailures};
};
async function processMessageAsync(record: SQSRecord): Promise {
if (record.body && record.body.includes("error")) {
throw new Error('There is an error in the SQS Message.');
}
console.log(`Processed message ${record.body}`);
}
```
------
#### [ PHP ]
**SDK per PHP**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Segnalazione di errori di elementi batch di SQS con Lambda tramite PHP.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
logger = $logger;
}
/**
* @throws JsonException
* @throws \Bref\Event\InvalidLambdaEvent
*/
public function handleSqs(SqsEvent $event, Context $context): void
{
$this->logger->info("Processing SQS records");
$records = $event->getRecords();
foreach ($records as $record) {
try {
// Assuming the SQS message is in JSON format
$message = json_decode($record->getBody(), true);
$this->logger->info(json_encode($message));
// TODO: Implement your custom processing logic here
} catch (Exception $e) {
$this->logger->error($e->getMessage());
// failed processing the record
$this->markAsFailed($record);
}
}
$totalRecords = count($records);
$this->logger->info("Successfully processed $totalRecords SQS records");
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**SDK per Python (Boto3)**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Segnalazione di errori di elementi batch di SQS con Lambda tramite Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event, context):
if event:
batch_item_failures = []
sqs_batch_response = {}
for record in event["Records"]:
try:
print(f"Processed message: {record['body']}")
except Exception as e:
batch_item_failures.append({"itemIdentifier": record['messageId']})
sqs_batch_response["batchItemFailures"] = batch_item_failures
return sqs_batch_response
```
------
#### [ Ruby ]
**SDK per Ruby**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda-with-batch-item-handling).
Segnalazione di errori di elementi batch di SQS con Lambda tramite Ruby.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
require 'json'
def lambda_handler(event:, context:)
if event
batch_item_failures = []
sqs_batch_response = {}
event["Records"].each do |record|
begin
# process message
rescue StandardError => e
batch_item_failures << {"itemIdentifier" => record['messageId']}
end
end
sqs_batch_response["batchItemFailures"] = batch_item_failures
return sqs_batch_response
end
end
```
------
#### [ Rust ]
**SDK per Rust**
C'è altro da fare. GitHub Trova l'esempio completo e scopri come eseguire la configurazione e l'esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Segnalazione di errori di elementi batch di SQS con Lambda tramite Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::{
event::sqs::{SqsBatchResponse, SqsEvent},
sqs::{BatchItemFailure, SqsMessage},
};
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
async fn process_record(_: &SqsMessage) -> Result<(), Error> {
Err(Error::from("Error processing message"))
}
async fn function_handler(event: LambdaEvent) -> Result {
let mut batch_item_failures = Vec::new();
for record in event.payload.records {
match process_record(&record).await {
Ok(_) => (),
Err(_) => batch_item_failures.push(BatchItemFailure {
item_identifier: record.message_id.unwrap(),
}),
}
}
Ok(SqsBatchResponse {
batch_item_failures,
})
}
#[tokio::main]
async fn main() -> Result<(), Error> {
run(service_fn(function_handler)).await
}
```
------
Se gli eventi non riusciti non tornano in coda, vedi [Come posso risolvere i problemi della funzione Lambda](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-sqs-report-batch-item-failures/) SQS? ReportBatchItemFailures nel Knowledge Center. AWS
### Condizioni di successo e di errore
Lambda considera un batch completamente riuscito se la funzione restituisce uno dei seguenti elementi:
+ Una `batchItemFailures` lista vuota
+ Un `batchItemFailures` elenco nullo
+ Un vuoto `EventResponse`
+ Un valore nullo `EventResponse`
Lambda considera un batch completamente non riuscito se la funzione restituisce uno dei seguenti elementi:
+ Risposta JSON non valida
+ Una stringa vuota `itemIdentifier`
+ Un valore nullo `itemIdentifier`
+ Un `itemIdentifier` con un nome chiave errato
+ Un `itemIdentifier` valore di con un ID messaggio inesistente
### CloudWatch metriche
Per determinare se la tua funzione riporta correttamente gli errori degli articoli in batch, puoi monitorare i parametri `NumberOfMessagesDeleted` e `ApproximateAgeOfOldestMessage` Amazon SQS in Amazon. CloudWatch
+ `NumberOfMessagesDeleted` tiene traccia del numero di messaggi rimossi dalla coda. Se questo scende a 0, significa che la risposta alla funzione non sta restituendo correttamente i messaggi non riusciti.
+ `ApproximateAgeOfOldestMessage` tiene traccia del tempo di permanenza del messaggio meno recente all'interno della coda. Un incremento considerevole di questo parametro può indicare che la funzione non sta restituendo correttamente i messaggi non riusciti.
### Utilizzo di Powertools per il processore batch AWS Lambda
L'utilità per il processore batch di Powertools gestisce AWS Lambda automaticamente la logica di risposta parziale in batch, riducendo la complessità dell'implementazione della segnalazione degli errori dei batch. Ecco alcuni esempi di utilizzo del processore batch:
**Python**
Per esempi completi e istruzioni di configurazione, consultate la [documentazione del processore batch](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/).
Elaborazione di messaggi Amazon SQS con processore AWS Lambda batch.
```
import json
from aws_lambda_powertools import Logger
from aws_lambda_powertools.utilities.batch import BatchProcessor, EventType, process_partial_response
from aws_lambda_powertools.utilities.data_classes import SQSEvent
from aws_lambda_powertools.utilities.typing import LambdaContext
processor = BatchProcessor(event_type=EventType.SQS)
logger = Logger()
def record_handler(record):
logger.info(record)
# Your business logic here
# Raise an exception to mark this record as failed
def lambda_handler(event, context: LambdaContext):
return process_partial_response(
event=event,
record_handler=record_handler,
processor=processor,
context=context
)
```
**TypeScript**
Per esempi completi e istruzioni di configurazione, consulta la [documentazione del processore batch](https://docs.aws.amazon.com/powertools/typescript/latest/features/batch/).
Elaborazione di messaggi Amazon SQS con processore AWS Lambda batch.
```
import { BatchProcessor, EventType, processPartialResponse } from '@aws-lambda-powertools/batch';
import { Logger } from '@aws-lambda-powertools/logger';
import type { SQSEvent, Context } from 'aws-lambda';
const processor = new BatchProcessor(EventType.SQS);
const logger = new Logger();
const recordHandler = async (record: any): Promise => {
logger.info('Processing record', { record });
// Your business logic here
// Throw an error to mark this record as failed
};
export const handler = async (event: SQSEvent, context: Context) => {
return processPartialResponse(event, recordHandler, processor, {
context,
});
};
```
# Parametri Lambda per gli strumenti di mappatura dell'origine degli eventi di Amazon SQS
Tutti i tipi di sorgenti di eventi Lambda condividono le stesse operazioni [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)e quelle dell'[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)API. Tuttavia, solo alcuni dei parametri si applicano ad Amazon SQS.
| Parametro | Obbligatorio | Predefinito | Note |
| --- | --- | --- | --- |
| BatchSize | N | 10 | Per le code standard il massimo è 10.000. Per le code FIFO il massimo è 10. |
| Abilitato | N | true | nessuno |
| EventSourceArn | Y | N/D | L'ARN del flusso dei dati o di un consumatore di flusso |
| FunctionName | Y | N/D | nessuno |
| FilterCriteria | N | N/D | [Controllare gli eventi che Lambda invia alla funzione](invocation-eventfiltering.md) |
| FunctionResponseTypes | N | N/D | Per consentire alla funzione di segnalare errori specifici in un batch, includi il valore `ReportBatchItemFailures` in `FunctionResponseTypes`. Per ulteriori informazioni, consulta [Implementazione di risposte batch parziali](services-sqs-errorhandling.md#services-sqs-batchfailurereporting). |
| MaximumBatchingWindowInSeconds | N | 0 | La creazione di finestre di batch non è supportata per le code FIFO |
| ProvisionedPollerConfig | N | N/D | Configura il numero minimo (2-200) e massimo (2-2000) di poller di eventi dedicati per la mappatura delle sorgenti degli eventi SQS. Ogni poller può gestire fino all'1% del throughput e 10 richiami simultanei MB/sec . |
| ScalingConfig | N | N/D | [Configurazione della simultaneità massima per le origini eventi di Amazon SQS](services-sqs-scaling.md#events-sqs-max-concurrency) |
# Utilizzo del filtro eventi con un'origine eventi Amazon SQS
Puoi utilizzare il filtraggio degli eventi per controllare quali record di un flusso o di una coda Lambda invia alla funzione. Per informazioni generali sul funzionamento del filtraggio eventi, consulta [Controllare gli eventi che Lambda invia alla funzione](invocation-eventfiltering.md).
In questa sezione viene descritto il filtraggio degli eventi per le origini di eventi Amazon MQ.
**Nota**
Le mappature delle sorgenti degli eventi di Amazon SQS supportano solo il filtraggio sulla chiave. `body`
**Topics**
+ [
## Nozioni di base sul filtraggio degli eventi di Amazon SQS
](#filtering-SQS)
## Nozioni di base sul filtraggio degli eventi di Amazon SQS
Supponiamo che la coda Amazon SQS contenga messaggi nel formato JSON seguente.
```
{
"RecordNumber": 1234,
"TimeStamp": "yyyy-mm-ddThh:mm:ss",
"RequestCode": "AAAA"
}
```
Un record di esempio per questa coda sarebbe il seguente.
```
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "{\n "RecordNumber": 1234,\n "TimeStamp": "yyyy-mm-ddThh:mm:ss",\n "RequestCode": "AAAA"\n}",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-west-2:123456789012:my-queue",
"awsRegion": "us-west-2"
}
```
Per filtrare in base al contenuto dei messaggi Amazon SQS, utilizza la chiave `body` nel record dei messaggi Amazon SQS. Supponiamo di voler elaborare solo i record nei quali il `RequestCode` del messaggio Amazon SQS è "BBBB". L'oggetto `FilterCriteria` dovrebbe avere la struttura seguente.
```
{
"Filters": [
{
"Pattern": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"
}
]
}
```
Per una maggiore chiarezza, ecco il valore del `Pattern` del filtro espanso in JSON semplice.
```
{
"body": {
"RequestCode": [ "BBBB" ]
}
}
```
Puoi aggiungere il filtro utilizzando la console, la AWS CLI o un modello AWS SAM.
------
#### [ Console ]
Per aggiungere questo filtro utilizzando la console, segui le istruzioni riportate in [Collegamento dei criteri di filtro a una mappatura dell'origine evento (console)](invocation-eventfiltering.md#filtering-console) e inserisci la seguente stringa per i **criteri di filtraggio**.
```
{ "body" : { "RequestCode" : [ "BBBB" ] } }
```
------
#### [ AWS CLI ]
Per creare una nuova mappatura dell'origine degli eventi con questi criteri di filtraggio utilizzando l'AWS Command Line Interface (AWS CLI), esegui il comando seguente.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:sqs:us-east-2:123456789012:my-queue \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"}]}'
```
Per aggiungere questi criteri di filtraggio a una mappatura dell'origine degli eventi esistente, esegui il comando seguente.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"}]}'
```
------
#### [ AWS SAM ]
Per aggiungere questo filtro utilizzando AWS SAM, aggiungi il seguente frammento al modello YAML dell'origine degli eventi.
```
FilterCriteria:
Filters:
- Pattern: '{ "body" : { "RequestCode" : [ "BBBB" ] } }'
```
------
Supponiamo che tu voglia che la tua funzione elabori solo i record in cui `RecordNumber` è maggiore di 9999. L'oggetto `FilterCriteria` dovrebbe avere la struttura seguente.
```
{
"Filters": [
{
"Pattern": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"
}
]
}
```
Per una maggiore chiarezza, ecco il valore del `Pattern` del filtro espanso in JSON semplice.
```
{
"body": {
"RecordNumber": [
{
"numeric": [ ">", 9999 ]
}
]
}
}
```
Puoi aggiungere il filtro utilizzando la console, la AWS CLI o un modello AWS SAM.
------
#### [ Console ]
Per aggiungere questo filtro utilizzando la console, segui le istruzioni riportate in [Collegamento dei criteri di filtro a una mappatura dell'origine evento (console)](invocation-eventfiltering.md#filtering-console) e inserisci la seguente stringa per i **criteri di filtraggio**.
```
{ "body" : { "RecordNumber" : [ { "numeric": [ ">", 9999 ] } ] } }
```
------
#### [ AWS CLI ]
Per creare una nuova mappatura dell'origine degli eventi con questi criteri di filtraggio utilizzando l'AWS Command Line Interface (AWS CLI), esegui il comando seguente.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:sqs:us-east-2:123456789012:my-queue \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"}]}'
```
Per aggiungere questi criteri di filtraggio a una mappatura dell'origine degli eventi esistente, esegui il comando seguente.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"}]}'
```
------
#### [ AWS SAM ]
Per aggiungere questo filtro utilizzando AWS SAM, aggiungi il seguente frammento al modello YAML dell'origine degli eventi.
```
FilterCriteria:
Filters:
- Pattern: '{ "body" : { "RecordNumber" : [ { "numeric": [ ">", 9999 ] } ] } }'
```
------
Per Amazon SQS, il corpo del messaggio può essere qualsiasi stringa. Tuttavia, questo può essere problematico se il `FilterCriteria` si aspetta che `body` sia in un formato JSON valido. Anche lo scenario inverso è vero: se il corpo del messaggio in arrivo è in formato JSON ma i criteri di filtraggio si aspettano che `body` sia una stringa semplice, allora si potrebbe riscontrare un comportamento indesiderato.
Per evitare questo problema, assicurati che il formato del corpo nei `FilterCriteria` corrisponda al formato previsto per il `body` nei messaggi ricevuti dalla coda. Prima di filtrare i messaggi, Lambda valuta automaticamente il formato del corpo del messaggio in arrivo e il modello di filtraggio per `body`. In caso di mancata corrispondenza, Lambda rilascia il messaggio. La tabella seguente riepiloga questa valutazione:
| Formato `body` messaggio in arrivo | Formato `body` modello di filtro | Operazione risultante |
| --- | --- | --- |
| Stringa normale | Stringa normale | Filtri Lambda in base ai criteri di filtro. |
| Stringa normale | Nessun modello di filtro per le proprietà dei dati | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
| Stringa normale | JSON valido | Lambda rilascia il messaggio. |
| JSON valido | Stringa normale | Lambda rilascia il messaggio. |
| JSON valido | Nessun modello di filtro per le proprietà dei dati | Filtri Lambda (solo sulle altre proprietà dei metadati) in base ai criteri di filtro. |
| JSON valido | JSON valido | Filtri Lambda in base ai criteri di filtro. |
# Tutorial: Utilizzo di Lambda con Amazon SQS
In questo tutorial creerai una funzione Lambda che utilizza messaggi da una coda di [Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html). La funzione Lambda viene eseguita ogni volta che viene aggiunto un nuovo messaggio alla coda. La funzione scrive i messaggi in un flusso Amazon CloudWatch Logs. Il seguente diagramma illustra le risorse AWS utilizzate per completare il tutorial.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sqs_tut_resources.png)
Per completare questo tutorial, completa le seguenti attività:
1. Crea una funzione Lambda che scrive messaggi nei registri. CloudWatch
1. Creare una coda Amazon SQS.
1. Crea una mappatura dell'origine degli eventi Lambda. La mappatura dell'origine degli eventi legge la coda di Amazon SQS e richiama la funzione Lambda quando viene aggiunto un nuovo messaggio.
1. Verifica la configurazione aggiungendo messaggi alla coda e monitorando i risultati in Logs. CloudWatch
## Prerequisiti
### Installa il AWS Command Line Interface
Se non l'hai ancora installato AWS Command Line Interface, segui i passaggi indicati in [Installazione o aggiornamento della versione più recente di AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) per installarlo.
Per eseguire i comandi nel tutorial, sono necessari un terminale a riga di comando o una shell (interprete di comandi). In Linux e macOS, utilizza la shell (interprete di comandi) e il gestore pacchetti preferiti.
**Nota**
Su Windows, alcuni comandi della CLI Bash utilizzati comunemente con Lambda (ad esempio, `zip`) non sono supportati dai terminali integrati del sistema operativo. Per ottenere una versione integrata su Windows di Ubuntu e Bash, [installa il sottosistema Windows per Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
## Creazione del ruolo di esecuzione
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sqs_tut_steps1.png)
Un [ruolo di esecuzione](lambda-intro-execution-role.md) è un ruolo AWS Identity and Access Management (IAM) che concede a una funzione Lambda l'autorizzazione all' Servizi AWS accesso e alle risorse. Per consentire alla tua funzione di leggere articoli da Amazon SQS, allega la politica di **AWSLambdaSQSQueueExecutionRole**autorizzazione.
**Creazione di un ruolo di esecuzione e collegamento di una policy di autorizzazione Amazon SQS personalizzata**
1. Aprire la [pagina Roles (Ruoli)](https://console.aws.amazon.com/iam/home#/roles) della console IAM.
1. Scegli **Crea ruolo**.
1. Per **Tipo di entità attendibile**, scegli **Servizio AWS **.
1. In **Caso d'uso**, scegli **Lambda**.
1. Scegli **Next (Successivo)**.
1. Nella casella di ricerca **Policy di autorizzazione**, inserisci **AWSLambdaSQSQueueExecutionRole**.
1. **Seleziona la **AWSLambdaSQSQueueExecutionRole**politica, quindi scegli Avanti.**
1. In **Dettagli del ruolo**, per **Nome del ruolo** inserisci **lambda-sqs-role**, quindi scegli **Crea ruolo**.
Dopo la creazione del ruolo, prendi nota del valore del nome della risorsa Amazon (ARN) del ruolo di esecuzione. Ne avrai bisogno nelle fasi successive.
## Creazione della funzione
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sqs_tut_steps2.png)
Crea una funzione Lambda che elabora i messaggi Amazon SQS. Il codice della funzione registra il corpo del messaggio CloudWatch Amazon SQS in Logs.
Questo tutorial utilizza il runtime Node.js 24, ma abbiamo anche fornito codice di esempio in altri linguaggi di runtime. Per visualizzare il codice per il runtime che ti interessa, seleziona la scheda corrispondente nella casella seguente. Il JavaScript codice che utilizzerai in questo passaggio si trova nel primo esempio mostrato nella **JavaScript**scheda.
------
#### [ .NET ]
**SDK per .NET**
C'è altro su GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilizzo di un evento SQS con Lambda tramite .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using Amazon.Lambda.Core;
using Amazon.Lambda.SQSEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace SqsIntegrationSampleCode
{
public async Task FunctionHandler(SQSEvent evnt, ILambdaContext context)
{
foreach (var message in evnt.Records)
{
await ProcessMessageAsync(message, context);
}
context.Logger.LogInformation("done");
}
private async Task ProcessMessageAsync(SQSEvent.SQSMessage message, ILambdaContext context)
{
try
{
context.Logger.LogInformation($"Processed message {message.Body}");
// TODO: Do interesting work based on the new message
await Task.CompletedTask;
}
catch (Exception e)
{
//You can use Dead Letter Queue to handle failures. By configuring a Lambda DLQ.
context.Logger.LogError($"An error occurred");
throw;
}
}
}
```
------
#### [ Go ]
**SDK per Go V2**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilizzo di un evento SQS con Lambda tramite Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package integration_sqs_to_lambda
import (
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(event events.SQSEvent) error {
for _, record := range event.Records {
err := processMessage(record)
if err != nil {
return err
}
}
fmt.Println("done")
return nil
}
func processMessage(record events.SQSMessage) error {
fmt.Printf("Processed message %s\n", record.Body)
// TODO: Do interesting work based on the new message
return nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK per Java 2.x**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilizzo di un evento SQS con Lambda tramite Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.SQSEvent;
import com.amazonaws.services.lambda.runtime.events.SQSEvent.SQSMessage;
public class Function implements RequestHandler {
@Override
public Void handleRequest(SQSEvent sqsEvent, Context context) {
for (SQSMessage msg : sqsEvent.getRecords()) {
processMessage(msg, context);
}
context.getLogger().log("done");
return null;
}
private void processMessage(SQSMessage msg, Context context) {
try {
context.getLogger().log("Processed message " + msg.getBody());
// TODO: Do interesting work based on the new message
} catch (Exception e) {
context.getLogger().log("An error occurred");
throw e;
}
}
}
```
------
#### [ JavaScript ]
**SDK per JavaScript (v3)**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/blob/main/integration-sqs-to-lambda).
Consumo di un evento SQS con JavaScript Lambda utilizzando.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
exports.handler = async (event, context) => {
for (const message of event.Records) {
await processMessageAsync(message);
}
console.info("done");
};
async function processMessageAsync(message) {
try {
console.log(`Processed message ${message.body}`);
// TODO: Do interesting work based on the new message
await Promise.resolve(1); //Placeholder for actual async work
} catch (err) {
console.error("An error occurred");
throw err;
}
}
```
Consumo di un evento SQS con TypeScript Lambda utilizzando.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import { SQSEvent, Context, SQSHandler, SQSRecord } from "aws-lambda";
export const functionHandler: SQSHandler = async (
event: SQSEvent,
context: Context
): Promise => {
for (const message of event.Records) {
await processMessageAsync(message);
}
console.info("done");
};
async function processMessageAsync(message: SQSRecord): Promise {
try {
console.log(`Processed message ${message.body}`);
// TODO: Do interesting work based on the new message
await Promise.resolve(1); //Placeholder for actual async work
} catch (err) {
console.error("An error occurred");
throw err;
}
}
```
------
#### [ PHP ]
**SDK per PHP**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilizzo di un evento SQS con Lambda tramite PHP.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
logger = $logger;
}
/**
* @throws InvalidLambdaEvent
*/
public function handleSqs(SqsEvent $event, Context $context): void
{
foreach ($event->getRecords() as $record) {
$body = $record->getBody();
// TODO: Do interesting work based on the new message
}
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**SDK per Python (Boto3)**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilizzo di un evento SQS con Lambda tramite Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event, context):
for message in event['Records']:
process_message(message)
print("done")
def process_message(message):
try:
print(f"Processed message {message['body']}")
# TODO: Do interesting work based on the new message
except Exception as err:
print("An error occurred")
raise err
```
------
#### [ Ruby ]
**SDK per Ruby**
C'è dell'altro GitHub. Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilizzo di un evento SQS con Lambda tramite Ruby.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event:, context:)
event['Records'].each do |message|
process_message(message)
end
puts "done"
end
def process_message(message)
begin
puts "Processed message #{message['body']}"
# TODO: Do interesting work based on the new message
rescue StandardError => err
puts "An error occurred"
raise err
end
end
```
------
#### [ Rust ]
**SDK per Rust**
C'è altro da fare. GitHub Trova l’esempio completo e scopri come eseguire la configurazione e l’esecuzione nel repository di [Esempi serverless](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilizzo di un evento SQS con Lambda tramite Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::event::sqs::SqsEvent;
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
async fn function_handler(event: LambdaEvent) -> Result<(), Error> {
event.payload.records.iter().for_each(|record| {
// process the record
tracing::info!("Message body: {}", record.body.as_deref().unwrap_or_default())
});
Ok(())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
// disable printing the name of the module in every log line.
.with_target(false)
// disabling time is handy because CloudWatch will add the ingestion time.
.without_time()
.init();
run(service_fn(function_handler)).await
}
```
------
**Creazione di una funzione Lambda in Node.js**
1. Crea una directory per il progetto, quindi passa a quella directory.
```
mkdir sqs-tutorial
cd sqs-tutorial
```
1. Copia il JavaScript codice di esempio in un nuovo file denominato`index.js`.
1. Crea un pacchetto di implementazione utilizzando il seguente comando `zip`.
```
zip function.zip index.js
```
1. Crea una funzione Lambda utilizzando il comando [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html) della AWS CLI . Per il `role` parametro, immettere l'ARN del ruolo di esecuzione creato in precedenza.
**Nota**
La funzione Lambda e la coda Amazon SQS devono trovarsi nella stessa Regione AWS.
```
aws lambda create-function --function-name ProcessSQSRecord \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--role arn:aws:iam::111122223333:role/lambda-sqs-role
```
## Test della funzione
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sqs_tut_steps3.png)
Richiama la funzione Lambda manualmente utilizzando `invoke` AWS CLI il comando e un evento Amazon SQS di esempio.
**Invocazione della funzione Lambda con un evento di esempio**
1. Salva il seguente JSON come un file denominato `input.json`. Questo JSON simula un evento che Amazon SQS potrebbe inviare alla tua funzione Lambda, dove `"body"` contiene il messaggio effettivo dalla coda. In questo esempio, il messaggio è `"test"`.
**Example Evento Amazon SQS**
Questo è un evento di test: non è necessario modificare il messaggio o il numero di account.
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "test",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "098f6bcd4621d373cade4e832627b4f6",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-1:111122223333:my-queue",
"awsRegion": "us-east-1"
}
]
}
```
1. [Esegui il seguente comando invoke.](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/invoke.html) AWS CLI Questo comando restituisce CloudWatch i log nella risposta. Per ulteriori informazioni sul recupero di oggetti, consulta [Accedi ai log con AWS CLI](monitoring-cloudwatchlogs-view.md#monitoring-cloudwatchlogs-cli).
```
aws lambda invoke --function-name ProcessSQSRecord --payload file://input.json out --log-type Tail \
--query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode
```
L'**cli-binary-format**opzione è obbligatoria se si utilizza la AWS CLI versione 2. Per rendere questa impostazione come predefinita, esegui `aws configure set cli-binary-format raw-in-base64-out`. Per ulteriori informazioni, consulta la pagina [AWS CLI supported global command line options](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) nella *Guida per l'utente di AWS Command Line Interface versione 2*.
1. Individua il log `INFO` nella risposta. È qui che la funzione Lambda registra il corpo del messaggio. I log visualizzati dovrebbero essere di questo tipo:
```
2023-09-11T22:45:04.271Z 348529ce-2211-4222-9099-59d07d837b60 INFO Processed message test
2023-09-11T22:45:04.288Z 348529ce-2211-4222-9099-59d07d837b60 INFO done
```
## Creazione di una coda Amazon SQS
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sqs_tut_steps4.png)
Creare una coda Amazon SQS che la funzione Lambda può utilizzare come origine eventi. La funzione Lambda e la coda Amazon SQS devono trovarsi nella stessa Regione AWS.
**Come creare una coda**
1. Apri la [console Amazon SQS](https://console.aws.amazon.com/sqs).
1. Scegliere **Crea coda**.
1. Inserisci un nome per la coda. Lascia tutte le altre proprietà sui valori predefiniti.
1. Scegliere **Crea coda**.
Dopo aver creato la coda, prendi nota del suo ARN. Questa operazione è necessaria nella fase successiva quando si associa la coda alla funzione Lambda.
## Configurazione dell'origine eventi
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sqs_tut_steps5.png)
Collega la coda Amazon SQS alla tua funzione Lambda creando una [mappatura dell'origine degli eventi](invocation-eventsourcemapping.md). La mappatura dell'origine degli eventi legge la coda di Amazon SQS e richiama la funzione Lambda quando viene aggiunto un nuovo messaggio.
Per creare una mappatura tra la coda Amazon SQS e la funzione Lambda, usa il comando. [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) AWS CLI Esempio:
```
aws lambda create-event-source-mapping --function-name ProcessSQSRecord --batch-size 10 \
--event-source-arn arn:aws:sqs:us-east-1:111122223333:my-queue
```
Per ottenere un elenco delle mappature delle sorgenti degli eventi, usa il comando. [list-event-source-mappings](https://awscli.amazonaws.com/v2/documentation/api/2.1.29/reference/lambda/list-event-source-mappings.html) Esempio:
```
aws lambda list-event-source-mappings --function-name ProcessSQSRecord
```
## Invio di un messaggio di test
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sqs_tut_steps6.png)
**Invio di un messaggio Amazon SQS alla funzione Lambda**
1. Apri la [console Amazon SQS](https://console.aws.amazon.com/sqs).
1. Scegli la coda creata in precedenza.
1. Scegli **Invia e ricevi messaggi**.
1. Nella sezione **Corpo del messaggio**, inserisci un messaggio di test, ad esempio "questo è un messaggio di prova".
1. Scegliere **Invia messaggio**.
Lambda esegue il polling della coda per gli aggiornamenti. Quando c'è un nuovo messaggio, Lambda richiama la tua funzione con questi nuovi dati di evento dalla coda. Se il gestore della funzione conclude senza eccezioni, Lambda considera il messaggio elaborato correttamente e inizia a leggere nuovi messaggi nella coda. Dopo aver elaborato correttamente un messaggio, Lambda lo elimina automaticamente dalla coda. Se il gestore genera un'eccezione, Lambda considera il batch dei messaggi come non correttamente elaborato e Lambda richiama la funzione con lo stesso batch di messaggi.
## Controlla i log CloudWatch
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sqs_tut_steps7.png)
**Verifica della corretta elaborazione del messaggio da parte della funzione**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegli la SQSRecord funzione **Process**.
1. Scegli **Monitor (Monitoraggio)**.
1. Scegli **Visualizza CloudWatch registri.**
1. Nella CloudWatch console, scegli il **flusso di log** per la funzione.
1. Individua il log `INFO`. È qui che la funzione Lambda registra il corpo del messaggio. Dovresti vedere il messaggio che hai inviato dalla coda Amazon SQS. Esempio:
```
2023-09-11T22:49:12.730Z b0c41e9c-0556-5a8b-af83-43e59efeec71 INFO Processed message this is a test message.
```
## Pulizia delle risorse
Ora è possibile eliminare le risorse create per questo tutorial, a meno che non si voglia conservarle. Eliminando AWS le risorse che non utilizzi più, eviti addebiti inutili a tuo Account AWS carico.
**Come eliminare il ruolo di esecuzione**
1. Aprire la pagina [Ruoli](https://console.aws.amazon.com/iam/home#/roles) della console IAM.
1. Selezionare il ruolo di esecuzione creato.
1. Scegliere **Elimina**.
1. Inserisci il nome del ruolo nel campo di immissione testo e seleziona **Delete** (Elimina).
**Per eliminare la funzione Lambda**
1. Aprire la pagina [Functions (Funzioni)](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Selezionare la funzione creata.
1. Scegliere **Operazioni**, **Elimina**.
1. Digita **confirm** nel campo di immissione testo e scegli **Delete** (Elimina).
**Per eliminare la coda Amazon SQS**
1. Accedi Console di gestione AWS e apri la console Amazon SQS all'indirizzo. [https://console.aws.amazon.com/sqs/](https://console.aws.amazon.com/sqs/)
1. Selezionare la coda creata.
1. Scegli **Elimina**.
1. Inserisci **confirm** nel campo di immissione del testo.
1. Scegli **Delete** (Elimina).
# Tutorial: utilizzo di una coda Amazon SQS tra più account come origine eventi
In questo tutorial, crei una funzione Lambda che consuma i messaggi da una coda Amazon Simple Queue Service (Amazon SQS) in un account diverso. AWS Questo tutorial include due AWS account: l'**account A** si riferisce all'account che contiene la funzione Lambda e l'**account B** si riferisce all'account che contiene la coda Amazon SQS.
## Prerequisiti
### Installa il AWS Command Line Interface
Se non l'hai ancora installato AWS Command Line Interface, segui i passaggi indicati in [Installazione o aggiornamento della versione più recente di AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) per installarlo.
Per eseguire i comandi nel tutorial, sono necessari un terminale a riga di comando o una shell (interprete di comandi). In Linux e macOS, utilizza la shell (interprete di comandi) e il gestore pacchetti preferiti.
**Nota**
Su Windows, alcuni comandi della CLI Bash utilizzati comunemente con Lambda (ad esempio, `zip`) non sono supportati dai terminali integrati del sistema operativo. Per ottenere una versione integrata su Windows di Ubuntu e Bash, [installa il sottosistema Windows per Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
## Creazione del ruolo di esecuzione (account A)
Nell'**Account A**, crea un [ruolo di esecuzione](lambda-intro-execution-role.md) che autorizzi la funzione ad accedere alle AWS risorse richieste.
**Creazione di un ruolo di esecuzione**
1. Apri la [pagina Ruoli](https://console.aws.amazon.com/iam/home#/roles) nella console AWS Identity and Access Management (IAM).
1. Scegliere **Create role** (Crea ruolo).
1. Creare un ruolo con le seguenti proprietà.
+ **Entità attendibile** – **AWS Lambda**
+ **Autorizzazioni**: **AWSLambdaSQSQueueExecutionRole**
+ **Nome ruolo** – **cross-account-lambda-sqs-role**
La **AWSLambdaSQSQueueExecutionRole**policy dispone delle autorizzazioni necessarie alla funzione per leggere elementi da Amazon SQS e scrivere log su Amazon Logs. CloudWatch
## Creazione della funzione (account A)
In **Account A**, crea una funzione Lambda che elabora i messaggi Amazon SQS. La funzione Lambda e la coda Amazon SQS devono trovarsi nella stessa Regione AWS.
Il seguente esempio di codice Node.js scrive ogni messaggio in un log in Logs. CloudWatch
**Example index.mjs**
```
export const handler = async function(event, context) {
event.Records.forEach(record => {
const { body } = record;
console.log(body);
});
return {};
}
```
**Creazione della funzione**
**Nota**
Seguendo questi passaggi viene creata una funzione Node.js. Per le altre lingue i passaggi sono simili, ma alcuni dettagli sono diversi.
1. Salva l'esempio di codice come un file denominato `index.mjs`.
1. Crea un pacchetto di implementazione.
```
zip function.zip index.mjs
```
1. Create la funzione utilizzando il comando `create-function` AWS Command Line Interface (AWS CLI). Sostituisci `arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role` con l'ARN del ruolo di esecuzione creato in precedenza.
```
aws lambda create-function --function-name CrossAccountSQSExample \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--role arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role
```
## Testa la funzione (Account A)
Nell'**Account A**, verifica manualmente la tua funzione Lambda utilizzando il `invoke` AWS CLI comando e un evento Amazon SQS di esempio.
Se il gestore termina normalmente senza eccezioni, Lambda considera il messaggio come elaborato correttamente e inizia a leggere nuovi messaggi nella coda. Dopo aver elaborato correttamente un messaggio, Lambda lo elimina automaticamente dalla coda. Se il gestore genera un'eccezione, Lambda considera il batch dei messaggi come non correttamente elaborato e Lambda richiama la funzione con lo stesso batch di messaggi.
1. Salva il seguente JSON come un file denominato `input.txt`.
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "test",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "098f6bcd4621d373cade4e832627b4f6",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-1:111122223333:example-queue",
"awsRegion": "us-east-1"
}
]
}
```
Il precedente JSON simula un evento che Amazon SQS potrebbe inviare alla tua funzione Lambda, dove `"body"` contiene il messaggio effettivo dalla coda.
1. Eseguire il seguente comando `invoke` AWS CLI .
```
aws lambda invoke --function-name CrossAccountSQSExample \
--cli-binary-format raw-in-base64-out \
--payload file://input.txt outputfile.txt
```
L'**cli-binary-format**opzione è obbligatoria se utilizzi la AWS CLI versione 2. Per rendere questa impostazione come predefinita, esegui `aws configure set cli-binary-format raw-in-base64-out`. Per ulteriori informazioni, consulta la pagina [AWS CLI supported global command line options](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) nella *Guida per l'utente di AWS Command Line Interface versione 2*.
1. Verificare l'output nel file `outputfile.txt`.
## Creazione di una coda Amazon SQS (account B)
In **Account B**, crea una coda Amazon SQS che la funzione Lambda in **Account A** può utilizzare come origine eventi. La funzione Lambda e la coda Amazon SQS devono trovarsi nella stessa Regione AWS.
**Come creare una coda**
1. Apri la [console Amazon SQS](https://console.aws.amazon.com/sqs).
1. Scegliere **Crea coda**.
1. Crea una coda con le seguenti proprietà.
+ **Type (Tipo)**: **Standard**
+ **Nome**: **LambdaCrossAccountQueue**
+ **Configuration (Configurazione)**: mantieni le impostazioni predefinite.
+ **Access policy (Policy di accesso)**: scegli **Advanced (Avanzata)**. Incolla la seguente politica JSON. Sostituisci i valori seguenti:
+ `111122223333`: Account AWS ID per l'**account** A
+ `444455556666`: Account AWS ID per l'**account B**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [
{
"Sid": "Queue1_AllActions",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role"
]
},
"Action": "sqs:*",
"Resource": "arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue"
}
]
}
```
------
Questa policy concede al ruolo di esecuzione Lambda nell'**Account A** le autorizzazioni per utilizzare i messaggi provenienti da questa coda Amazon SQS.
1. Dopo aver creato la coda, registra il suo Amazon Resource Name (ARN). Questa operazione è necessaria nella fase successiva quando si associa la coda alla funzione Lambda.
## Configurazione dell'origine eventi (account A)
Nell'**Account A, crea una** mappatura dell'origine degli eventi tra la coda Amazon SQS **nell'Account** B e la tua funzione Lambda eseguendo il comando seguente. `create-event-source-mapping` AWS CLI Sostituisci `arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue` con l'ARN della coda Amazon SQS creata nel passaggio precedente.
```
aws lambda create-event-source-mapping --function-name CrossAccountSQSExample --batch-size 10 \
--event-source-arn arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue
```
È possibile ottenere un elenco delle mappature delle fonti eventi eseguendo il comando riportato di seguito.
```
aws lambda list-event-source-mappings --function-name CrossAccountSQSExample \
--event-source-arn arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue
```
## Eseguire il test della configurazione
A questo punto è possibile eseguire il test della configurazione come indicato di seguito:
1. Nell'**Account B**, apri [Console Amazon SQS](https://console.aws.amazon.com/sqs).
1. Scegli **LambdaCrossAccountQueue**, che hai creato in precedenza.
1. Scegli **Invia e ricevi messaggi**.
1. In **Corpo del messaggio**, inserisci un messaggio di prova.
1. Scegliere **Send Message** (Invia messaggio).
La funzione Lambda nell'**Account A** dovrebbe ricevere il messaggio. Lambda continuerà a eseguire il polling della coda per gli aggiornamenti. Quando c'è un nuovo messaggio, Lambda richiama la tua funzione con questi nuovi dati di evento dalla coda. La tua funzione viene eseguita e crea registri in Amazon CloudWatch. Puoi visualizzare i log nella [console CloudWatch ](https://console.aws.amazon.com/cloudwatch).
## Pulizia delle risorse
Ora è possibile eliminare le risorse create per questo tutorial, a meno che non si voglia conservarle. Eliminando AWS le risorse che non utilizzi più, eviti addebiti inutili a tuo carico. Account AWS
Nell'**Account A** elimina il ruolo di esecuzione e la funzione Lambda.
**Come eliminare il ruolo di esecuzione**
1. Aprire la pagina [Ruoli](https://console.aws.amazon.com/iam/home#/roles) della console IAM.
1. Selezionare il ruolo di esecuzione creato.
1. Scegliere **Elimina**.
1. Inserisci il nome del ruolo nel campo di immissione testo e seleziona **Delete** (Elimina).
**Per eliminare la funzione Lambda**
1. Aprire la pagina [Functions (Funzioni)](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Selezionare la funzione creata.
1. Scegliere **Operazioni**, **Elimina**.
1. Digita **confirm** nel campo di immissione testo e scegli **Delete** (Elimina).
Nell'**Account B** elimina la coda Amazon SQS.
**Per eliminare la coda Amazon SQS**
1. Accedi Console di gestione AWS e apri la console Amazon SQS all'indirizzo. [https://console.aws.amazon.com/sqs/](https://console.aws.amazon.com/sqs/)
1. Selezionare la coda creata.
1. Scegli **Elimina**.
1. Inserisci **confirm** nel campo di immissione del testo.
1. Scegli **Delete** (Elimina).