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.
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 for 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!
Step 5: Send events:
I have created a simple EventBridge application using spring boot with gradle project.
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.
In service class, PutEventsRequest action sends multiple events to EventBridge in a single request.
Step 6: Testing the event:
From local:
From 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.
CloudWatch monitor the success 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!
