First write!
"); responseStream.write("${loremIpsum1}
`); await new Promise(r => setTimeout(r, 1000)); responseStream.write("DONE!
"); responseStream.write(""); responseStream.end(); } ); ``` Di seguito è riportato un esempio del nostro `template.yaml` file. Lo streaming di risposta per la nostra funzione Lambda è configurato utilizzando la `FunctionUrlConfig` proprietà. ``` AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: > Sample SAM Template for lambda-streaming-nodejs-app Resources: StreamingFunction: Type: AWS::Serverless::Function Properties: CodeUri: src/ Handler: index.handler Runtime: nodejs18.x Architectures: - x86_64 Timeout: 10 FunctionUrlConfig: AuthType: AWS_IAM InvokeMode: RESPONSE_STREAM Outputs: StreamingFunction: Description: "Streaming Lambda Function ARN" Value: !GetAtt StreamingFunction.Arn StreamingFunctionURL: Description: "Streaming Lambda Function URL" Value: !GetAtt StreamingFunctionUrl.FunctionUrl ``` In genere, è possibile utilizzare `sam build` e `sam deploy --guided` creare e distribuire un'applicazione di produzione. In questo esempio, assumeremo un ambiente di sviluppo e utilizzeremo il `sam sync` comando per creare e distribuire la nostra applicazione. **Nota** Il `sam sync` comando è consigliato per ambienti di sviluppo. Per ulteriori informazioni, consulta [Introduzione all'uso sam sync della sincronizzazione con Cloud AWS](using-sam-cli-sync.md). Prima dell'esecuzione`sam sync`, verifichiamo che il nostro progetto sia configurato correttamente nel nostro `samconfig.toml` file. Soprattutto, verifichiamo i valori di `stack_name` e`watch`. Con questi valori specificati nel nostro file di configurazione, non è necessario fornirli nella riga di comando. ``` version = 0.1 [default] [default.global.parameters] stack_name = "lambda-streaming-nodejs-app" [default.build.parameters] cached = true parallel = true [default.validate.parameters] lint = true [default.deploy.parameters] capabilities = "CAPABILITY_IAM" confirm_changeset = true resolve_s3 = true s3_prefix = "lambda-streaming-nodejs-app" region = "us-west-2" image_repositories = [] [default.package.parameters] resolve_s3 = true [default.sync.parameters] watch = true [default.local_start_api.parameters] warm_containers = "EAGER" [default.local_start_lambda.parameters] warm_containers = "EAGER" ``` Successivamente, eseguiamo `sam sync` la creazione e la distribuzione della nostra applicazione. Poiché l'`--watch`opzione è configurata nel nostro file di configurazione, AWS SAMCLI creerà la nostra applicazione, distribuirà la nostra applicazione e controllerà le modifiche. ``` $ sam sync The SAM CLI will use the AWS Lambda, Amazon API Gateway, and AWS StepFunctions APIs to upload your code without performing a CloudFormation deployment. This will cause drift in your CloudFormation stack. **The sync command should only be used against a development stack**. Queued infra sync. Waiting for in progress code syncs to complete... Starting infra sync. Building codeuri: /Users/.../lambda-streaming-nodejs-app/src runtime: nodejs18.x metadata: {} architecture: x86_64 functions: StreamingFunction package.json file not found. Continuing the build without dependencies. Running NodejsNpmBuilder:CopySource Build Succeeded Successfully packaged artifacts and wrote output template to file /var/folders/45/5ct135bx3fn2551_ptl5g6_80000gr/T/tmpavrzdhgp. Execute the following command to deploy the packaged template sam deploy --template-file /var/folders/45/5ct135bx3fn2551_ptl5g6_80000gr/T/tmpavrzdhgp --stack-nameFirst write!
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque vitae mi tincidunt tellus ultricies dignissim id et diam. Morbi pharetra eu nisi et finibus. Vivamus diam nulla, vulputate et nisl cursus, pellentesque vehicula libero. Cras imperdiet lorem ante, non posuere dolor sollicitudin a. Vestibulum ipsum lacus, blandit nec augue id, lobortis dictum urna. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia curae; Morbi auctor orci eget tellus aliquam, non maximus massa porta. In diam ante, pulvinar aliquam nisl non, elementum hendrerit sapien. Vestibulum massa nunc, mattis non congue vitae, placerat in quam. Nam vulputate lectus metus, et dignissim erat varius a.
DONE!
START RequestId: 1e4cdf04-60de-4769-b3a2-c1481982deb4 Version: $LATEST END RequestId: 1e4cdf04-60de-4769-b3a2-c1481982deb4 REPORT RequestId: 1e4cdf04-60de-4769-b3a2-c1481982deb4 Duration: 4088.66 ms Billed Duration: 4089 ms Memory Size: 128 MB Max Memory Used: 68 MB Init Duration: 168.45 ms ``` Quando modifichiamo il codice della nostra funzione, rileva e AWS SAMCLI implementa immediatamente le nostre modifiche. Ecco un esempio dell' AWS SAMCLIoutput dopo aver apportato modifiche al nostro codice di funzione: ``` Syncing Lambda Function StreamingFunction... Building codeuri: /Users/.../lambda-streaming-nodejs-app/src runtime: nodejs18.x metadata: {} architecture: x86_64 functions: StreamingFunction package.json file not found. Continuing the build without dependencies. Running NodejsNpmBuilder:CopySource Finished syncing Lambda Function StreamingFunction. Syncing Layer StreamingFunctione9cfe924DepLayer... SyncFlow [Layer StreamingFunctione9cfe924DepLayer]: Skipping resource update as the content didn't change Finished syncing Layer StreamingFunctione9cfe924DepLayer. ``` Ora possiamo `sam remote invoke` riutilizzarlo per interagire con la nostra funzione nel cloud e testare le nostre modifiche. ### Esempi SQS #### Esempi di base **Richiama una coda Amazon SQS fornendo l'ARN come ID di risorsa:** ``` $ sam remote invoke arn:aws:sqs:us-west-2:01234567890:sqs-example-4DonhBsjsW1b --event '{"hello": "world"}' --output json Sending message to SQS queue MySqsQueue { "MD5OfMessageBody": "49dfdd54b01cbcd2d2ab5e9e5ee6b9b9", "MessageId": "4f464cdd-15ef-4b57-bd72-3ad225d80adc", "ResponseMetadata": { "RequestId": "95d39377-8323-5ef0-9223-ceb198bd09bd", "HTTPStatusCode": 200, "HTTPHeaders": { "x-amzn-requestid": "95d39377-8323-5ef0-9223-ceb198bd09bd", "date": "Wed, 08 Nov 2023 23:27:26 GMT", "content-type": "application/x-amz-json-1.0", "content-length": "106", "connection": "keep-alive" }, "RetryAttempts": 0 } }% ``` ### Esempi di Step Functions #### Esempi di base **Richiama una macchina a stati fornendo il suo ID fisico come ID di risorsa:** Innanzitutto, `sam list resources` per ottenere il nostro ID fisico, utilizziamo: ``` $ sam list resources --stack-name state-machine-example --output json [ { "LogicalResourceId": "HelloWorldStateMachine", "PhysicalResourceId": "arn:aws:states:us-west-2:513423067560:stateMachine:HelloWorldStateMachine-z69tFEUx0F66" }, { "LogicalResourceId": "HelloWorldStateMachineRole", "PhysicalResourceId": "simple-state-machine-HelloWorldStateMachineRole-PduA0BDGuFXw" } ] ``` Successivamente, invochiamo la nostra macchina a stati utilizzando l'ID fisico come ID di risorsa. Passiamo un evento alla riga di comando con l'`--event`opzione: ``` $ sam remote invoke arn:aws:states:us-west-2:01234567890:stateMachine:HelloWorldStateMachine-z69tFEUx0F66 --event '{"is_developer": true}' Invoking Step Function arn:aws:states:us-west-2:01234567890:stateMachine:HelloWorldStateMachine-z69tFEUx0F66 "Hello Developer World"% ``` **Invoca una macchina a stati passando un evento vuoto:** ``` $ sam remote invoke HelloWorldStateMachine --stack-name state-machine-example Invoking Step Function HelloWorldStateMachine "Hello World"% ``` ## Link correlati Per la documentazione relativa `sam remote invoke` e all'utilizzo di AWS SAMCLI, vedere quanto segue: + [sam remote invoke](sam-cli-command-reference-remote-invoke.md) + [AWS SAMCLIrisoluzione dei problemi](sam-cli-troubleshooting.md) # Automatizza i test di integrazione locali con AWS SAM Sebbene sia possibile utilizzarlo [Introduzione ai test con sam local invoke](using-sam-cli-local-invoke.md) per testare manualmente il codice, consente AWS SAM anche di testarlo utilizzando test di integrazione automatizzati. I test di integrazione consentono di rilevare i problemi nelle prime fasi del ciclo di sviluppo, migliorare la qualità del codice e risparmiare tempo riducendo al contempo i costi. Per creare test di integrazione automatizzati AWS SAM, devi prima eseguire test sulle funzioni Lambda locali prima di distribuirli nel Cloud. AWS Il [Introduzione ai test con sam local start-lambda](using-sam-cli-local-start-lambda.md) comando avvia un endpoint locale che emula l'endpoint Invoke Lambda. Puoi richiamarlo dai tuoi test automatici. Poiché questo endpoint emula l'endpoint Lambda invoke, puoi scrivere i test una volta e poi eseguirli (senza alcuna modifica) sulla funzione Lambda locale o su una funzione Lambda distribuita. Puoi anche eseguire gli stessi test su uno stack distribuito nella tua pipeline. AWS SAM CI/CD Ecco come funziona il processo: 1. Avvia l'endpoint Lambda locale. Avvia l'endpoint Lambda locale eseguendo il seguente comando nella directory che contiene il modello: AWS SAM ``` sam local start-lambda ``` Questo comando avvia un endpoint locale in cui viene emulato`http://127.0.0.1:3001`. AWS Lambda Puoi eseguire test automatici su questo endpoint Lambda locale. Quando richiami questo endpoint utilizzando AWS CLI o SDK, esegue localmente la funzione Lambda specificata nella richiesta e restituisce una risposta. 1. Esegui un test di integrazione sull'endpoint Lambda locale. Nel test di integrazione, puoi utilizzare l' AWS SDK per richiamare la funzione Lambda con i dati di test, attendere la risposta e verificare che la risposta sia quella prevista. Per eseguire il test di integrazione localmente, devi configurare l' AWS SDK per inviare una chiamata API Lambda Invoke per richiamare l'endpoint Lambda locale avviato nel passaggio precedente. Quello che segue è un esempio di Python (i quattro AWS SDKs linguaggi hanno configurazioni simili): ``` import boto3 import botocore # Set "running_locally" flag if you are running the integration test locally running_locally = True if running_locally: # Create Lambda SDK client to connect to appropriate Lambda endpoint lambda_client = boto3.client('lambda', region_name="us-west-2", endpoint_url="http://127.0.0.1:3001", use_ssl=False, verify=False, config=botocore.client.Config( signature_version=botocore.UNSIGNED, read_timeout=15, retries={'max_attempts': 0}, ) ) else: lambda_client = boto3.client('lambda') # Invoke your Lambda function as you normally usually do. The function will run # locally if it is configured to do so response = lambda_client.invoke(FunctionName="HelloWorldFunction") # Verify the response assert response == "Hello World" ``` È possibile utilizzare questo codice per testare le funzioni Lambda distribuite impostando su`running_locally`. `False` Questo configura l' AWS SDK a cui connettersi AWS Lambda nel cloud. AWS # Genera payload di eventi di esempio con AWS SAM Per testare le tue funzioni Lambda, puoi generare e personalizzare payload di eventi di esempio che imitano i dati che le tue funzioni Lambda riceveranno quando vengono attivate da altri servizi. AWS Ciò include servizi come API Gateway CloudFormation, Amazon S3 e altro ancora. La generazione di payload di eventi di esempio consente di testare il comportamento della funzione Lambda con una varietà di input diversi senza dover lavorare in un ambiente live. Questo approccio consente inoltre di risparmiare tempo rispetto alla creazione manuale di esempi di eventi di AWS servizio per testare le funzioni. Per l'elenco completo dei servizi per i quali è possibile generare payload di eventi di esempio, utilizzate questo comando: ``` sam local generate-event --help ``` Per l'elenco delle opzioni che puoi usare per un particolare servizio, usa questo comando: ``` sam local generate-event [SERVICE] --help ``` Esempi: ``` #Generates the event from S3 when a new object is created sam local generate-event s3 put # Generates the event from S3 when an object is deleted sam local generate-event s3 delete ``` # Test e debug di funzioni durevoli Il test e il debug delle funzioni durevoli a livello locale funzionano in modo simile alle normali funzioni Lambda, con supporto automatico per checkpoint e replay. Questa guida illustra gli scenari di test e le tecniche di risoluzione dei problemi più comuni. ## Flusso di lavoro di test locale Quando si testano funzioni durevoli a livello locale, il flusso di lavoro è diverso dalle normali funzioni Lambda: **Flusso di lavoro durevole per la verifica** 1. Crea la tua applicazione: ``` $ sam build ``` 1. Invoca la tua funzione duratura: ``` $ sam local invoke MyDurableFunction --durable-execution-name test ``` 1. Controlla la cronologia delle esecuzioni, se necessario: ``` $ sam local execution history execution-id ``` ## Scenari di test comuni ### Test del comportamento dei checkpoint Per verificare che la tua funzione funzioni correttamente, i checkpoint indicano: ``` # Example Python durable function def handler(event, context): # This will create a checkpoint context.wait(10) # Wait 10 seconds # Function resumes here after wait return {"message": "Function resumed after wait"} ``` Quando si richiama questa funzione localmente, il periodo di attesa viene gestito automaticamente. ### Scenari di callback di test Per le funzioni che attendono callback esterni: 1. Avvia la tua funzione duratura che attende una richiamata 1. In un altro terminale, risolvi il callback: ``` $ sam local callback succeed callback-id ``` 1. Osserva che la funzione riprende l'esecuzione ## Risoluzione dei problemi ### Funzione durevole che non viene eseguita correttamente **Problema:** la funzione non si comporta come una funzione durevole. **Soluzioni:** + Verifica che `DurableConfig` sia impostato nel tuo modello SAM + Assicurati che il codice della funzione utilizzi metodi SDK per funzioni durevoli (ad esempio,`context.wait()`) + Verifica di utilizzare un runtime supportato (TypeScript, JavaScript, Python) ### Impossibile recuperare la cronologia delle esecuzioni **Problema:** il `local execution history` comando non restituisce risultati. **Soluzioni:** + Verifica che l'ID di esecuzione sia corretto + Verifica che la funzione sia stata richiamata almeno una volta ### I comandi di callback non funzionano **Problema:** i comandi di callback non risolvono le operazioni in sospeso. **Soluzioni:** + Verifica che l'ID di callback sia corretto + Assicurati che la funzione sia effettivamente in attesa di una richiamata + Verifica di utilizzare la sintassi corretta del comando di callback ## Suggerimenti per il debug + **Usa la cronologia di esecuzione**: esamina la cronologia delle esecuzioni per comprendere il flusso della tua funzione duratura + **Esegui test in modo incrementale**: inizia con semplici operazioni di attesa prima di aggiungere una logica complessa + **Usa la registrazione dettagliata: abilita la registrazione** dettagliata per tracciare il flusso di esecuzione ## Ulteriori informazioni Per ulteriori informazioni su test e debug, consulta: + [Introduzione ai test con sam local invoke](using-sam-cli-local-invoke.md)- Documentazione locale sulle invoke + [sam local execution history](sam-cli-command-reference-sam-local-execution-history.md)- Cronologia delle esecuzioni