Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Utilisation de Lambda avec Amazon MQ
**Note**
Si vous souhaitez envoyer des données à une cible autre qu'une fonction Lambda ou enrichir les données avant de les envoyer, consultez [Amazon EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes.html) Pipes.
Amazon MQ est un service d’agent de messages géré pour [Apache ActiveMQ](https://activemq.apache.org/) et [RabbitMQ](https://www.rabbitmq.com). Un *agent de messages* permet à des applications et composants logiciels de communiquer à l’aide de divers langages de programmation, systèmes d’exploitation et autres protocoles de messagerie formels par le biais de rubriques ou d’événements en file d’attente.
Amazon MQ peut également gérer des instances Amazon Elastic Compute Cloud (Amazon EC2) en votre nom en installant des agents ActiveMQ ou RabbitMQ, et en fournissant différentes topologies réseau et infrastructures.
Vous pouvez utiliser une fonction Lambda pour traiter des enregistrements de votre agent de messages Amazon MQ. Lambda invoque votre fonction via un [mappage de source d’événement](invocation-eventsourcemapping.md), une ressource Lambda qui lit les messages de votre agent et invoque la fonction [de manière synchrone](invocation-sync.md).
**Avertissement**
Les mappages des sources d’événements Lambda traitent chaque événement au moins une fois, et le traitement des enregistrements peut être dupliqué. Pour éviter les problèmes potentiels liés à des événements dupliqués, nous vous recommandons vivement de rendre votre code de fonction idempotent. Pour en savoir plus, consultez [Comment rendre ma fonction Lambda idempotente](https://repost.aws/knowledge-center/lambda-function-idempotent) dans le Knowledge Center. AWS
Le mappage de source d’événement Amazon MQ est sujet aux restrictions de configuration suivantes :
+ Simultanéité : les fonctions Lambda qui utilisent un mappage des sources d’événements Amazon MQ disposent d’un paramètre de [simultanéité](lambda-concurrency.md) maximale par défaut. Pour ActiveMQ, le service Lambda limite le nombre d’environnements d’exécution simultanés à cinq par mappage des sources d’événements Amazon MQ. Pour RabbitMQ, le nombre d’environnements d’exécution simultanés est limité à 1 par mappage des sources d’événements Amazon MQ. Même si vous modifiez les paramètres de simultanéité réservés ou fournis de votre fonction, le service Lambda ne mettra pas plus d’environnements d’exécution à disposition. Pour demander une augmentation de la simultanéité maximale par défaut pour un seul mappage de source d'événement Amazon MQ, Support contactez l'UUID du mappage de source d'événement, ainsi que la région. Étant donné que les augmentations sont appliquées au niveau de chaque mappage des sources d’événements, et non au niveau du compte ou de la région, vous devez demander manuellement une augmentation de mise à l’échelle pour chaque mappage des sources d’événements.
+ Traitement entre comptes – Lambda ne prend pas en charge le traitement entre comptes. Vous ne pouvez pas utiliser Lambda pour traiter des enregistrements d’un agent de messages Amazon MQ se trouvant dans un autre Compte AWS.
+ Authentification — Pour ActiveMQ, seul ActiveMQ est pris en charge. [SimpleAuthenticationPlugin](https://activemq.apache.org/security#simple-authentication-plugin) Pour RabbitMQ, seule l’authentification [PLAIN](https://www.rabbitmq.com/access-control.html#mechanisms) est prise en charge. Les utilisateurs doivent utiliser AWS Secrets Manager pour gérer leurs informations d'identification. Pour plus d’informations sur l’authentification ActiveMQ, consultez [Intégration d’agents ActiveMQ avec LDAP](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/security-authentication-authorization.html) dans le *Guide du développeur Amazon MQ*.
+ Quota de connexion – Les agents ont un nombre maximum de connexions autorisées par protocole de niveau filaire. Ce quota est basé sur le type d’instance de l’agent. Pour plus d’informations, consultez la section [Agents](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-limits.html#broker-limits) de **Quotas dans Amazon** dans le *Manuel du développeur Amazon MQ*.
+ Connectivité – Vous pouvez créer des agents dans un cloud privé virtuel (VPC) public ou privé. Pour le mode privé VPCs, votre fonction Lambda doit accéder au VPC pour recevoir des messages. Pour plus d’informations, consultez [Configurer la sécurité réseau](process-mq-messages-with-lambda.md#process-mq-messages-with-lambda-networkconfiguration), plus loin dans cette section.
+ Destinations d’événements – Seules les destinations en file d’attente sont prises en charge. Toutefois, vous pouvez utiliser une rubrique virtuelle qui se comporte comme une rubrique en interne tout en interagissant avec Lambda en tant que file d’attente. Pour plus d’informations, consultez [Virtual Destinations (Destinations virtuelles)](https://activemq.apache.org/virtual-destinations) sur le site web Apache ActiveMQ, et [Virtual Hosts (Hôtes virtuels)](https://www.rabbitmq.com/vhosts.html) sur le site web RabbitMQ.
+ Topologie réseau – Pour ActiveMQ, un mappage de source d’événement prend en charge une seule instance ou un seul agent en veille. Pour RabbitMQ, un mappage de source d’événement prend en charge un seul agent d’instance ou un seul déploiement de cluster. Les agents à instance unique nécessitent un point de terminaison de basculement. Pour plus d’informations sur ces modes de déploiement d’agent, consultez [Architecture d’agent ActiveMQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-broker-architecture.html) et [Architecture d’agent RabbitMQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/rabbitmq-broker-architecture.html) dans le *Guide du développeur Amazon MQ*.
+ Protocoles – Les protocoles pris en charge dépendent du type d’intégration d’Amazon MQ.
+ Pour les intégrations ActiveMQ, Lambda consomme les messages à l'aide OpenWire/Java du protocole Message Service (JMS). Aucun autre protocole n’est pris en charge pour la consommation de messages. Dans le protocole JMS, seuls [https://activemq.apache.org/components/cms/api_docs/activemqcpp-3.6.0/html/classactivemq_1_1commands_1_1_active_m_q_text_message.html](https://activemq.apache.org/components/cms/api_docs/activemqcpp-3.6.0/html/classactivemq_1_1commands_1_1_active_m_q_text_message.html) et [https://activemq.apache.org/components/cms/api_docs/activemqcpp-3.9.0/html/classactivemq_1_1commands_1_1_active_m_q_bytes_message.html](https://activemq.apache.org/components/cms/api_docs/activemqcpp-3.9.0/html/classactivemq_1_1commands_1_1_active_m_q_bytes_message.html) sont pris en charge. Lambda prend également en charge les propriétés personnalisées JMS. Pour plus d'informations sur le OpenWire protocole, consultez [OpenWire](https://activemq.apache.org/openwire.html)le site Web d'Apache ActiveMQ.
+ Pour les intégrations RabbitMQ, Lambda consomme des messages à l’aide du protocole AMQP 0-9-1. Aucun autre protocole n’est pris en charge pour la consommation de messages. Pour plus d’informations sur l’implémentation par RabbitMQ du protocole AMQP 0-9-1, consultez [Guide de référence complet AMQP 0-9-1](https://www.rabbitmq.com/amqp-0-9-1-reference.html) sur le site web de RabbitMQ.
Lambda prend automatiquement en charge les dernières versions d’ActiveMQ et de RabbitMQ qu’Amazon MQ prend en charge. Pour connaître les dernières versions prises en charge, consultez [Notes de mise à jour Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-release-notes.html) dans le *Guide du développeur Amazon MQ*.
**Note**
Par défaut, Amazon MQ comporte une fenêtre de maintenance hebdomadaire pour les agents. Pendant cette période, les agents ne sont pas disponibles. Pendant ce temps, Lambda ne peut pas traiter les messages des agents sans veille.
**Topics**
+ [Comprendre le groupe de consommateurs Lambda pour Amazon MQ](#services-mq-configure)
+ [Configuration de source d’événements Amazon MQ pour Lambda](process-mq-messages-with-lambda.md)
+ [Paramètres de mappage des sources d’événements](services-mq-params.md)
+ [Filtrer les événement à partir d’une source d’événements Amazon MQ](with-mq-filtering.md)
+ [Résoudre les erreurs de mappage des sources d’événement Amazon MQ](services-mq-errors.md)
## Comprendre le groupe de consommateurs Lambda pour Amazon MQ
Pour interagir avec Amazon MQ, Lambda crée un groupe de consommateurs qui peut être lu à partir de vos agents Amazon MQ. Le groupe de consommateurs est créé avec le même ID qu’un mappage de source d’événements UUID.
Pour les sources d’événements Amazon MQ, Lambda réunit les enregistrements par lots et les envoie à votre fonction dans une seule charge utile. Pour contrôler le comportement, vous pouvez configurer la fenêtre de traitement par lots et la taille du lot. Lambda extrait les messages jusqu’à ce qu’il traite la taille maximale de la charge utile de 6 Mo, que la fenêtre de traitement par lots expire ou que le nombre d’enregistrements atteigne la taille totale du lot. Pour de plus amples informations, veuillez consulter [Comportement de traitement par lots](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching).
Le groupe de consommateurs récupère les messages sous forme de BLOB d’octets, puis les code en base64 dans une charge unique JSON puis invoque votre fonction. Si votre fonction renvoie une erreur pour l’un des messages d’un lot, Lambda réessaie le lot de messages complet jusqu’à ce que le traitement réussisse ou que les messages expirent.
**Note**
Alors que les fonctions Lambda ont généralement un délai d’expiration maximal de 15 minutes, les mappages des sources d’événement pour Amazon MSK, Apache Kafka autogéré, Amazon DocumentDB et Amazon MQ pour ActiveMQ et RabbitMQ ne prennent en charge que les fonctions dont le délai d’expiration maximal est de 14 minutes. Cette contrainte garantit que le mappage des sources d’événements peut gérer correctement les erreurs de fonction et effectuer de nouvelles tentatives.
Vous pouvez surveiller l'utilisation simultanée d'une fonction donnée à l'aide de la `ConcurrentExecutions` métrique d'Amazon CloudWatch. Pour de plus amples informations sur la simultanéité, consultez [Configuration de la simultanéité réservée pour une fonction](configuration-concurrency.md).
**Example Événements d’enregistrement Amazon MQ**
```
{
"eventSource": "aws:mq",
"eventSourceArn": "arn:aws:mq:us-east-2:111122223333:broker:test:b-9bcfa592-423a-4942-879d-eb284b418fc8",
"messages": [
{
"messageID": "ID:b-9bcfa592-423a-4942-879d-eb284b418fc8-1---mq---us-east-2.amazonaws.com.rproxy.goskope.com-37557-1234520418293-4:1:1:1:1",
"messageType": "jms/text-message",
"deliveryMode": 1,
"replyTo": null,
"type": null,
"expiration": "60000",
"priority": 1,
"correlationId": "myJMSCoID",
"redelivered": false,
"destination": {
"physicalName": "testQueue"
},
"data":"QUJDOkFBQUE=",
"timestamp": 1598827811958,
"brokerInTime": 1598827811958,
"brokerOutTime": 1598827811959,
"properties": {
"index": "1",
"doAlarm": "false",
"myCustomProperty": "value"
}
},
{
"messageID": "ID:b-9bcfa592-423a-4942-879d-eb284b418fc8-1---mq---us-east-2.amazonaws.com.rproxy.goskope.com-37557-1234520418293-4:1:1:1:1",
"messageType": "jms/bytes-message",
"deliveryMode": 1,
"replyTo": null,
"type": null,
"expiration": "60000",
"priority": 2,
"correlationId": "myJMSCoID1",
"redelivered": false,
"destination": {
"physicalName": "testQueue"
},
"data":"LQaGQ82S48k=",
"timestamp": 1598827811958,
"brokerInTime": 1598827811958,
"brokerOutTime": 1598827811959,
"properties": {
"index": "1",
"doAlarm": "false",
"myCustomProperty": "value"
}
}
]
}
```
```
{
"eventSource": "aws:rmq",
"eventSourceArn": "arn:aws:mq:us-east-2:111122223333:broker:pizzaBroker:b-9bcfa592-423a-4942-879d-eb284b418fc8",
"rmqMessagesByQueue": {
"pizzaQueue::/": [
{
"basicProperties": {
"contentType": "text/plain",
"contentEncoding": null,
"headers": {
"header1": {
"bytes": [
118,
97,
108,
117,
101,
49
]
},
"header2": {
"bytes": [
118,
97,
108,
117,
101,
50
]
},
"numberInHeader": 10
},
"deliveryMode": 1,
"priority": 34,
"correlationId": null,
"replyTo": null,
"expiration": "60000",
"messageId": null,
"timestamp": "Jan 1, 1970, 12:33:41 AM",
"type": null,
"userId": "AIDACKCEVSQ6C2EXAMPLE",
"appId": null,
"clusterId": null,
"bodySize": 80
},
"redelivered": false,
"data": "eyJ0aW1lb3V0IjowLCJkYXRhIjoiQ1pybWYwR3c4T3Y0YnFMUXhENEUifQ=="
}
]
}
}
```
Dans l’exemple RabbitMQ, `pizzaQueue` est le nom de la file d’attente RabbitMQ, et `/` est le nom de l’hôte virtuel. Lors de la réception de messages, la source d’événement répertorie les messages sous `pizzaQueue::/`.
# Configuration de source d’événements Amazon MQ pour Lambda
**Topics**
+ [Configurer la sécurité réseau](#process-mq-messages-with-lambda-networkconfiguration)
+ [Créer le mappage des sources d’événements](#services-mq-eventsourcemapping)
## Configurer la sécurité réseau
Pour donner à Lambda un accès complet à Amazon MQ via votre mappage des sources d’événements, soit votre agent doit utiliser un point de terminaison public (adresse IP publique), soit vous devez fournir un accès au VPC Amazon dans lequel vous avez créé l’agent.
Lorsque vous utilisez Amazon MQ avec Lambda, créez des [points de terminaison de VPC AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) qui permettent à votre fonction d’accéder aux ressources de votre Amazon VPC.
**Note**
AWS PrivateLink Les points de terminaison VPC sont requis pour les fonctions avec des mappages de sources d'événements qui utilisent le mode par défaut (à la demande) pour les sondeurs d'événements. Si le mappage de votre source d'événements utilise le [mode provisionné](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode), vous n'avez pas besoin de configurer les points de terminaison AWS PrivateLink VPC.
Créez un point de terminaison pour accéder aux ressources suivantes :
+ Lambda — Créez un point de terminaison pour le principal de service Lambda.
+ AWS STS — Créez un point de terminaison pour le AWS STS afin qu'un directeur de service assume un rôle en votre nom.
+ Secrets Manager : si votre agent utilise Secrets Manager pour stocker les informations d’identification, créez un point de terminaison pour Secrets Manager.
Vous pouvez également configurer une passerelle NAT sur chaque sous-réseau public d’Amazon VPC. Pour de plus amples informations, veuillez consulter [Activation de l’accès Internet pour les fonctions Lambda connectées à un VPC](configuration-vpc-internet.md).
Lorsque vous créez un mappage de sources d'événements pour Amazon MQ, Lambda vérifie si des interfaces réseau élastiques (ENIs) sont déjà présentes pour les sous-réseaux et les groupes de sécurité configurés pour votre Amazon VPC. Si Lambda trouve des objets existants ENIs, il essaie de les réutiliser. Sinon, Lambda en crée un nouveau ENIs pour se connecter à la source de l'événement et appeler votre fonction.
**Note**
Les fonctions Lambda s'exécutent toujours au sein VPCs du service Lambda. La configuration VPC de votre fonction n’affecte pas le mappage des sources d’événements. Seule la configuration réseau des sources d’événements détermine la manière dont Lambda se connecte à votre source d’événements.
Configurez les groupes de sécurité pour le VPC Amazon contenant votre agent. Par défaut, Amazon MQ utilise les ports suivants : `61617` (Amazon MQ pour ActiveMQ) `5671` et (Amazon MQ pour RabbitMQ).
+ Règles entrantes – Autorisent tout le trafic sur le port de l’agent par défaut pour le groupe de sécurité associé à votre source d’événement. Vous pouvez également utiliser une règle de groupe de sécurité avec référence circulaire pour autoriser l’accès à partir d’instances appartenant au même groupe de sécurité.
+ Règles de sortie : autorisez tout le trafic sur le port `443` pour les destinations externes si votre fonction doit communiquer avec les AWS services. Vous pouvez également utiliser une règle de groupe de sécurité à référencement automatique pour limiter l'accès au courtier si vous n'avez pas besoin de communiquer avec d'autres AWS services.
+ Règles entrantes relatives au point de terminaison Amazon VPC – Si vous utilisez un point de terminaison Amazon VPC, le groupe de sécurité associé à votre point de terminaison Amazon VPC doit autoriser le trafic entrant sur le port `443` en provenance du groupe de sécurité de l’agent.
Si votre agent utilise l’authentification, vous pouvez également restreindre la politique de point de terminaison pour le point de terminaison Secrets Manager. Pour appeler l’API Secrets Manager, Lambda utilise votre rôle de fonction, et non le principal de service Lambda.
**Example Politique de point de terminaison de VPC — Point de terminaison Secrets Manager**
```
{
"Statement": [
{
"Action": "secretsmanager:GetSecretValue",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws::iam::123456789012:role/my-role"
]
},
"Resource": "arn:aws::secretsmanager:us-west-2:123456789012:secret:my-secret"
}
]
}
```
Lorsque vous utilisez des points de terminaison Amazon VPC, AWS achemine vos appels d'API pour appeler votre fonction à l'aide de l'Elastic Network Interface (ENI) du point de terminaison. Le directeur du service Lambda doit faire appel à tous `lambda:InvokeFunction` les rôles et fonctions qui les utilisent. ENIs
Par défaut, les points de terminaison Amazon VPC disposent de politiques IAM ouvertes qui permettent un accès étendu aux ressources. La meilleure pratique consiste à restreindre ces politiques pour effectuer les actions nécessaires à l’aide de ce point de terminaison. Pour garantir que votre mappage des sources d’événements est en mesure d’invoquer votre fonction Lambda, la politique de point de terminaison de VPC doit autoriser le principal de service Lambda à appeler `sts:AssumeRole` et `lambda:InvokeFunction`. Le fait de restreindre vos politiques de point de terminaison de VPC pour autoriser uniquement les appels d’API provenant de votre organisation empêche le mappage des sources d’événements de fonctionner correctement. C’est pourquoi `"Resource": "*"` est requis dans ces politiques.
Les exemples de politiques de point de terminaison de VPC suivants montrent comment accorder l’accès requis au principal de service Lambda pour les points de terminaison AWS STS et Lambda.
**Example Politique de point de terminaison VPC — point de terminaison AWS STS**
```
{
"Statement": [
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
**Example Politique de point de terminaison de VPC — Point de terminaison Lambda**
```
{
"Statement": [
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
## Créer le mappage des sources d’événements
Créez un [mappage de source d’événement](invocation-eventsourcemapping.md) pour indiquer à Lambda d’envoyer des enregistrements d’un agent Amazon MQ à une fonction Lambda. Vous pouvez créer plusieurs mappages de source d’événement pour traiter les mêmes données avec plusieurs fonctions, ou pour traiter des éléments à partir de plusieurs sources avec une seule fonction.
Pour configurer votre fonction afin qu’elle lise à partir d’Amazon MQ, ajoutez les autorisations requises et créez un déclencheur **MQ** dans la console Lambda.
Pour lire les enregistrements d’un agent Amazon MQ, votre fonction Lambda a besoin des autorisations suivantes. Vous autorisez Lambda à interagir avec votre agent Amazon MQ et ses ressources sous-jacentes en ajoutant des déclarations d’autorisation à votre rôle d’[exécution de fonction](lambda-intro-execution-role.md) :
+ [mq : DescribeBroker](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/brokers-broker-id.html#brokers-broker-id-http-methods)
+ [responsable des secrets : GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)
+ [EC2 : CreateNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkInterface.html)
+ [EC2 : DeleteNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkInterface.html)
+ [EC2 : DescribeNetworkInterfaces](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeNetworkInterfaces.html)
+ [EC2 : DescribeSecurityGroups](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSecurityGroups.html)
+ [EC2 : DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html)
+ [EC2 : DescribeVpcs](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html)
+ [journaux : CreateLogGroup](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html)
+ [journaux : CreateLogStream](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogStream.html)
+ [journaux : PutLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html)
**Note**
Lorsque vous utilisez une clé gérée par le client chiffrée, ajoutez également l’autorisation `[kms:Decrypt](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-bootstrap-brokers.html#clusters-clusterarn-bootstrap-brokersget)`.
**Pour ajouter des autorisations et créer un déclencheur**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom d’une fonction.
1. Choisissez l’onglet **Configuration**, puis **Permissions** (Autorisations).
1. Sous **Nom du rôle**, cliquez sur le lien vers votre rôle d’exécution. Ce lien ouvre le rôle dans la console IAM.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/execution-role.png)
1. Sélectionnez **Ajouter des autorisations**, puis **Ajouter la politique**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/inline-policy.png)
1. Dans l’**Éditeur de politique**, sélectionnez **JSON**. Saisissez la politique suivante. Votre fonction a besoin de ces autorisations pour lire à partir d’un agent Amazon MQ.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"mq:DescribeBroker",
"secretsmanager:GetSecretValue",
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
```
------
**Note**
Lorsque vous utilisez une clé gérée par le client chiffrée, vous devez également ajouter l’autorisation `kms:Decrypt`.
1. Choisissez **Suivant**. Saisissez un nom de politique, puis choisissez **Créer une politique**.
1. Revenez à votre fonction dans la console Lambda. Sous **Function overview (Vue d’ensemble de la fonction)**, choisissez **Add trigger (Ajouter un déclencheur)**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/add-trigger.png)
1. Choisissez le type de déclencheur **MQ**.
1. Configurez les options requises, puis choisissez **Add (Ajouter)**.
Lambda prend en charge les options suivantes pour les sources d’événement Amazon MQ.
+ **MQ broker (Agent MQ)** – Sélectionnez un agent Amazon MQ.
+ **Batch size (Taille de lot)** – Définissez le nombre maximum de messages à extraire dans un lot.
+ **Queue name (Nom de file d’attente)** – Entrez la file d’attente Amazon MQ à consommer.
+ **Source access configuration (Configuration de l’accès source)** – Entrez les informations d’hôte virtuel et le secret Secrets Manager qui stocke vos informations d’identification d’agent.
+ **Enable trigger (Activer le déclencheur)** – Désactivez le déclencheur pour arrêter le traitement des enregistrements.
Pour activer ou désactiver le déclencheur (ou le supprimer), choisissez le déclencheur **MQ** dans le concepteur. Pour reconfigurer le déclencheur, utilisez les opérations d’API de mappage de source d’événement.
# Paramètres de mappage des sources d’événements
Tous les types de sources d’événement Lambda partagent les mêmes opérations d’API [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) et [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html). Cependant, seuls certains paramètres s’appliquent à Amazon MQ et à RabbitMQ.
| Paramètre | Obligatoire | Par défaut | Remarques |
| --- | --- | --- | --- |
| BatchSize | N | 100 | Maximum : 10 000. |
| Activé | N | VRAI | none |
| FunctionName | Y | N/A | none |
| FilterCriteria | N | N/A | [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md) |
| MaximumBatchingWindowInSeconds | N | 500 ms | [Comportement de traitement par lots](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching) |
| Files d’attente | N | N/A | Le nom de la file d’attente de destination de l’agent Amazon MQ à consommer. |
| SourceAccessConfigurations | N | N/A | Pour ActiveMQ, informations d’identification BASIC\$1AUTH. Pour RabbitMQ, il peut contenir à la fois des informations d’identification BASIC\$1AUTH et des informations VIRTUAL\$1HOST. |
# Filtrer les événement à partir d’une source d’événements Amazon MQ
Vous pouvez utiliser le filtrage d’événements pour contrôler les enregistrements d’un flux ou d’une file d’attente que Lambda envoie à votre fonction. Pour obtenir des informations générales sur le fonctionnement du filtrage des événements, consultez [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md).
Cette section porte sur le filtrage des événements pour les sources Amazon MQ.
**Note**
Les mappages des sources d’événements Amazon MQ prennent uniquement en charge le filtrage sur la clé `data`.
**Topics**
+ [Principes de base du filtrage des événements Amazon MQ](#filtering-AMQ)
## Principes de base du filtrage des événements Amazon MQ
Supposons que votre file d’attente de messages Amazon MQ contienne des messages au format JSON valide ou sous forme de chaînes simples. Un exemple d’enregistrement ressemblerait à ce qui suit, avec les données converties en chaîne encodée en Base64 dans le champ `data`.
------
#### [ ActiveMQ ]
```
{
"messageID": "ID:b-9bcfa592-423a-4942-879d-eb284b418fc8-1---mq---us-east-2.amazonaws.com.rproxy.goskope.com-37557-1234520418293-4:1:1:1:1",
"messageType": "jms/text-message",
"deliveryMode": 1,
"replyTo": null,
"type": null,
"expiration": "60000",
"priority": 1,
"correlationId": "myJMSCoID",
"redelivered": false,
"destination": {
"physicalName": "testQueue"
},
"data":"QUJDOkFBQUE=",
"timestamp": 1598827811958,
"brokerInTime": 1598827811958,
"brokerOutTime": 1598827811959,
"properties": {
"index": "1",
"doAlarm": "false",
"myCustomProperty": "value"
}
}
```
------
#### [ RabbitMQ ]
```
{
"basicProperties": {
"contentType": "text/plain",
"contentEncoding": null,
"headers": {
"header1": {
"bytes": [
118,
97,
108,
117,
101,
49
]
},
"header2": {
"bytes": [
118,
97,
108,
117,
101,
50
]
},
"numberInHeader": 10
},
"deliveryMode": 1,
"priority": 34,
"correlationId": null,
"replyTo": null,
"expiration": "60000",
"messageId": null,
"timestamp": "Jan 1, 1970, 12:33:41 AM",
"type": null,
"userId": "AIDACKCEVSQ6C2EXAMPLE",
"appId": null,
"clusterId": null,
"bodySize": 80
},
"redelivered": false,
"data": "eyJ0aW1lb3V0IjowLCJkYXRhIjoiQ1pybWYwR3c4T3Y0YnFMUXhENEUifQ=="
}
```
------
Pour les agents Active MQ et Rabbit MQ, vous pouvez utiliser le filtrage d’événements pour filtrer les enregistrements à l’aide de la clé `data`. Supposons que votre file d’attente Amazon MQ contienne des messages au format JSON suivant.
```
{
"timeout": 0,
"IPAddress": "203.0.113.254"
}
```
Pour filtrer uniquement les enregistrements dont le champ `timeout` est supérieur à 0, l’objet `FilterCriteria` serait le suivant.
```
{
"Filters": [
{
"Pattern": "{ \"data\" : { \"timeout\" : [ { \"numeric\": [ \">\", 0] } } ] } }"
}
]
}
```
Pour plus de clarté, voici la valeur du `Pattern` de filtre étendu en JSON simple :
```
{
"data": {
"timeout": [ { "numeric": [ ">", 0 ] } ]
}
}
```
Vous pouvez ajouter votre filtre à l’aide de la console, d’AWS CLI ou d’un modèle AWS SAM.
------
#### [ Console ]
pour ajouter ce filtre à l’aide de la console, suivez les instructions de [Attacher des critères de filtre à un mappage de sources d’événements (console)](invocation-eventfiltering.md#filtering-console) et saisissez la chaîne suivante comme **critère de filtre**.
```
{ "data" : { "timeout" : [ { "numeric": [ ">", 0 ] } ] } }
```
------
#### [ AWS CLI ]
Pour créer un nouveau mappage des sources d’événements avec ces critères de filtrage à l’aide de l’outil AWS Command Line Interface (AWS CLI), exécutez la commande suivante.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:mq:us-east-2:123456789012:broker:my-broker:b-8ac7cc01-5898-482d-be2f-a6b596050ea8 \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : { \"timeout\" : [ { \"numeric\": [ \">\", 0 ] } ] } }"}]}'
```
Pour ajouter ces critères de filtre à un mappage des sources d’événements existant, exécutez la commande suivante.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : { \"timeout\" : [ { \"numeric\": [ \">\", 0 ] } ] } }"}]}'
```
Pour ajouter ces critères de filtre à un mappage des sources d’événements existant, exécutez la commande suivante.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : { \"timeout\" : [ { \"numeric\": [ \">\", 0 ] } ] } }"}]}'
```
------
#### [ AWS SAM ]
Pour ajouter ce filtre à l’aide d’AWS SAM, ajoutez l’extrait suivant au modèle YAML de votre source d’événement.
```
FilterCriteria:
Filters:
- Pattern: '{ "data" : { "timeout" : [ { "numeric": [ ">", 0 ] } ] } }'
```
------
Avec Amazon MQ, vous pouvez également filtrer les enregistrements dont le message est une chaîne simple. Supposons que vous vouliez traiter uniquement les enregistrements dont le message commence par « Result: ». L’objet `FilterCriteria` se présente comme suit.
```
{
"Filters": [
{
"Pattern": "{ \"data\" : [ { \"prefix\": \"Result: \" } ] }"
}
]
}
```
Pour plus de clarté, voici la valeur du `Pattern` de filtre étendu en JSON simple :
```
{
"data": [
{
"prefix": "Result: "
}
]
}
```
Vous pouvez ajouter votre filtre à l’aide de la console, d’AWS CLI ou d’un modèle AWS SAM.
------
#### [ Console ]
Pour ajouter ce filtre à l’aide de la console, suivez les instructions de [Attacher des critères de filtre à un mappage de sources d’événements (console)](invocation-eventfiltering.md#filtering-console) et saisissez la chaîne suivante comme **critère de filtre**.
```
{ "data" : [ { "prefix": "Result: " } ] }
```
------
#### [ AWS CLI ]
Pour créer un nouveau mappage des sources d’événements avec ces critères de filtrage à l’aide de l’outil AWS Command Line Interface (AWS CLI), exécutez la commande suivante.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:mq:us-east-2:123456789012:broker:my-broker:b-8ac7cc01-5898-482d-be2f-a6b596050ea8 \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : [ { \"prefix\": \"Result: \" } ] }"}]}'
```
Pour ajouter ces critères de filtre à un mappage des sources d’événements existant, exécutez la commande suivante.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : [ { \"prefix\": \"Result: \" } ] }"}]}'
```
------
#### [ AWS SAM ]
Pour ajouter ce filtre à l’aide d’AWS SAM, ajoutez l’extrait suivant au modèle YAML de votre source d’événement.
```
FilterCriteria:
Filters:
- Pattern: '{ "data" : [ { "prefix": "Result " } ] }'
```
------
Les messages Amazon MQ doivent être des chaînes codées en UTF-8, soit des chaînes en texte brut, soit au format JSON. En effet, Lambda décode les tableaux d’octets Amazon MQ en UTF-8 avant d’appliquer des critères de filtre. Si vos messages utilisent un autre encodage, tel que UTF-16 ou ASCII, ou si le format du message ne correspond pas au format `FilterCriteria`, Lambda traite uniquement les filtres de métadonnées. Le tableau suivant résume le comportement spécifique :
| Format du du message entrant | Modèle de filtre de format pour les propriétés des messages | Action obtenue. |
| --- | --- | --- |
| Chaîne de texte brut | Chaîne de texte brut | Lambda filtre en fonction de vos critères de filtre. |
| Chaîne de texte brut | Pas de modèle de filtre pour les propriétés des données | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| Chaîne de texte brut | JSON valide | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| JSON valide | Chaîne de texte brut | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| JSON valide | Pas de modèle de filtre pour les propriétés des données | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| JSON valide | JSON valide | Lambda filtre en fonction de vos critères de filtre. |
| Chaîne non codée UTF-8 | JSON, chaîne de texte brut ou aucun modèle | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
# Résoudre les erreurs de mappage des sources d’événement Amazon MQ
Quand une fonction Lambda rencontre une erreur irrécupérable, votre consommateur Amazon MQ arrête le traitement des enregistrements. D’autres consommateurs peuvent continuer le traitement, à condition qu’ils ne rencontrent pas la même erreur. Pour déterminer la cause potentielle d’un consommateur arrêté, vérifiez le champ `StateTransitionReason` dans les détails de retour de votre `EventSourceMapping` pour l’un des codes suivants :
**`ESM_CONFIG_NOT_VALID`**
La configuration de mappage de source d’événement n’est pas valide.
**`EVENT_SOURCE_AUTHN_ERROR`**
Lambda n’a pas réussi à authentifier la source de l’événement.
**`EVENT_SOURCE_AUTHZ_ERROR`**
Lambda ne dispose pas des autorisations requises pour accéder à la source d’événement.
**`FUNCTION_CONFIG_NOT_VALID`**
La configuration de la fonction n’est pas valide.
Les enregistrements ne sont pas non plus traités si Lambda les abandonne en raison de leur taille. La taille limite pour les enregistrements Lambda est de 6 Mo. Pour relivrer des messages en cas d’erreur de fonction, vous pouvez utiliser une file d’attente de lettres mortes (DLQ). Pour plus d’informations, consultez [Message Redelivery and DLQ Handling (Relivraison des messages et gestion des DLQ)](https://activemq.apache.org/message-redelivery-and-dlq-handling), et le [Guide de fiabilité](https://www.rabbitmq.com/reliability.html) sur le site web RabbitMQ.
**Note**
Lambda ne prend pas en charge les stratégies de relivraison personnalisées. Au lieu de cela, Lambda utilise une stratégie avec les valeurs par défaut de la page [Stratégie de relivraison](https://activemq.apache.org/redelivery-policy) sur le site web d’Apache ActiveMQ, avec `maximumRedeliveries` défini sur 6.