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) ou Google Pub/Sub 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 événement est émis avec Google Pub/Sub ou AWS SQS.

Ce type de trigger est idéal pour :

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

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
  • Les credentials 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

Gestionnaire d'évènements​

Source de la réception du message :

  • Google Pub/Sub : Actuellement disponible
  • AWS SQS : File d'attente Amazon SQS
  • D'autres gestionnaires seront disponibles plus tard

Queue URL / Souscription​

Pour AWS SQS :

  • L'URL complète de votre file d'attente SQS
  • Format : https://sqs.{region}.amazonaws.com/{account-id}/{queue-name}

Pour Google Pub/Sub :

  • Identifiant du projet : Identifiant du projet GCP auquel appartient le sujet (topic) à surveiller
  • Souscription : Souscription à surveiller. Tous les événements publiés sur cette souscription seront reçus

Credentials AWS​

Configurez les credentials AWS :

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

Ne stockez jamais vos credentials AWS directement dans la configuration. Utilisez toujours un Credential 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 un Credential AWS :

    • Dans Ecosystem, créez un Credential 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
    • Credentials : Le credential créé 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​

  • Credentials : Utilisez toujours des Credentials 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​