Aller au contenu principal

Trigger Google Pub/Sub / Évènements

Le trigger Google Pub/Sub (ou Évènements) écoute une souscription Google Cloud 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 publié sur un topic Google Pub/Sub et livré via la souscription configurée.

Ce type de trigger est idéal pour :

  • Intégrer avec des systèmes Google Cloud (GCP)
  • Traiter des messages de manière asynchrone
  • Découpler les systèmes via un bus d'événements
  • Réagir aux événements émis par d'autres services GCP (Cloud Functions, BigQuery, etc.)

Prérequis​

Avant de créer un trigger Google Pub/Sub, vous devez avoir :

  • Un projet Google Cloud avec l'API Pub/Sub activée
  • Un topic Pub/Sub créé
  • Une souscription (subscription) associée à ce topic — en mode pull pour qu'Ecosystem puisse consommer les messages
  • Une méthode d'authentification GCP (compte de service avec les droits Pub/Sub Subscriber)

Configuration​

Options de base​

Lors de la création d'un trigger de type Évènements avec le gestionnaire Google Pub/Sub, vous devez configurer :

Identifiant du projet (Project ID)​

L'identifiant du projet GCP auquel appartient le topic et la souscription à surveiller (ex. : my-project-12345).

Souscription (Subscription)​

Le nom de la souscription à surveiller. Tous les messages publiés sur le topic associé et livrés à cette souscription déclencheront le workflow.
Format typique : projects/<project-id>/subscriptions/<subscription-name> ou simplement le nom de la souscription selon l'interface Ecosystem.

Méthode d'authentification GCP​

Configurez la méthode d'authentification Google Cloud utilisée par Ecosystem pour accéder à Pub/Sub :

  • Compte de service : utilisez une clé de compte de service (JSON) ou les identifiants pris en charge par Ecosystem
  • Utilisez une méthode d'authentification Ecosystem (type GCP / Google) pour stocker ces informations de manière sécurisée
Sécurité

Ne stockez jamais les clés de compte de service ou les identifiants GCP directement dans la configuration. Utilisez toujours une méthode d'authentification Ecosystem.

Le compte de service doit disposer au minimum du rôle Pub/Sub Subscriber (ou équivalent) sur la souscription concernée.

Données transmises​

Lorsqu'un message est reçu depuis Google Pub/Sub, le workflow reçoit une structure contenant notamment :

{
  "messageId": "1234567890",
  "data": "<données encodées en base64 du corps du message>",
  "body": {
    "event": "order.created",
    "data": {
      "orderId": "12345",
      "amount": 99.99
    }
  },
  "attributes": {
    "customAttribute": "value"
  },
  "publishTime": "2024-01-15T10:30:00.000Z",
  "orderingKey": "optional-ordering-key",
  "receivedAt": "2024-01-15T10:30:01Z"
}
  • messageId : identifiant unique du message Pub/Sub
  • data : corps du message (souvent encodé en base64 côté Pub/Sub ; selon la configuration, il peut être décodé dans body)
  • attributes : attributs personnalisés éventuels attachés au message à la publication
  • publishTime : date/heure de publication sur le topic

Exemple d'utilisation​

Scénario : Traitement d'événements depuis un topic Pub/Sub​

  1. Créer le topic et la souscription dans GCP :

    • Dans la console Google Cloud (Pub/Sub), créez un topic (ex. : orders-events)
    • Créez une souscription en mode pull liée à ce topic (ex. : orders-events-sub)
    • Notez l'identifiant du projet et le nom de la souscription

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

    • Dans Ecosystem, créez une méthode d'authentification de type Google / GCP
    • Associez un compte de service disposant du rôle Pub/Sub Subscriber sur cette souscription

  3. Créer le trigger :

    • Type : Évènements (Event)
    • Gestionnaire d'événements : Google Pub/Sub
    • Identifiant du projet : l'ID de votre projet GCP
    • Souscription : le nom ou l'identifiant complet de la souscription
    • Méthode d'authentification : celle créée précédemment

  4. Créer le workflow associé :

    • Le workflow reçoit le message Pub/Sub en entrée
    • Traitez le payload (par ex. commande, notification)
    • Après traitement réussi, le message est reconnu (ack) ; en cas d'échec, il peut être renvoyé (nack) pour retraitement

  5. Déployer :

    • Déployez le trigger dans l'environnement cible
    • Le trigger commence à consommer les messages de la souscription

Gestion des messages​

Reconnaissance (ack) automatique​

En général, Ecosystem reconnaît (ack) automatiquement le message après un traitement réussi. Si le workflow échoue, le message peut être refusé (nack) et redevenir disponible pour une nouvelle tentative selon la politique de la souscription.

Délai d'expiration (ack deadline)​

Pub/Sub impose un délai pour reconnaître un message. Si le workflow dépasse ce délai, le message peut être redelivré. Configurez si besoin un timeout adapté à la durée de votre workflow.

Gestion des erreurs​

  • En cas d'échec du workflow, le message peut être retraité selon la configuration de la souscription (retry, dead-letter topic, etc.).
  • Utilisez un dead-letter topic pour les messages en erreur après plusieurs tentatives.
  • Assurez-vous que le traitement est idempotent : les messages peuvent être livrés plus d'une fois.

Bonnes pratiques​

  • Méthodes d'authentification : Utilisez toujours une méthode d'authentification Ecosystem, jamais de clés en dur.
  • Permissions : Principe du moindre privilège — le compte de service doit avoir uniquement les droits Subscriber sur la souscription concernée.
  • Idempotence : Concevez le workflow pour gérer les livraisons multiples du même message.
  • Dead-letter : Configurez une souscription dead-letter pour les messages en échec après N tentatives.
  • Monitoring : Surveillez les métriques Pub/Sub dans Google Cloud (nombre de messages non reconnus, délai de traitement).

Prochaines étapes​