Author: Mehul Sengupta
Introduction:
Amazon SNS – Amazon Simple Notification Service is a managed AWS service that provides the functionality of message-based communication on the cloud, which can be used to decouple the components in an application without the overhead of having to manage and bear the operating costs for the same. Like most other AWS components, it’s subscription-based as in pay as you use, so it is more affordable while at the same time enabling us to focus mainly on the business logic. It’s scalable and highly available, so the chances of losing important messages are also negligible. Amazon SNS is based on topics around the publish-subscribe messaging model, i.e., too much messaging between systems achieved by fanning out messages to multiple systems. It has two functionalities:
- Application to application – As in passing on messages to SQS queues, HTTP endpoints, etc.
- Application to person – As in passing messages to end users via mail, SMS, etc.
In this article, we will look at a few of the most commonly used SNS connectors from the Mule 4 SNS module.
Prerequisites:
- An Amazon Web Services free tier account, with an IAM user having access to SNS whose access key and secret can be used to configure.
- A test topic created in the SNS Console inside AWS so its ARN can be used.
- Anypoint Studio 7.10
- An email receiving the notifications.
- A mobile number for receiving SMS notifications.
Mule 4 SNS Connector:
The Mule 4 SNS connector enables us to connect directly to the Amazon SNS API from Mule ESB. We configure the connector using the access key and token of the AWS account, and we are good at accessing the topics. There are many different connectors present in the SNS module, but we are going to focus on the following in this article:
- Create topic
- Publish
- Create Email and SMS subscriptions to demonstrate fanout.
The SNS module is not implicitly present in the Palette. We have to import it from Exchange:
SNS Configuration:
Next, we configure the credentials to access the SNS topics. We use a separate secure properties config file here. To obtain the SNS ARN, go to the SNS Console on AWS. Alongside the topic name, copy the ARN and paste it into the property file. Also, add the access key and secret for the SNS config and paste it into the property file. Select the Basic option from the drop-down. Next, from the property files, fill out the values as:
- Test Topic and Globally Defined Default Topic ARN – test topic ARN as secure property placeholder ${secure::sns.testTopic}
- Access Key: IAM access key – ${secure::sns.access_key}
- Secret Key: IAM secret key – ${secure::sns.secret}
- Region Endpoint: The region where the topic is present – ${secure::sns.region}
Next, we create a simple flow to demonstrate the working of the Create Topic connector:
Create Topic:
The connectors:
- A simple GET HTTP Listener which passes on an URI Param as the topic name.
- Two simple loggers
- The Create Topic connector configured as below to create a topic with the specified topic name as URI parameter:
Run the project and hit the endpoint with a GET request from any REST client such as Postman: http://localhost:8081/create-topic/notifications1
Note: We created the HTTP listener with default properties and set the endpoint name as create-topic. If you changed anything, use your specific endpoint name. Once this is run, a topic with name notifications1 will be created and a response.
- For a successful run, we get the topic ARN returned to the REST client as well as a payload, if logged after the Create Topic connector:
arn:aws:sns:us-east-1:513*********:notifications1
- If we go to the SNS Console, we can now see our newly created Topic along with other topics (if any)
Now we set the subscriptions for the Topic to demonstrate the fanout capabilities of SNS and how it’s different from SQS. For simplicity, we do this directly from the AWS console.
In the SNS Console,
- Select the notifications topic from the list.
- Scroll down and select the subscription tab
- Create a subscription and select the protocol from the drop down.
- We will configure both the Email and SMS protocols.
- Email:
- Select Email from the drop down.
- In the endpoint, type a valid email address that you have access to.
- Leave the other optional fields as is.
- Click on create subscription, once done it needs to be confirmed and for the same, you’ll receive an email from AWS as below.
- Confirm the subscription by clicking on the link, you’ll get a message with Subscription confirmed.
- In the SNS console, refresh and now you should see the subscription is confirmed.
- SMS:
- Select SMS from the drop down.
- Add a phone number to be verified since we are using the Sandbox here.
- An SMS with a verification code will be sent to the number. Verify the same.
- Next, similar to the Email, select the topic ARN and number to send the SMS to which in this case would be the one which we just verified.
- Skip other optional fields and create the subscription.
Thus we now have 2 confirmed subscriptions as below:
We now Publish a simple message from our REST client to the Topic, and in turn, it’ll send an Email and SMS simultaneously:
Publish:
The connectors:
- A simple GET HTTP Listener which passes on an URI Param as the topic name.
- Two simple loggers
- A transform message which transforms the JSON object to a Java String simulating an order confirmation message.
Note: Publish only accepts a String message.
- The publish connector: The publish connector as the name suggests, publishes a message to the desired topic. Here, we pass on the order confirmation message which we just created using the Transform message to the topic to be sent as Email and SMS.
As visible from the connector config, the following values need to be populated:
- Display Name – A suitable display name for the connector, default is Publish.
- Connector config – The configuration we just defined.
- Message – The message being passed as payload, but in Java String format.
- Subject – Optional to define a subject for the message to be published.
- Message structure – blank here, (json – to signify a json message)
- Message attributes – optional – Amazon SNS message attributes
- Topic ARN – The unique ARN defining the topic (arn:aws:sns:us-east-1:513*********:notifications1)
- Target ARN – Platform endpoint where you want to publish the message (blank)
- Phone Number – The phone number where you want to publish (blank)
Note: One or more of the last 3 points are required. In this article, we only publish to the Topic, so that ARN is only populated.
Once the flow is ready, we trigger it with some sample JSON object at the following endpoint: http://localhost:8081/publish :
{
“id”: 12345,
“product”: “MSI GeForce GTX 1050 TI 4GT OC Graphics Card”,
“price”: 29708,
“qty”: 1
}
Upon successful execution of the flow, the message would have been inserted into the Topic, and we get a unique id for the message returned as the response.
As soon as the message is published, we receive the Email notification on our subscribed Email as below with the subject as we had specified in the Publish connector:
We also receive the SMS notification with the same body simultaneously.
So that’s how fanout works with Amazon SNS topics. Similarly, we can add more endpoints such as HTTP/HTTPS, SQS queues, Lambda functions, etc.
Unlike SQS, where we have a one-to-one message transfer pattern, in SNS, we can have more than one consumer (one to many) using the Publish-Subscribe pattern as we saw here.
