Configuration de votre projet de gestionnaire Java Exemple de code de fonction Java Lambda Définitions de classe valides pour les gestionnaires Java Convention de nommage du gestionnaire Définition et accès à l’objet d’événement d’entrée Accès et utilisation de l’objet de contexte Lambda Utilisation du AWS SDK pour Java v2 dans votre gestionnaire Accès aux variables d’environnement Utilisation de l'état global Pratiques exemplaires en matière de code pour les fonctions Lambda Java

Définition du gestionnaire de fonction Lambda dans Java

Le gestionnaire de fonction Lambda est la méthode dans votre code de fonction qui traite les événements. Lorsque votre fonction est invoquée, Lambda exécute la méthode du gestionnaire. Votre fonction s’exécute jusqu’à ce que le gestionnaire renvoie une réponse, se ferme ou expire.

Cette page explique comment utiliser les gestionnaires de fonctions Lambda en Java, notamment les options de configuration du projet, les conventions de dénomination et les meilleures pratiques. Cette page inclut également un exemple de fonction Java Lambda qui collecte des informations relatives à une commande, produit un reçu sous forme de fichier texte et place ce fichier dans un bucket Amazon Simple Storage Service (S3). Pour plus d’informations sur le déploiement de votre fonction après l’avoir écrite, consultez Déployer des fonctions Lambda en Java avec des archives de fichiers .zip ou JAR ou Déployer des fonctions Lambda en Java avec des images conteneurs.

Sections

Configuration de votre projet de gestionnaire Java
Exemple de code de fonction Java Lambda
Définitions de classe valides pour les gestionnaires Java
Convention de nommage du gestionnaire
Définition et accès à l’objet d’événement d’entrée
Accès et utilisation de l’objet de contexte Lambda
Utilisation du AWS SDK pour Java v2 dans votre gestionnaire
Accès aux variables d’environnement
Utilisation de l'état global
Pratiques exemplaires en matière de code pour les fonctions Lambda Java

Configuration de votre projet de gestionnaire Java

Lorsque vous utilisez des fonctions Lambda en Java, le processus consiste à écrire votre code, à le compiler et à déployer les artefacts compilés sur Lambda. Vous pouvez initialiser un projet Java Lambda de différentes manières. Par exemple, vous pouvez utiliser des outils tels que l'archétype Maven pour les fonctions Lambda, la commande AWS SAM CLI sam init ou même une configuration de projet Java standard dans votre IDE préféré, tel qu'IntelliJ IDEA ou Visual Studio Code. Vous pouvez également créer manuellement la structure de fichier requise.

Un projet de fonction Java Lambda typique suit cette structure générale :


/project-root
    └ src
        └ main
            └ java
                └ example
                    └ OrderHandler.java (contains main handler)
                    └ <other_supporting_classes>
     └ build.gradle OR pom.xml

Vous pouvez utiliser Maven ou Gradle pour créer votre projet et gérer les dépendances.

La logique de gestion principale de votre fonction réside dans un fichier Java situé sous le src/main/java/example répertoire. Dans l'exemple de cette page, nous nommons ce fichierOrderHandler.java. Outre ce fichier, vous pouvez inclure des classes Java supplémentaires selon vos besoins. Lorsque vous déployez votre fonction sur Lambda, assurez-vous de spécifier la classe Java qui contient la méthode de gestion principale que Lambda doit invoquer lors d'un appel.

Exemple de code de fonction Java Lambda

L'exemple de code de fonction Lambda Java 21 suivant prend en compte les informations relatives à une commande, produit un reçu sous forme de fichier texte et place ce fichier dans un compartiment Amazon S3.

Exemple Fonction Lambda `OrderHandler.java`


package example;

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import software.amazon.awssdk.core.sync.RequestBody;
import software.amazon.awssdk.services.s3.S3Client;
import software.amazon.awssdk.services.s3.model.PutObjectRequest;
import software.amazon.awssdk.services.s3.model.S3Exception;

import java.nio.charset.StandardCharsets;

/**
 * Lambda handler for processing orders and storing receipts in S3.
 */
public class OrderHandler implements RequestHandler<OrderHandler.Order, String> {

    private static final S3Client S3_CLIENT = S3Client.builder().build();

    /**
     * Record to model the input event.
     */
    public record Order(String orderId, double amount, String item) {}

    @Override
    public String handleRequest(Order event, Context context) {
        try {
            // Access environment variables
            String bucketName = System.getenv("RECEIPT_BUCKET");
            if (bucketName == null || bucketName.isEmpty()) {
                throw new IllegalArgumentException("RECEIPT_BUCKET environment variable is not set");
            }

            // Create the receipt content and key destination
            String receiptContent = String.format("OrderID: %s\nAmount: $%.2f\nItem: %s",
                    event.orderId(), event.amount(), event.item());
            String key = "receipts/" + event.orderId() + ".txt";

            // Upload the receipt to S3
            uploadReceiptToS3(bucketName, key, receiptContent);

            context.getLogger().log("Successfully processed order " + event.orderId() +
                    " and stored receipt in S3 bucket " + bucketName);
            return "Success";

        } catch (Exception e) {
            context.getLogger().log("Failed to process order: " + e.getMessage());
            throw new RuntimeException(e);
        }
    }

    private void uploadReceiptToS3(String bucketName, String key, String receiptContent) {
        try {
            PutObjectRequest putObjectRequest = PutObjectRequest.builder()
                    .bucket(bucketName)
                    .key(key)
                    .build();

            // Convert the receipt content to bytes and upload to S3
            S3_CLIENT.putObject(putObjectRequest, RequestBody.fromBytes(receiptContent.getBytes(StandardCharsets.UTF_8)));
        } catch (S3Exception e) {
            throw new RuntimeException("Failed to upload receipt to S3: " + e.awsErrorDetails().errorMessage(), e);
        }
    }
}

Ce fichier OrderHandler.java comprend les sections suivantes :

package example: En Java, cela peut être n'importe quoi, mais cela doit correspondre à la structure de répertoire de votre projet. Ici, nous utilisons package example parce que la structure du répertoire estsrc/main/java/example.
importinstructions : utilisez-les pour importer les classes Java requises par votre fonction Lambda.
public class OrderHandler ...: Cela définit votre classe Java et doit être une définition de classe valide.
private static final S3Client S3_CLIENT ...: Cela initialise un client S3 en dehors de l'une des méthodes de la classe. Cela oblige Lambda à exécuter ce code pendant la phase d'initialisation.
public record Order ...: Définissez la forme de l'événement d'entrée attendu dans cet enregistrement Java personnalisé.
public String handleRequest(Order event, Context context) : il s’agit de la méthode de gestion principale, qui contient la logique principale de votre application.
private void uploadReceiptToS3(...) {} : il s’agit d’une méthode auxiliaire référencée par la méthode de gestion principale handleRequest.

Le pom.xml fichier build.gradle ou suivant accompagne cette fonction.

build.gradle


plugins {
    id 'java'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'com.amazonaws:aws-lambda-java-core:1.2.3'
    implementation 'software.amazon.awssdk:s3:2.28.29'
    implementation 'org.slf4j:slf4j-nop:2.0.16'
}

task buildZip(type: Zip) {
    from compileJava
    from processResources
    into('lib') {
        from configurations.runtimeClasspath
    }
}

java {
    sourceCompatibility = JavaVersion.VERSION_21
    targetCompatibility = JavaVersion.VERSION_21
}

build.dependsOn buildZip

pom.xml


<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>example-java</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>example-java-function</name>
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.compiler.source>21</maven.compiler.source>
        <maven.compiler.target>21</maven.compiler.target>
    </properties>
    <dependencies>
        <dependency>
            <groupId>com.amazonaws</groupId>
            <artifactId>aws-lambda-java-core</artifactId>
            <version>1.2.3</version>
        </dependency>
        <dependency>
            <groupId>software.amazon.awssdk</groupId>
            <artifactId>s3</artifactId>
            <version>2.28.29</version>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-nop</artifactId>
            <version>2.0.16</version>
        </dependency>
    </dependencies>
    
    <build>
        <plugins>
            <plugin>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>3.5.2</version>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-shade-plugin</artifactId>
                <version>3.4.1</version>
                <configuration>
                    <createDependencyReducedPom>false</createDependencyReducedPom>
                    <filters>
                        <filter>
                            <artifact>*:*</artifact>
                            <excludes>
                                <exclude>META-INF/*</exclude>
                                <exclude>META-INF/versions/**</exclude>
                            </excludes>
                        </filter>
                    </filters>
                </configuration>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>shade</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.13.0</version>
                <configuration>
                    <release>21</release>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

Pour que cette fonction fonctionne correctement, son rôle d'exécution doit autoriser l's3:PutObjectaction. Assurez-vous également de définir la variable d’environnement RECEIPT_BUCKET. Après une invocation réussie, le compartiment Amazon S3 doit contenir un fichier de reçu.

Note

Cette fonction peut nécessiter des paramètres de configuration supplémentaires pour s'exécuter correctement sans expiration du délai imparti. Nous recommandons de configurer 256 Mo de mémoire et un délai d'attente de 10 secondes. La première invocation peut prendre plus de temps en raison d'un démarrage à froid. Les appels suivants devraient s'exécuter beaucoup plus rapidement en raison de la réutilisation de l'environnement d'exécution.

Définitions de classe valides pour les gestionnaires Java

Pour définir votre classe, la aws-lambda-java-corebibliothèque définit deux interfaces pour les méthodes de gestion. Utilisez les interfaces fournies pour simplifier la configuration du gestionnaire et valider la signature de la méthode au moment de la compilation.

L’interface RequestHandler est un type générique qui prend deux paramètres : le type d’entrée et le type de sortie. Les deux types doivent être des objets. Dans cet exemple, notre OrderHandler classe implémenteRequestHandler<OrderHandler.Order, String>. Le type d'entrée est l'Orderenregistrement que nous définissons au sein de la classe, et le type de sortie estString.


public class OrderHandler implements RequestHandler<OrderHandler.Order, String> {
    ...
}

Lorsque vous utilisez cette interface, le moteur d'exécution Java désérialise l'événement dans l'objet avec le type d'entrée et sérialise la sortie sous forme de texte. Utilisez cette interface lorsque la sérialisation intégrée fonctionne avec vos types d’entrée et de sortie.

Pour utiliser votre propre sérialisation, vous pouvez implémenter l'RequestStreamHandlerinterface. Avec cette interface, Lambda transmet à votre gestionnaire un flux d’entrée et un flux de sortie. Le gestionnaire lit les octets du flux d’entrée, écrit dans le flux de sortie et renvoie une valeur vide. Pour un exemple d'utilisation de l'environnement d'exécution Java 21, consultez HandlerStream.java.

Si vous travaillez uniquement avec des types de base et génériques (c'est-à-dire String Integer=List, ouMap) dans votre fonction Java, vous n'avez pas besoin d'implémenter d'interface. Par exemple, si votre fonction prend une Map<String, String> entrée et renvoie unString, votre définition de classe et votre signature de gestionnaire peuvent ressembler à ce qui suit :


public class ExampleHandler {
    public String handleRequest(Map<String, String> input, Context context) {
        ...
    }
}

De plus, lorsque vous n'implémentez pas d'interface, l'objet de contexte est facultatif. Par exemple, votre définition de classe et votre signature de gestionnaire peuvent ressembler à ce qui suit :


public class NoContextHandler {
   public String handleRequest(Map<String, String> input) {
        ...
   }
}

Convention de nommage du gestionnaire

Pour les fonctions Lambda en Java, si vous implémentez l'RequestStreamHandlerinterface RequestHandler ou, votre méthode de gestion principale doit être nommée. handleRequest Incluez également le @Override tag au-dessus de votre handleRequest méthode. Lorsque vous déployez votre fonction sur Lambda, spécifiez le gestionnaire principal dans la configuration de votre fonction au format suivant :

<package>. <Class>— Par exemple,example.OrderHandler.

Pour les fonctions Lambda en Java qui n'implémentent pas l'RequestStreamHandlerinterface RequestHandler or, vous pouvez utiliser n'importe quel nom pour le gestionnaire. Lorsque vous déployez votre fonction sur Lambda, spécifiez le gestionnaire principal dans la configuration de votre fonction au format suivant :

<package>. <Class>: : <handler_method_name> — Par exemple,example.Handler::mainHandler.

Définition et accès à l’objet d’événement d’entrée

JSON est le format d’entrée le plus courant et standard pour les fonctions Lambda. Dans cet exemple, la fonction exige une entrée similaire à l’exemple suivant :


{
    "orderId": "12345",
    "amount": 199.99,
    "item": "Wireless Headphones"
}

Lorsque vous utilisez des fonctions Lambda dans Java 17 ou version ultérieure, vous pouvez définir la forme de l'événement d'entrée attendu sous la forme d'un enregistrement Java. Dans cet exemple, nous définissons un enregistrement au sein de la OrderHandler classe pour représenter un Order objet :


public record Order(String orderId, double amount, String item) {}

Cet enregistrement correspond à la forme d'entrée attendue. Après avoir défini votre enregistrement, vous pouvez écrire une signature de gestionnaire qui prend en compte une entrée JSON conforme à la définition de l'enregistrement. Le moteur d'exécution Java désérialise automatiquement ce JSON en un objet Java. Vous pouvez ensuite accéder aux champs de l'objet. Par exemple, event.orderId récupère la valeur de orderId à partir de l’entrée d’origine.

Note

Les enregistrements Java sont une fonctionnalité des environnements d'exécution Java 17 et des versions plus récentes uniquement. Dans toutes les exécutions Java, vous pouvez utiliser une classe pour représenter les données des événements. Dans de tels cas, vous pouvez utiliser une bibliothèque comme Jackson pour désérialiser les entrées JSON.

Autres types d'événements d'entrée

Il existe de nombreux événements d'entrée possibles pour les fonctions Lambda en Java :

Integer, Long, Double, etc. – L’événement est un nombre sans mise en forme supplémentaire, par exemple, 3.5. Le moteur d'exécution Java convertit la valeur en un objet du type spécifié.
String – L’événement est une chaîne JSON incluant des guillemets, par exemple, “My string”. Le moteur d'exécution convertit la valeur en un String objet sans guillemets.
List<Integer>, List<String>, List<Object>, etc. – L’événement est un tableau JSON. Le moteur d’exécution le désérialise en un objet du type ou de l’interface spécifié.
InputStream – L’événement a un type JSON quelconque. Le moteur d’exécution transmet un flux d’octets du document au gestionnaire sans modification. Vous désérialisez l’entrée et écrivez la sortie dans un flux de sortie.
Type de bibliothèque : pour les événements envoyés par d'autres AWS services, utilisez les types de la aws-lambda-java-eventsbibliothèque. Par exemple, si votre fonction Lambda est invoquée par Amazon Simple Queue Service (SQS), utilisez SQSEvent l'objet comme entrée.

Accès et utilisation de l’objet de contexte Lambda

L’objet de contexte Lambda contient des informations sur l’invocation, la fonction et l’environnement d’exécution. Dans cet exemple, l'objet de contexte est de type com.amazonaws.services.lambda.runtime.Context et constitue le deuxième argument de la fonction de gestion principale.


public String handleRequest(Order event, Context context) {
    ...
}

Si votre classe implémente l' RequestStreamHandlerinterface RequestHandlerou, l'objet de contexte est un argument obligatoire. Dans le cas contraire, l'objet de contexte est facultatif. Pour plus d'informations sur les signatures de gestionnaires acceptées valides, consultezDéfinitions de classe valides pour les gestionnaires Java.

Si vous appelez d'autres services à l'aide du AWS SDK, l'objet de contexte est requis dans quelques domaines clés. Par exemple, pour produire des journaux de fonctions pour Amazon CloudWatch, vous pouvez utiliser context.getLogger() cette méthode pour obtenir un LambdaLogger objet à enregistrer. Dans cet exemple, nous pouvons utiliser l'enregistreur pour enregistrer un message d'erreur si le traitement échoue pour une raison quelconque :


context.getLogger().log("Failed to process order: " + e.getMessage());

En dehors de la journalisation, vous pouvez également utiliser l'objet de contexte pour surveiller les fonctions. Pour plus d’informations sur la copie d’objets, consultez Utilisation de l’objet de contexte Lambda pour récupérer les informations de la fonction Java.

Utilisation du AWS SDK pour Java v2 dans votre gestionnaire

Vous utiliserez souvent les fonctions Lambda pour interagir avec d'autres AWS ressources ou pour les mettre à jour. Le moyen le plus simple d'interagir avec ces ressources est d'utiliser le AWS SDK for Java v2.

Note

Le AWS SDK pour Java (v1) est en mode maintenance et sera disponible end-of-support le 31 décembre 2025. Nous vous recommandons d'utiliser uniquement le AWS SDK pour Java v2 à l'avenir.

Pour ajouter des dépendances du SDK à votre fonction, ajoutez-les dans votre fichier build.gradle for Gradle ou dans votre pom.xml fichier pour Maven. Nous vous recommandons de n'ajouter que les bibliothèques dont vous avez besoin pour votre fonction. Dans l'exemple de code précédent, nous avons utilisé la software.amazon.awssdk.services.s3 bibliothèque. Dans Gradle, vous pouvez ajouter cette dépendance en ajoutant la ligne suivante dans la section des dépendances de votre build.gradle :


implementation 'software.amazon.awssdk:s3:2.28.29'

Dans Maven, ajoutez les lignes suivantes dans la <dependencies> section de votre pom.xml :


    <dependency>
        <groupId>software.amazon.awssdk</groupId>
        <artifactId>s3</artifactId>
        <version>2.28.29</version>
    </dependency>

Note

Il ne s'agit peut-être pas de la version la plus récente du SDK. Choisissez la version du SDK adaptée à votre application.

Importez ensuite les dépendances directement dans votre classe Java :


import software.amazon.awssdk.services.s3.S3Client;
import software.amazon.awssdk.services.s3.model.PutObjectRequest;
import software.amazon.awssdk.services.s3.model.S3Exception;

L'exemple de code initialise ensuite un client Amazon S3 comme suit :


private static final S3Client S3_CLIENT = S3Client.builder().build();

Dans cet exemple, nous avons initialisé notre client Amazon S3 en dehors de la fonction de gestion principale pour éviter d'avoir à l'initialiser à chaque fois que nous invoquons notre fonction. Après avoir initialisé votre client SDK, vous pouvez l'utiliser pour interagir avec d'autres AWS services. L’exemple de code appelle l’API Amazon S3 PutObject comme suit :


PutObjectRequest putObjectRequest = PutObjectRequest.builder()
    .bucket(bucketName)
    .key(key)
    .build();

// Convert the receipt content to bytes and upload to S3
S3_CLIENT.putObject(putObjectRequest, RequestBody.fromBytes(receiptContent.getBytes(StandardCharsets.UTF_8)));

Accès aux variables d’environnement

Dans le code de votre gestionnaire, vous pouvez référencer n'importe quelle variable d'environnement à l'aide de la System.getenv() méthode. Dans cet exemple, nous référençons la variable d’environnement RECEIPT_BUCKET définie à l’aide de la ligne de code suivante :


String bucketName = System.getenv("RECEIPT_BUCKET");
if (bucketName == null || bucketName.isEmpty()) {
    throw new IllegalArgumentException("RECEIPT_BUCKET environment variable is not set");
}

Utilisation de l'état global

Lambda exécute votre code statique et le constructeur de classe pendant la phase d’initialisation avant d’invoquer votre fonction pour la première fois. Les ressources créées lors de l'initialisation restent en mémoire entre les invocations, ce qui vous évite d'avoir à les créer à chaque fois que vous appelez votre fonction.

Dans l'exemple de code, le code d'initialisation du client S3 ne fait pas partie de la méthode de gestion principale. Le moteur d'exécution initialise le client avant que la fonction ne gère son premier événement, ce qui peut entraîner des délais de traitement plus longs. Les événements suivants sont beaucoup plus rapides car Lambda n'a pas besoin d'initialiser à nouveau le client.

Pratiques exemplaires en matière de code pour les fonctions Lambda Java

Respectez les directives de la liste suivante pour utiliser les pratiques exemplaires de codage lors de la création de vos fonctions Lambda :

Séparez le gestionnaire Lambda de votre logique principale. Cela vous permet de créer une fonction testable plus unitaire.
Contrôlez les dépendances du package de déploiement de vos fonctions. L’environnement d’exécution AWS Lambda contient un certain nombre de bibliothèques. Pour activer le dernier ensemble de mises à jour des fonctionnalités et de la sécurité, Lambda met régulièrement à jour ces bibliothèques. Ces mises à jour peuvent introduire de subtiles modifications dans le comportement de votre fonction Lambda. Pour disposer du contrôle total des dépendances que votre fonction utilise, empaquetez toutes vos dépendances avec votre package de déploiement.
Réduisez la complexité de vos dépendances. Privilégiez les infrastructures plus simples qui se chargent rapidement au démarrage de l’environnement d’exécution. Par exemple, préférez les infrastructures d’injection (IoC) de dépendances Java plus simples comme Dagger ou Guice, à des plus complexes comme Spring Framework.
Réduisez la taille de votre package de déploiement selon ses besoins d’exécution. Cela contribue à réduire le temps nécessaire au téléchargement et à la décompression de votre package de déploiement avant l’invocation. Pour les fonctions créées en Java, évitez de télécharger l'intégralité de la bibliothèque du AWS SDK dans le cadre de votre package de déploiement. À la place, appuyez-vous de façon sélective sur les modules qui sélectionnent les composants du kit SDK dont vous avez besoin (par exemple, DynamoDB, modules du kit SDK Amazon S3 et bibliothèques principales Lambda).

Tirez parti de la réutilisation de l’environnement d’exécution pour améliorer les performances de votre fonction. Initialisez les clients SDK et les connexions à la base de données en dehors du gestionnaire de fonctions et mettez en cache les actifs statiques localement dans le répertoire /tmp. Les invocations ultérieures traitées par la même instance de votre fonction peuvent réutiliser ces ressources. Cela permet d’économiser des coûts, tout en réduisant le temps d’exécution de la fonction.

Pour éviter des éventuelles fuites de données entre les invocations, n’utilisez pas l’environnement d’exécution pour stocker des données utilisateur, des événements ou d’autres informations ayant un impact sur la sécurité. Si votre fonction repose sur un état réversible qui ne peut pas être stocké en mémoire dans le gestionnaire, envisagez de créer une fonction distincte ou des versions distinctes d’une fonction pour chaque utilisateur.
Utilisez une directive keep-alive pour maintenir les connexions persistantes. Lambda purge les connexions inactives au fil du temps. Si vous tentez de réutiliser une connexion inactive lorsque vous invoquez une fonction, cela entraîne une erreur de connexion. Pour maintenir votre connexion persistante, utilisez la directive Keep-alive associée à votre environnement d’exécution. Pour obtenir un exemple, consultez Réutilisation des connexions avec Keep-Alive dans Node.js.
Utilisez des variables d’environnement pour transmettre des paramètres opérationnels à votre fonction. Par exemple, si vous écrivez dans un compartiment Amazon S3 au lieu de coder en dur le nom du compartiment dans lequel vous écrivez, configurez le nom du compartiment comme variable d’environnement.
Évitez d’utiliser des invocations récursives dans votre fonction Lambda, lorsque la fonction s’invoque elle-même ou démarre un processus susceptible de l’invoquer à nouveau. Cela peut entraîner un volume involontaire d’invocations de fonction et des coûts accrus. Si vous constatez un volume involontaire d’invocations, définissez immédiatement la simultanéité réservée à la fonction sur 0 afin de limiter toutes les invocations de la fonction, pendant que vous mettez à jour le code.
N'utilisez pas de code non documenté ni public APIs dans votre code de fonction Lambda. Pour les AWS Lambda environnements d'exécution gérés, Lambda applique régulièrement des mises à jour de sécurité et fonctionnelles aux applications internes de Lambda. APIs Ces mises à jour internes de l'API peuvent être rétroincompatibles, ce qui peut entraîner des conséquences imprévues, telles que des échecs d'invocation si votre fonction dépend de ces mises à jour non publiques. APIs Consultez la référence de l'API pour obtenir une liste des API accessibles au public APIs.
Écriture du code idempotent. L’écriture de code idempotent pour vos fonctions garantit ne gestion identique des événements dupliqués. Votre code doit valider correctement les événements et gérer correctement les événements dupliqués. Pour de plus amples informations, veuillez consulterComment faire en sorte que ma fonction Lambda soit idempotente ?.

Évitez d’utiliser le cache DNS de Java. Les fonctions Lambda mettent déjà en cache les réponses DNS. Si vous utilisez un autre cache DNS, vous risquez de subir des interruptions de connexion.

La classe java.util.logging.Logger peut activer indirectement le cache DNS de la JVM. Pour remplacer les paramètres par défaut, définissez networkaddress.cache.ttl sur 0 avant de procéder à l’initialisation de logger. Exemple :
```
public class MyHandler {
  // first set TTL property
  static{
   java.security.Security.setProperty("networkaddress.cache.ttl" , "0");
  }
 // then instantiate logger
  var logger = org.apache.logging.log4j.LogManager.getLogger(MyHandler.class);
}
```
Réduisez le temps que Lambda met à décompresser les packages de déploiement créés dans Java en plaçant vos fichiers .jar de dépendance dans un répertoire /lib distinct. Cette solution est plus rapide que le placement de tout le code de votre fonction dans un seul fichier .jar comprenant une multitude de fichiers .class. Pour obtenir des instructions, consultez Déployer des fonctions Lambda en Java avec des archives de fichiers .zip ou JAR.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Création avec Java

Déploiement d’archives de fichiers .zip

Définition du gestionnaire de fonction Lambda dans Java

Sections

Configuration de votre projet de gestionnaire Java

Exemple de code de fonction Java Lambda

Exemple Fonction Lambda OrderHandler.java

Note

Définitions de classe valides pour les gestionnaires Java

Convention de nommage du gestionnaire

Définition et accès à l’objet d’événement d’entrée

Note

Autres types d'événements d'entrée

Accès et utilisation de l’objet de contexte Lambda

Utilisation du AWS SDK pour Java v2 dans votre gestionnaire

Note

Note

Accès aux variables d’environnement

Utilisation de l'état global

Pratiques exemplaires en matière de code pour les fonctions Lambda Java

Exemple Fonction Lambda `OrderHandler.java`