Aller au contenu principal

Trigger AWS SQS / Évènements

Le trigger AWS SQS (ou Évènements) écoute une file d'attente Amazon Simple Queue Service (SQS) et déclenche un workflow pour chaque message reçu.

Vue d'ensemble​

Ce déclencheur permet de lancer des flux à chaque fois qu'un message est reçu sur une file AWS SQS.

Ce type de trigger est idéal pour :

  • Intégrer avec des systèmes AWS
  • Traiter des messages de manière asynchrone
  • Découpler les systèmes
  • Gérer des files d'attente de messages

Pour les événements Google Cloud Pub/Sub, consultez la page dédiée : Trigger Google Pub/Sub.

Prérequis​

Avant de créer un trigger AWS SQS, vous devez avoir :

  • Un compte AWS avec accès à SQS
  • Une file d'attente SQS créée
  • Une méthode d'authentification AWS (Access Key ID et Secret Access Key)
  • Les permissions nécessaires pour lire depuis la file d'attente

Configuration​

Options de base​

Lors de la création d'un trigger AWS SQS, vous devez configurer :

Région AWS​

Sélectionnez la région AWS où se trouve votre file d'attente :

  • Exemples : us-east-1, eu-west-1, ap-southeast-1
  • La région doit correspondre à celle de votre file d'attente

Queue URL​

L'URL complète de votre file d'attente SQS :

  • Format : https://sqs.{region}.amazonaws.com/{account-id}/{queue-name}

Méthode d'authentification AWS​

Configurez la méthode d'authentification AWS :

  • Access Key ID : Votre clé d'accès AWS
  • Secret Access Key : Votre clé secrète AWS
  • Utilisez une méthode d'authentification Ecosystem pour stocker ces informations de manière sécurisée
Sécurité

Ne stockez jamais vos identifiants AWS directement dans la configuration. Utilisez toujours une méthode d'authentification Ecosystem.

Options avancées​

Visibility Timeout​

Le délai pendant lequel un message est invisible après avoir été récupéré :

  • Par défaut : 30 secondes
  • Augmentez si votre workflow prend plus de temps à s'exécuter
  • Si le message n'est pas supprimé avant la fin du timeout, il redevient visible
Max Number of Messages​

Nombre maximum de messages à récupérer par requête :

  • Par défaut : 1
  • Maximum : 10
  • Plus de messages = traitement plus rapide mais plus complexe
Wait Time​

Temps d'attente pour recevoir des messages (long polling) :

  • Par défaut : 0 (short polling)
  • Recommandé : 20 secondes (long polling)
  • Réduit le nombre de requêtes et les coûts

Données transmises​

Lorsqu'un message est reçu depuis SQS, le workflow reçoit :

{
  "messageId": "123e4567-e89b-12d3-a456-426614174000",
  "receiptHandle": "AQEBzWwaftRI0KuVm4tP...",
  "body": {
    "event": "order.created",
    "data": {
      "orderId": "12345",
      "amount": 99.99
    }
  },
  "attributes": {
    "ApproximateReceiveCount": "1",
    "SentTimestamp": "1234567890123"
  },
  "messageAttributes": {
    "customAttribute": {
      "stringValue": "value",
      "dataType": "String"
    }
  },
  "receivedAt": "2024-01-15T10:30:00Z"
}

Exemple d'utilisation​

Scénario : Traitement de commandes depuis SQS​

  1. Créer la file d'attente dans AWS :

    • Accédez à la console AWS SQS
    • Créez une nouvelle file d'attente
    • Notez l'URL de la file d'attente

  2. Créer une méthode d'authentification AWS :

    • Dans Ecosystem, créez une méthode d'authentification de type AWS
    • Entrez votre Access Key ID et Secret Access Key

  3. Créer le trigger :

    • Type : AWS SQS
    • Région : us-east-1
    • Queue URL : L'URL de votre file d'attente
    • Méthode d'authentification : Celle créée précédemment
    • Visibility Timeout : 60 secondes (si votre workflow prend du temps)

  4. Créer le workflow associé :

    • Reçoit le message depuis SQS
    • Traite la commande
    • Supprime le message de la file après traitement réussi

  5. Déployer :

    • Déployez le trigger dans l'environnement de production
    • Le trigger commence à écouter la file d'attente

Gestion des messages​

Suppression automatique​

Par défaut, Ecosystem supprime automatiquement le message de la file après traitement réussi. Si le workflow échoue, le message reste dans la file et sera retraité.

Suppression manuelle​

Dans certains cas, vous pouvez vouloir supprimer manuellement le message :

  • Utilisez le nœud AWS SQS dans le workflow
  • Supprimez le message après validation

Gestion des erreurs​

Si le workflow échoue :

  • Le message redevient visible après le Visibility Timeout
  • Il sera retraité automatiquement
  • Après plusieurs tentatives, considérez de déplacer le message vers une DLQ (Dead Letter Queue)

Bonnes pratiques​

  • Méthodes d'authentification : Utilisez toujours une méthode d'authentification Ecosystem, jamais des valeurs en dur
  • Visibility Timeout : Configurez un timeout suffisant pour votre workflow
  • Long Polling : Activez le long polling pour réduire les coûts
  • Dead Letter Queue : Configurez une DLQ pour les messages en erreur
  • Monitoring : Surveillez les métriques SQS dans AWS
  • Sécurité : Utilisez des IAM roles avec permissions minimales
  • Idempotence : Assurez-vous que le traitement est idempotent (les messages peuvent être dupliqués)

Coûts AWS​

SQS facture :

  • Les requêtes API (recevoir, supprimer)
  • Le stockage des messages
  • Le transfert de données

Optimisez en utilisant le long polling et en supprimant rapidement les messages traités.

Prochaines étapes​