First write!
"); responseStream.write("${loremIpsum1}
`); await new Promise(r => setTimeout(r, 1000)); responseStream.write("DONE!
"); responseStream.write(""); responseStream.end(); } ); ``` Voici un exemple de fichier `template.yaml`. Le streaming des réponses pour notre fonction Lambda est configuré à l'aide de la propriété `FunctionUrlConfig`. ``` 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 ``` Généralement, vous pouvez utiliser `sam build` et `sam deploy --guided` pour créer et déployer une application de production. Dans cet exemple, nous allons utiliser un environnement de développement et utiliser la `sam sync` commande pour créer et déployer notre application. **Note** La commande `sam sync` est recommandée pour les environnements de développement. Pour en savoir plus, veuillez consulter la section [Présentation de l'utilisation sam sync de la synchronisation avec AWS Cloud](using-sam-cli-sync.md). Avant de lancer `sam sync`, nous vérifions que notre projet est correctement configuré dans notre fichier `samconfig.toml`. Plus important encore, nous vérifions les valeurs de `stack_name` et `watch`. Ces valeurs étant spécifiées dans notre fichier de configuration, nous n'avons pas à les fournir sur la ligne de commande. ``` 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" ``` Ensuite, nous exécutons `sam sync` pour déployer notre application. Comme l'option `--watch` est configurée dans notre fichier de configuration, la CLI AWS SAM créera notre application, la déploiera et surveillera les modifications. ``` $ 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 ``` Lorsque nous modifions notre code de fonction, la CLI AWS SAM détecte et déploie instantanément nos modifications. Voici un exemple de réponse générée par la CLI AWS SAM après que des modifications ont été apportées à notre code de fonction : ``` 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. ``` Nous pouvons à présent utiliser `sam remote invoke` à nouveau pour interagir avec notre fonction dans le cloud et tester nos modifications. ### Exemples SQS #### Exemples de base **Appelez une file d'attente Amazon SQS en fournissant l'ARN comme ID de ressource :** ``` $ 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 } }% ``` ### Exemples de Step Functions #### Exemples de base **Invoquez une machine à états en fournissant son identifiant physique en tant qu'identifiant de ressource :** Tout d'abord, nous utilisons `sam list resources` pour obtenir notre identifiant physique : ``` $ 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" } ] ``` Ensuite, nous invoquons notre machine à états en utilisant l'identifiant physique comme identifiant de ressource. Nous transmettons un événement en ligne de commande avec l'`--event`option : ``` $ 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"% ``` **Invoquez une machine à états en transmettant un événement vide :** ``` $ sam remote invoke HelloWorldStateMachine --stack-name state-machine-example Invoking Step Function HelloWorldStateMachine "Hello World"% ``` ## Liens connexes Pour la documentation relative à `sam remote invoke` et à l'utilisation du AWS SAMCLI, consultez les rubriques suivantes : + [sam remote invoke](sam-cli-command-reference-remote-invoke.md) + [Résolution des problèmes de la CLI AWS SAM](sam-cli-troubleshooting.md) # Automatisez les tests d'intégration locaux avec AWS SAM Bien que vous puissiez l'utiliser [Présentation des tests avec sam local invoke](using-sam-cli-local-invoke.md) pour tester le code manuellement, il vous permet AWS SAM également de tester votre code à l'aide de tests d'intégration automatisés. Les tests d'intégration vous aident à détecter les problèmes au début du cycle de développement, à améliorer la qualité de votre code et à gagner du temps tout en réduisant les coûts. Pour créer des tests d'intégration automatisés dans AWS SAM, vous devez d'abord exécuter des tests sur des fonctions Lambda locales avant de les déployer dans le AWS Cloud. La [Présentation des tests avec sam local start-lambda](using-sam-cli-local-start-lambda.md) commande démarre un point de terminaison local qui émule le point de terminaison d'appel Lambda. Vous pouvez l'appeler à partir de vos tests automatisés. Comme ce point de terminaison émule le point de terminaison Lambda Invoke, vous pouvez écrire des tests une seule fois, puis les exécuter (sans aucune modification) sur la fonction Lambda locale ou sur une fonction Lambda déployée. Vous pouvez également exécuter les mêmes tests sur une AWS SAM pile déployée dans votre CI/CD pipeline. Voici comment fonctionne le processus : 1. Démarrez le point de terminaison Lambda local. Démarrez le point de terminaison Lambda local en exécutant la commande suivante dans le répertoire contenant votre AWS SAM modèle : ``` sam local start-lambda ``` Cette commande démarre un point de terminaison local sur `http://127.0.0.1:3001` qui émule AWS Lambda. Vous pouvez exécuter des tests automatisés par rapport à ce point de terminaison Lambda local. Lorsque vous appelez ce point de terminaison à l'aide du SDK AWS CLI ou, il exécute localement la fonction Lambda spécifiée dans la demande et renvoie une réponse. 1. Exécutez un test d'intégration sur le point de terminaison Lambda local. Lors de votre test d'intégration, vous pouvez utiliser le AWS SDK pour appeler votre fonction Lambda avec les données de test, attendre une réponse et vérifier que la réponse est conforme à vos attentes. Pour exécuter le test d'intégration en local, vous devez configurer le SDK AWS pour envoyer l'appel d'API de Lambda au point de terminaison Lambda local démarré à l'étape précédente. Voici un exemple en Python (les quatre AWS SDKs autres langages ont des configurations similaires) : ``` 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" ``` Vous pouvez utiliser ce code pour tester les fonctions Lambda déployées en définissant `running_locally` sur `False`. Cela permet de configurer le AWS SDK auquel se connecter AWS Lambda dans le AWS cloud. # Générez des exemples de charges utiles d'événements avec AWS SAM Pour tester vos fonctions Lambda, vous pouvez générer et personnaliser des exemples de charges utiles d'événements qui imitent les données que vos fonctions Lambda recevront lorsqu'elles seront déclenchées par d'autres services. AWS Cela inclut des services tels que API Gateway CloudFormation, Amazon S3, etc. La génération d'exemples de charges utiles d'événements vous permet de tester le comportement de votre fonction Lambda à l'aide de différentes entrées sans avoir à travailler dans un environnement réel. Cette approche permet également de gagner du temps par rapport à la création manuelle d'échantillons d'événements de AWS service pour tester les fonctions. Pour obtenir la liste complète des services pour lesquels vous pouvez générer des exemples de charges utiles d'événements, utilisez la commande suivante : ``` sam local generate-event --help ``` Pour obtenir la liste des options que vous pouvez utiliser pour un service particulier, utilisez la commande suivante : ``` sam local generate-event [SERVICE] --help ``` Exemples : ``` #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 ``` # Tester et déboguer des fonctions durables Le test et le débogage de fonctions durables en local fonctionnent de la même manière que les fonctions Lambda classiques, avec une prise en charge automatique du point de contrôle et de la rediffusion. Ce guide couvre les scénarios de test courants et les techniques de dépannage. ## Flux de travail de test local Lorsque vous testez des fonctions durables localement, le flux de travail diffère des fonctions Lambda classiques : **Flux de travail de test de fonctionnement durable** 1. Créez votre application : ``` $ sam build ``` 1. Invoquez votre fonction durable : ``` $ sam local invoke MyDurableFunction --durable-execution-name test ``` 1. Vérifiez l'historique des exécutions si nécessaire : ``` $ sam local execution history execution-id ``` ## Scénarios de test courants ### Tester le comportement des points de contrôle Pour vérifier que votre fonction fonctionne correctement, les points de contrôle indiquent : ``` # 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"} ``` Lorsque vous appelez cette fonction localement, le délai d'attente est géré automatiquement. ### Tester des scénarios de rappel Pour les fonctions qui attendent des rappels externes : 1. Démarrez votre fonction durable qui attend un rappel 1. Dans un autre terminal, résolvez le rappel : ``` $ sam local callback succeed callback-id ``` 1. Observez l'exécution de la fonction reprendre ## Résolution des problèmes ### La fonction durable ne s'exécute pas correctement **Problème :** La fonction ne se comporte pas comme une fonction durable. **Solutions :** + Vérifiez que cela `DurableConfig` est défini dans votre modèle SAM + Assurez-vous que votre code de fonction utilise des méthodes durables du SDK de fonctions (par exemple,`context.wait()`) + Vérifiez que vous utilisez un environnement d'exécution compatible (TypeScript, JavaScript, Python) ### Impossible de récupérer l'historique des exécutions **Problème :** La `local execution history` commande ne renvoie aucun résultat. **Solutions :** + Vérifiez que l'ID d'exécution est correct + Vérifiez que la fonction a été invoquée au moins une fois ### Les commandes de rappel ne fonctionnent pas **Problème :** les commandes de rappel ne résolvent pas les opérations en attente. **Solutions :** + Vérifiez que l'identifiant de rappel est correct + Assurez-vous que la fonction attend réellement un rappel + Vérifiez que vous utilisez la bonne syntaxe de commande de rappel ## Conseils de débogage + **Utiliser l'historique des exécutions** : passez en revue l'historique des exécutions pour comprendre le flux de votre fonction durable + **Testez de manière incrémentielle** : commencez par de simples opérations d'attente avant d'ajouter une logique complexe + **Utiliser la journalisation détaillée - Activez la journalisation** détaillée pour suivre le flux d'exécution ## En savoir plus Pour plus d'informations sur les tests et le débogage, voir : + [Présentation des tests avec sam local invoke](using-sam-cli-local-invoke.md)- Documentation d'appel local + [sam local execution history](sam-cli-command-reference-sam-local-execution-history.md)- Historique d'exécution