Skip to main content

Amazon Web Services

Sending and Receiving an event through EventBridge with Multiple Targets

Istock 1303320175

In this context, we will show how to send an event using custom rule and retrieve an event by adding target. Here I have added two targets which is simple pub/sub implementation as Amazon SNS as our publishing service, Amazon SQS as a subscriber and monitor the success event logs using AWS CloudWatch in EVENTBRIDGE.

What is EventBridge?

Amazon EventBridge is a serverless event bus that makes it easier to connect applications with data from a variety of sources. These event sources can be custom applications, AWS services and partner SaaS applications.

It provides a flexible way of filtering to allow events to be published to the event bus, and then, based on the target routing rules, sends the eligible events to the configured target applications or services.

Step 1: Create Event:

Create a new event bus in the EventBridge console and name it as test-event-bus.

Step 2: Create Custom Rule:

On the EventBridge homepage, Select Rules.

  • From the Event bus dropdown, select the test-event-bus.
  • Click Create rule and name it as sample-eventBridge-rule.

Step 3: Under Define pattern

  • Choose Event pattern
  • Under Event matching pattern, select Custom pattern and add your custom pattern.

Define

Basically, rule will check our event data. The source, detail-type, detail as the three parameters in event pattern and these would be constant. If it matched, then only the rule will pass.

Here I have filtered the event based on “Jack and Jim” in detail (our event message) params. If I gave the input with Jack/Jim the message will pass. If we gave any new value instead of our custom pattern, then the request event will be created. But we are not able to monitor that failure event in SNS, SQS and CloudWatch log.

Step 4: Create Target:

For Select targets, choose the AWS service that you want to act when EventBridge detects an event of the selected type.

We can create 25 targets for a single rule. Here I have used two targets:

  • Choose target as CloudWatch log group and create a log group as sample-eventBridge-log.
  • Choose target as SNS topic and select the SNS topic name as test-eventBridge-topic.

Target for CloudWatch:

Target Cloud

Target for SNS:

Amazon Web Services - Avoid Contact Center Outages: Plan Your Upgrade to Amazon Connect
Avoid Contact Center Outages: Plan Your Upgrade to Amazon Connect

Learn the six most common pitfalls when upgrading your contact center, and how Amazon Connect can help you avoid them.

Get the Guide

Target Sns

In SNS target I have transformed the input message based on my logic for input path and template. As shown below, the first part as Input path  where the required data values are extracted from the event payload. The second part is the Input template where the outgoing event data is created by incorporating the previously extracted values. One thing to note here is that the outgoing event data doesn’t need to be a JSON!

Transformer

Step 5: Send events:

I have created a simple EventBridge application using spring boot with gradle project.

Prjt Strure

Dependencies:

implementation group: ‘software.amazon.awssdk’, name: ‘eventbridge’, version: ‘2.16.101’

In EventBridgeController we have two api calls, one is for send an event to eventbridge and second one is for retrieving rules from an event. Finally added a SQS Listener, this is used to consume the message from a triggered event which from SNS target in rule. I have subscribed this queue from SNS topic. When an event successfully passed the rule the pub/sub messaging will occur.

Controller

In service classPutEventsRequest action sends multiple events to EventBridge in a single request.

Service

Step 6: Testing the event:

From local:

Local

From AWS console:

Aws Console

Triggered event output from both the AWS console and Postman. AWS SQS will be consumed only for the success message as highlighted. If it did not satisfy the rule, the event could be created with id but not consumed from SQS as second log in below screenshot.

Local Log

CloudWatch monitor the success log:

Cloudwatch Log

Conclusion:

This is a brief write up on EventBridge focusing mainly on the event routing rule configurations. If used wisely, it certainly can bring more versatility to the entire event ingestion and the delivery mechanism that we benefit from Amazon EventBridge. Please look into my GitHub repo for the full implementation of the applications and feel free to contribute to the repo.

I hope you found the details I shared here useful. Until then, happy eventing!

 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.