Envoi et réception d'un événement via EventBridge avec plusieurs cibles

Dans ce contexte, nous montrerons comment envoyer un événement à l'aide d'une règle personnalisée et récupérer un événement en ajoutant une cible. Ici, j'ai ajouté deux cibles qui sont une simple implémentation pub/sub comme Amazon SNS en tant que service de publication, Amazon SQS en tant qu'abonné et surveiller les journaux d'événements de réussite à l'aide de AWS CloudWatch dans EVENTBRIDGE.

Qu'est-ce qu'EventBridge ?

Amazon EventBridge est un bus d'événements sans serveur qui facilite la connexion d'applications avec des données provenant de diverses de sources. Ces sources d'événements peuvent être des applications personnalisées, des services AWS et des applications SaaS partenaires.

Il fournit un moyen flexible de filtrage pour permettre la publication d'événements sur le bus d'événements, puis, en fonction des règles de routage cible, envoie les événements éligibles. aux applications ou services cibles configurés.

Étape 1 : Créer un événement :

Créez un nouveau bus d'événements dans la console EventBridge et nommez-le test-event-bus.[19659005]Étape 2 : Créer une règle personnalisée :

Sur la page d'accueil d'EventBridge, sélectionnez les règles.

• Dans la liste déroulante du bus d'événements, sélectionnez le test-event-bus.
• Cliquez sur Créer règle et nommez-la sample-eventBridge-rule.

Étape 3 : Sous Définir le modèle

• Choisissez Modèle d'événement
• Sous Modèle de correspondance d'événement, sélectionnez Modèle personnalisé et ajoutez votre modèle personnalisé.

En gros, la règle sera c diable nos données d'événement. La source, le type de détail, le détail comme les trois paramètres du modèle d'événement et ceux-ci seraient constants. Si cela correspond, alors seule la règle passera.

Ici, j'ai filtré l'événement en fonction des paramètres "Jack et Jim" en détail (notre message d'événement). Si j'ai donné l'entrée avec Jack/Jim, le message passera. Si nous avons donné une nouvelle valeur au lieu de notre modèle personnalisé, l'événement de demande sera créé. Mais nous ne sommes pas en mesure de surveiller cet événement d'échec dans le journal SNS, SQS et CloudWatch.

Étape 4 : Créer une cible :

Pour Sélectionner des cibleschoisissez le service AWS sur lequel vous souhaitez agir lorsque EventBridge détecte un événement du type sélectionné.

Nous pouvons créer 25 cibles pour une seule règle. Ici, j'ai utilisé deux cibles :

• Choisissez la cible en tant que groupe de journaux CloudWatch et créez un groupe de journaux en tant que sample-eventBridge-log.
• Choisissez la cible en tant que sujet SNS et sélectionnez le nom du sujet SNS en tant que test-eventBridge-topic.

Cible pour CloudWatch :

Cible pour SNS :

Dans la cible SNS, j'ai transformé le message d'entrée en fonction de ma logique pour le chemin d'entrée et le modèle. Comme indiqué ci-dessous, la première partie en tant que chemin d'entrée où les valeurs de données requises sont extraites de la charge utile de l'événement. La deuxième partie est le modèle d'entrée où les données d'événement sortant sont créées en incorporant les valeurs précédemment extraites. Une chose à noter ici est que les données d'événement sortant n'ont pas besoin d'être un JSON !

Étape 5 : Envoyer des événements :

J'ai créé une application EventBridge simple en utilisant démarrage à ressort avec projet gradle.

Dépendances :

groupe d'implémentation : 'software.amazon.awssdk'nom : 'eventbridge' , version : '2.16.101'

Dans EventBridgeController, nous avons deux appels API, l'un pour envoyer un événement à eventbridge et le second pour récupérer les règles d'un événement. Enfin ajouté un écouteur SQS, il est utilisé pour consommer le message d'un événement déclenché provenant de la cible SNS dans la règle. J'ai souscrit à cette file d'attente à partir du sujet SNS. Lorsqu'un événement a passé avec succès la règle, la messagerie pub/sub se produit.

In service class, PutEventsRequest action envoie plusieurs événements à EventBridge en une seule requête.

Étape 6 : Test de l'événement :

De local :

De AWS console :

Sortie d'événement déclenché à partir de la console AWS et de Postman. AWS SQS sera utilisé uniquement pour le message de réussite tel qu'il est mis en évidence. S'il ne satisfaisait pas à la règle, l'événement pourrait être créé avec l'identifiant mais non consommé à partir de SQS en tant que deuxième connexion ci-dessous capture d'écran.

CloudWatch surveille le journal de réussite :

Conclusion :

Ceci est un bref article sur EventBridge se concentrant principalement sur les configurations de règles de routage d'événements. S'il est utilisé à bon escient, il peut certainement apporter plus de polyvalence à l'ensemble de l'ingestion d'événements et au mécanisme de livraison dont nous bénéficions d'Amazon EventBridge. Veuillez consulter mon dépôt GitHub pour la mise en œuvre complète des applications et n'hésitez pas à contribuer au dépôt.

J'espère que vous avez trouvé les détails que j'ai partagés ici utiles. D'ici là, bon événement!

 

Le meilleur outil 2023 pour ta croissance Instagram !

Source link

Partager :

• Cliquez pour partager sur Twitter(ouvre dans une nouvelle fenêtre)
• Cliquez pour partager sur Facebook(ouvre dans une nouvelle fenêtre)