That’s exactly what webhooks do. They notify your application instantly when a particular event occurs, prompting it to respond with a specific action.

How does a webhook work?

With a traditional system, your application would have to constantly check or ‘poll’ other services for updates. This is not only inefficient, but it also doesn’t provide real-time updates. Webhooks, on the other hand, reverse this process. 

Webhooks rely on HTTP (Hypertext Transfer Protocol) to transmit data. When an event occurs, the sending system requests an HTTP POST to a predefined URL, often called the “callback URL.” This URL points to the receiver’s endpoint, where it expects to receive data.

Basically, when a specific event happens, the data related to the event are sent immediately to a URL designated by your application. This automated information exchange allows web applications to communicate with each other in real time.

What are some common use cases?

1. Real-time updates. Social media platforms use webhooks to instantly notify users of new messages, likes, or comments.
2. Ecommerce. Online stores employ webhooks to update inventory levels, process orders, and send order status notifications.
3. Notifications. Messaging apps use webhooks to deliver real-time notifications, such as chat messages or friend requests.
4. IoT (Internet of Things). Webhooks are essential for collecting sensor data from IoT devices and triggering actions based on sensor readings.

Setting up webhooks.

Setting up webhooks involves three primary steps: 

1. Create a webhook endpoint. This is a URL in your application that will receive the webhooks. It should be an API endpoint that is capable of processing POST requests, as POST is the HTTP method generally used by webhooks.
2. Register the webhook endpoint with the provider. The webhook provider needs to know where to send the webhooks. This usually involves going to the provider’s dashboard or settings page and adding your endpoint URL to the webhooks section. You might also need to specify which events you want to subscribe to.
3. Implement the logic for received webhooks. Once your application receives a webhook, it needs to know what to do with the data. This could be anything from updating a user’s email address to processing a payment. The logic you implement will depend entirely on your application’s specific needs.

Remember to secure your webhooks to ensure that incoming requests are indeed from the provider. This usually involves verifying signatures that webhook providers include in their requests.

How to use webhooks with SMS.

Using webhooks with SMS is a powerful way to integrate real-time communication into your applications. To get started, you’ll need to sign up with an SMS service provider that supports webhooks, like Sinch MessageMedia.

1. First, set up a webhook endpoint on your server to receive incoming SMS data.
2. Once your webhook is in place, configure your SMS service provider to send a webhook notification whenever a new SMS is received. This notification will typically include essential information such as the sender’s phone number, the message content, and a timestamp.
3. You can then process this data in real-time, enabling various actions like automated replies, storing message history, or triggering specific events based on incoming SMS content.

By using webhooks with SMS, you can create dynamic, interactive, and responsive SMS-based applications that enhance your communication capabilities.

The post What is a webhook? appeared first on Sinch MessageMedia.

The basic authentication method is straightforward yet essential for businesses. It plays a critical role in securing computer systems and controlling data access, ensuring that only authorised parties can access sensitive resources.

When using this method, users insert an encoded string into the Authorisation header of each request.

HTTP basic authentication header format.

Basic authentication credentials are typically sent via HTTP request header, known as the basic auth header. The header format consists of the word “Basic” followed by a base64-encoded string of the username and password separated by a colon. Here’s an example:

Functionality overview.

1. Client request: The process begins with a client requesting access to the server.
2. Server challenge: The server responds with a challenge, requesting authentication.
3. User credentials: The user or system provides their username and password.
4. Encoding credentials: The credentials are encoded in base64.
5. Sending credentials to the server: The client sends the encoded credentials to the server.
6. Server authentication: The server decodes and verifies the credentials, granting the user access if valid.

Basic authentication is a fundamental security layer, ensuring only authorised entities can access resources. It’s essential for safeguarding sensitive data and enhancing overall system protection, seamlessly meeting requests for basic auth.

Ready to enhance your business’s security? Get started with a free trial.

The post What is basic authentication? appeared first on Sinch MessageMedia.

What is REST and SOAP API

SOAP is a protocol for most web services – it stands for Simple Object Access Protocol. However, as the internet evolved developers needed a way to quickly build more lightweight web and mobile applications. Thus, the alternative REST API (application programming interface) architecture was developed. REST quickly gained popularity as it supports multiple data formats and WS security. In 2018, most public web services provided REST APIs.

Some enterprise users still frequently choose SOAP for their web services and at MessageMedia we provide the legacy SOAP web services for those who have built their systems around it.

We do, however, encourage migration to the REST APIs where possible, for a number of reasons. It’s worth enumerating these reasons, as the decision to migrate is far more complex than just developer popularity.

D/L our free REST API key.

Get started building SMS integrations today.

Let’s go

SOAP API vs REST API

We’ve written before on what REST is.

While a lot of the newer APIs are built with REST architecture, and it’s definitely a trendy thing, it also has some real benefits. SOAP and REST are two different approaches to building APIs and two different answers to the question of “how to deal with data transmission”.

The main difference is that SOAP is a standardized protocol with official specifications, maintained and developed by the World Wide Web Consortium (W3C), while REST is an architectural style. On the other hand, REST architecture is a set of guidelines for creating RESTful web services. Thus, SOAP comes with strict rules, higher complexity, and requires more bandwidth and resources which can lead to slower page load times.

This means that in 2019, SOAP will be used for certain transactions that require high-level complexity such as APIs for financial services, payment gateways, CRM software, identity management, and so on. In some cases, you may need to process stateful operations. Such scenarios include those where you have to make a chain of operations act as one transaction, like bank transfers.

REST was created to address the problems of SOAP that arise when trying to send data for use in customer-facing applications, especially in today’s era of web and mobile apps where page load times = revenue.

At MessageMedia we’ve opted for the flexibility of REST, as we continue to build out our messaging capabilities. 

Benefits of REST API over SOAP

In general terms, the upshot of REST is that for the vast majority of cases, using the REST API will mean you’re able to do more, quicker, and with less bandwidth.

REST works better for modern thin clients (like a web browser) so if you are building a cloud app, REST is the preferable type of API for you. It works for all types of networking equipment and with a variety of service types (Java, .NET, PHP, Ruby, static HTTP, etc.). If you are building any kind of cloud app at all, you need the flexibility of REST. Imagine the tech debt of having to maintain your app while being locked into specific infrastructure requirements because of how you’ve set up access to the SOAP API.

By the same token, you want to be as flexible as possible about the type of client you’re able to run your app on in the majority of cases; even if right now your app runs on known infrastructure, this won’t always be the case. Because of REST’s lightweight and flexible implementation, it’s very Infrastructure friendly – network load balancers, firewalls, proxies, etc. are all optimised for RESTful traffic because they are optimised for HTTP/S traffic.

Finally, REST requests are stateless and thus by definition, highly scalable as they rely on multiple communication protocols. They’re also much more efficient – SOAP services always return XML, but our REST service returns JSON, which is the de-facto standard, and these JSON payloads are smaller than their XML counterparts. If you include the SOAP envelope overhead in this calculation, then our REST+JSON payloads are dramatically smaller.

Why REST API is used at MessageMedia

Aside from the general business reasons above, in a MessageMedia specific context, we are upfront about advocating for our customers to move to the REST APIs where possible.

The first and most obvious reason for this is that the flexibility of creating a REST web service enables us to innovate with our product offering. We’re building out a number of products and features that are only available via the REST API. When using the SOAP API you will, of course, get the benefit of our super high throughput and reliability – but you won’t get further product innovations like Secure Webhooks, or even the optionality of sending MMS, or any of the other exciting things on our product roadmap, such as RCS. These value-add features are often the key to getting the most value out of our products.

The second reason you might want to move across is if you are continuing to develop new interactions with the API, you will want to have access to our continually-improving developer toolkit for the REST APIs. In the developer relations team, we’re undertaking a number of projects this year to build out the developer toolkits. This includes the soon to be released v2 of the SDKs, which will make it easier than ever to get up and running with integration and more code samples.  

Migration strategy: SOAP to REST API

The most important part of commencing any move is going to be figuring out to what extent you currently use the SOAP API.

Depending on how your site is built to interface with the MessageMedia SOAP API, the level of changes required will vary. For example, in a simple use case where a piece of software is using the SOAP API simply to send bulk messages, this will be a relatively simple swap out for a lot of gains in terms of reducing complexity. However, if the software in question is making numerous calls to block and unblock numbers, schedule messages and so on, it will be necessary to match those functions to MessageMedia REST APIs.

The second part of this will be assessing the level of integration. The level of effort required for a full migration will depend largely on how your current code is built. If your current code uses code libraries the changes should be minimal. However, if your current code doesn’t use code libraries, the changes required may be fiddly. Once you’ve assessed these requirements, depending on your current site and future goals, migrating to the REST APIs and freeing yourself from the shackles of supporting SOAP-consuming code, could present an opportunity for you to optimise other parts of your site.

The good news is, you won’t ever run into a situation where the SOAP API does something for you that the REST API can’t. MessageMedia REST APIs have full feature parity across the numerous SOAP APIs that make up the legacy landscape.

D/L our free REST API key.

Get started building SMS integrations today.

Let’s go

Speak to our messaging team now to help you assess what functionality you currently use and how to transfer over to REST.

The post Convert SOAP to REST API: The benefits appeared first on Sinch MessageMedia.

For the companies that use this feature, it enables them to control branding and imbue their messages with an element of trustworthiness. When a customer receives a text from a sender with a name rather than a random number, they are going to be much more inclined to trust its messaging.

This is a capability offered by MessageMedia Rest APIs via a mechanism we call “alpha tags”.

What is an alpha tag

Alpha tags are a way for you to give your SMS messages a unique ‘sender’ name, which can include digits, text, and some special characters. With MessageMedia alpha tags you have a total of 11 characters to uniquely identify your business. You can choose to let the recipient know who the SMS is from, what it’s about, or any other information you’d like to convey within the space of 11 characters.

Why you should start using alpha tags

There are a number of marketing reasons to consider using alpha tags.

An example marketing use case is specifying a brand or campaign name. With your brand or campaign name as the message sender, your customers know immediately whom the SMS is from and what it’s about, greatly reducing their frustration with SMS communications because they know straight away whether they need to look at the message right away or whether it can wait for later.

There are also operational benefits to using alpha tags that you may not have considered. For example, having a sender name can increase authenticity for SMS 2FA systems. 

Most banks are currently using SMS-based 2FA methods in order to confirm new transaction recipients and, sometimes, individual transactions. Adding an alpha tag to these SMS messages increases their authenticity and the customer’s sense of security regarding your service. For an example of how to do 2FA with MessageMedia, view our Auth0 solution here.

Another operational use case involves urgent messaging in customer service – for example, a delivery notification from a courier or mailing business. Using alpha tags in this situation immediately highlights to the customer what the message is so that they read and act on it straight away.

Another customer service value-add is being able to specify different alpha tags for your messages allows you to let your customers know which messages are promotional, which are service messages, and which are personal communications. They know straight away what’s important, greatly increasing engagement with your SMS.

How are alpha tags limited

However, when working with alpha tags or considering using them, there are some limitations that you should be aware of:

• Each alpha tag must be relevant to your business and/or usecase, and must be registered with MessageMedia before you can send.
• They can only be used for one way message use cases
• They can only be sent once the feature is enabled on your account (contact your account manager)
• Not all countries support alpha tags
• Their maximum length is 11 characters, (consider abbreviating)
• iPhones don’t support special characters, (hyphens or underscores will be stripped out)

How to add alpha tags with MessageMedia APIs

To send with an alpha tag you first need to log into the MessageMedia Hub. and put in a request for your desired alpha tag (3-11 numbers and/or letters). To be approved, the alpha tag must have relevance to your business name and/or use case. You will receive email confirmation once the alpha tag has been approved. You can then send from the alpha tag, using the API call below.

When you’re making a call to the API there are two relevant fields:

Source Number: You can now use a text source number

Source Number Type: Change to “ALPHANUMERIC”

This is an example of a valid message call with alpha tags:

Add alpha tags to your SMS communications today.

Talk to one of our messaging experts.

Get started now

Final thoughts, further reading

Alpha tags is a feature available within MessageMedia APIs that you may find beneficial in a number of different use cases.

Get in touch with us if you’d like to turn it on in your account.

The post Alpha tag SMS: Send SMS with name instead of number appeared first on Sinch MessageMedia.

API Blueprints

API Blueprint is a high-level API description language. It’s an alternative to OpenAPI specifications (also known as Swagger). API Blueprint can be preferable in some circumstances because it is known for being easier to read for members of the team who don’t spend all day ‘down in the weeds’ of the code. An .apib file is essentially a markdown format file and its look and feel is familiar to anyone who has edited a Github readme file before. It’s easy for a community manager or a product manager to  change a description or add things with confidence that they’re not going to ‘break’ the way something renders. Some of the disadvantages of using .apib are that it lacks the same ecosystem around code level tooling that Swagger has. For example, Swagger code-gen is a huge time-saver for generating SDKs directly from a Swagger specification. I’m in the process of working around this but for now, we’re ‘all in’ on API Blueprint at MessageMedia. 

Including markdown templates

Aglio is an API Blueprint renderer that outputs static HTML, similar to Swagger UI for Swagger specs, or any of the other OpenAPI spec renderers. Aglio has several benefits for .apib users, including multiple themes and customisable output. However, the feature that really appealed to us, in this case, was the ability use ‘includes’. An ‘include’ is a separate markdown document nested in your API spec project that can be “pulled in” to the final render, and used in other neighbouring renders. This means that we can, for example, include the main body of the reporting documentation from the reporting team, include another team’s authentication information, and include any other surrounding information like a Postman collection button. In this scenario, Aglio will spit out a complete public-facing .abib file.

Distributing across teams

Now that we understand the concept of how Aglio can generate from multiple sources, the second issue is how to get sources from multiple git repos in the right place. The reporting team has its, Developer Relations has a public-facing documentation repo, and we need to be able to reference the master version of their repo so that changes get pulled in as they occur. The answer to this problem is submodules. 

Sub moduling is a git feature that allows you to use another project from within your project. It’s similar to including a package via a package manager. You can read more about the feature and its usage here, but to get started quickly, follow these instructions: 

Step 1: Add the submodule

git submodule add git://github.com/coder_bec/docsmaster.git docs

Step 2: Fix the submodule to a particular branch (devrel branch)

git checkout -b dev_branch origin/dev_branch

Step 3: Commit everything

git add .

git commit -m 'adding submodules'

Now, whenever the reporting team does an update to their repo, they do a PR to our branch – can we add this as a pipeline? – maybe.

Now when a change is made to a downstream submodule, you fetch and merge it. 

Step 4: Fetch and merge

git fetch

git merge origin/master

The question then becomes how to make sure you know when to fetch and merge and push your new docs. For now, we have a notification on the bitbucket repo that tells us when to do this. In the future we could look at ways to automate this. Let us know on our Developer Slack if you have any suggestions!

Putting it all together with Buildkite

Now that we’ve got our new process and it’s pulling in from all the right places, we can make a Buildkite pipeline that does a bunch of stuff and deploys our .apib file to our Apiary account. 

In the pipeline file above, we lint the documentation, validate it with a file that checks it’s a proper .apid file, then publish it to our Apiary account.

The future

In the future, we will look at using the HTML rendering features of Aglio and moving outside of Apiary. We may also be looking at ways to automate this process.

The post Managing API documentation over multiple teams appeared first on Sinch MessageMedia.

Hieu Nguyen is a Technical Lead at MessageMedia, interested in systems design and leading teams to achieve challenging goals. Outside of work, he keeps himself busy by reading about new technologies. Hieu loves travelling and playing chess with friends.

Introduction

In a previous post, Introduction to AWS Step Functions, you discovered the steps for coding and setting up a workflow with an AWS console. This post will show you how to organise and deploy a serverless application using a serverless framework.

What is serverless?

Serverless is another term for FAAS (Function As A Service). It’s an architecture for running code without worrying about the server or maintenance. Serverless takes care of managing a server and automatically scaling the system. This means that as an engineer, you can focus on implementing the application logic and deploying to the cloud provider.

Serverless framework is an enterprise framework that supports code deployments to various cloud providers. With the Serverless framework, you can maintain the database, policy and codebase in a serverless template and then build the whole infrastructure in a few seconds.

What is a Workflow?

A workflow is the order of steps, tasks, events, or interactions involved in the process of performing a certain task. Instead of displaying the application logic with complex code, you can use a workflow to visualise models and clearly control the logic in an application.

Step Functions is an AWS service that enables creation and management of. This service communicates with many other AWS services to build an application.

In AWS, there are many ways to manage a workflow definition. If you use an AWS console to create the definition workflow, it will be difficult and time-consuming to move the definition to another environment. Instead of creating a definition in an AWS console, you can build an environment in a few seconds using a severless framework. This method allows you to manage everything from coding to deployment in one place, saving you time and simplifying the process.

How to Build a Workflow with Serverless Framework

Let’s jump into the steps for setting up a serverless framework and an AWS CLI environment.

Prerequisites

• Node.js v6.5.0 or later.
• An AWS account. If you don’t have one, you can sign up for a free trial.
• An AWS CLI environment. Please follow this article.
• The configuration of your AWS CLI on your computer.
• Serverless CLI v1.9.0. Please follow this article.

Step One: Create a Serverless Project

You should use the command line serverless create –template aws-python –path aws-workflow to create a new serverless project.

–template aws-python: Set up a project template with a python environment

–path aws-workflow: Project folder

# Create a new Serverless Service/Project
$ serverless create –template aws-python –path aws-workflow

The command generates two files:

handler.py: This file contains the lambda function that you use later in state-machine

serverless.yml: The file is used for the configuration

Step Two: Update the handle.py File

Update the handle.py file by copying and pasting the following code. This function returns a message with the name in the event.

def lambda_handler (event, context):
 name = event['name']
 return name + ': Go Serverless v1.0! Your function executed successfully!'

Step Three: Create a Workflow

You will need to create a workflow with a serverless file. First, you should publicise a Lambda function with the name of “handler.lambda_handler“.

Next, you need to link a task to an Amazon Resources Name (ARN), following this structure arn:aws:lambda:#{AWS::Region}:#{AWS::AccountId}:function:${self:service}-${opt:stage}-lambda_handler.

This helps the state-machine to invoke a task with AWS Lambda. Moreover, you should use two plugins for the deployment of the Step Function. They are:

serverless-step-functions: Supports deploying the Step Function

serverless-pseudo-parameters: Resolves pseudo-parameters such as AWS::AccountId

The below should be copied as the content of serverless.yml:

service: aws-workflow

provider:# Used to publicize specific configurations for Cloud service providers, such as configuring provider names, runtime environments, usage areas, etc.
 aws # This tells Server Framework that you will deploy it to AWS lambda
 runtime: python3.7 # You will use python 3.7 to run your code
 stage: ${opt:stage, 'vn'} # This is the stage of deployment. You usually have dev/qa/prod
 region: ${opt:region, 'ap-southeast-2'} # You will deploy Python at southeast-2 region
 accountId: 201922325580 # Your AWS accountId
 memorySize: 2048 # optional, in MB, default is 1024
 timeout: 900 # optional, in seconds, default is 6
 deploymentBucket:
 name: "201922325580-reports-lambda-ap-southeast-2" # The place you will deploy our code
 deploymentPrefix: appts # Prefix of package deployment
 endpointType: regional
 versionFunctions: false
 role: IamRole

functions: #You will declare specific function logic functions here.
 hello:
 handler: handler.lambda_handler # Lambda function name

stepFunctions: # Definition of workflow
 stateMachines:
 hellostepfunc1:
 definition:
 Comment: "A Hello World example of the Amazon States Language using an AWS Lambda Function"
 StartAt: GetInformation
 States:
 GetInformation:
 Type: Task
 Resource: "arn:aws:lambda:#{AWS::Region}:#{AWS::AccountId}:function:${self:service}-${opt:stage}-hello"
 End: true
 resources: # This section will declare resources so that your Functions can be used. The resource will be declared by an AWS service called CloudFormation.
 Resources:
 IamRole:
 Type: "AWS::IAM::Role"
 Properties:
 RoleName: "#{AWS::Region}-${self:provider.stage}-aws-workflows"
 AssumeRolePolicyDocument:
 Version: "2012-10-17"
 Statement:
 - Effect: "Allow"
 Principal:
 Service:
 - lambda.amazonaws.com
 Action: "sts:AssumeRole"
 Policies:
 -
 PolicyName: "jira-reports-policy"
 PolicyDocument:
 Version: "2012-10-17"
 Statement:
 -
 Effect: Allow
 Action:
 - "logs:*" # Allow to write/read to CloudWatchLog
 Resource:
 - "*" # Allow all resources in VPC access
 plugins:
 - serverless-step-functions
 - serverless-pseudo-parameters

Step Four: Deploy the Workflow Application

You need to run some basic commands with a Command-Line-Interface

sudo npm install -g serverless: Installs a serverless framework package.

sudo npm install: Installs all libraries that are required in this project.

serverless plugin install: Installs a plugin that you need for a specific provider.

Please execute the commands to install and deploy the application.

Step Five: Run a Workflow Application

After deploying the application, serverless generates a Step Functions definition on the AWS console.

{
 "Comment": "A Hello World example of the Amazon States Language using an AWS Lambda Function",
 "StartAt": "GetInformation",
 "States": {
 "GetInformation": {
 "Type": "Task",
 "Resource": "arn:aws:lambda:ap-southeast-2:201922325580:function:aws-workflow-vn-hello",
 "End": true
 }
 }
 }

If you go to Step Functions on the AWS console, you will see the workflow definition and the visualised steps as below.

To execute your Step Function, navigate to Step Functions on the AWS console and choose the Step Function you have created. In the “Executions” tab, click on the “Start Execution” button, specify an execution name and provide the input as below.

{
 "name": "Input your name here"
 }

Once you hit the “Start Execution” button, the workflow calls your Lambda function and the output is displayed. Afterwards, your state machine is executed and the colour of the state changes to blue during execution and then to green for successful completion.

Conclusion

AWS Step Function is a compilation of workflows and Lambda functions, based on the serverless architecture. The serverless framework is a powerful solution for building and maintaining code in one place. These technologies hasten the development and deployment of an application.

The post How to use Serverless framework for building workflows appeared first on Sinch MessageMedia.

Introduction

Twenty years ago, I wrote my first automated chatbot. It hosted a trivia channel on IRC — the massive public chat network popular through the 90s and early 2000s. It asked a question, assessed answers and kept scores. It was written in AppleScript and required that I kept my Macintosh Quadra running 24/7, hoping the dial-up internet never flaked out. For some reason, writing bots for chat programs has become somewhat of a hobby. For many years my language of choice was Perl. I ran the bot on leased servers — expensive and overpowered for the simple nature of a bot.

In two tutorials, I’m going to bring you into my world. We’re going to work together to create a modern bot that you can interact with via Slack — the ubiquitous chat service of the modern technology company.

But we’re going to mix in some magic I would have loved twenty years ago. The magic of serverless architecture. You’ll be able to run your bot full time, in the cloud, without needing to run a server or provision any compute resources in your cloud environment.

These two tutorials will use Amazon’s AWS resources. But the concepts are easily transferred to Microsoft Azure, Google Compute or any other serverless environment you choose. The code I’ll show you will be written in Python, but it’s all simple enough that you could translate it into Node, Java, Go, or whatever language your environment provides.

In the first tutorial, we’ll explore how to set up a bot in AWS Lambda, linking in AWS API Gateways, and then attaching it to Slack. The actual bot is less important. All it will do is respond to a single command. There’s no state to maintain, no storage, no databases. By the time you’re finished, you should be able to repurpose the bot to respond with more useful information than this tutorial.

In the second tutorial we will link in some more of Amazon’s vast library of serverless services and a MessageMedia account to create a bot that can send and receive two-way SMS messages from within Slack.

Neither tutorial requires you to know how to write Python. All the code is provided, and you can just copy and paste. I’ll walk you through creating a serverless Slack bot. You can get the source from BitBucket here: https://bitbucket.org/RickMeasham/serverlessslackbot

Tutorial 1: Good one dad!

Let’s get this over with; I’m a dad. I tell dad jokes. But I’ve been telling them far longer than I’ve been a dad. Most of my friends laugh good-naturedly, but I’ll never forget the time my friend Suze responded to a joke with a sarcasm-laded “Good one dad”. (I’m sure she actually thinks I’m hilarious).

Let’s write a bot that Suze would love. Let’s write a bot that responds with a dad joke whenever someone types “/dadjoke” in our Slack account.

The Toolkit

This bot is super simple. All we need is an AWS account and a Slack account that will let us add an app. If your work account doesn’t let you add an app, then it’s free to sign up for your own Slack account. It’ll just be lonely unless you invite some friends. Similarly, you can sign up for a free AWS account with Amazon: https://aws.amazon.com.

In AWS we will use the Lambda service. Lambda is a serverless environment that runs a program on demand without requiring provisioning of compute (EC2) resources. If nobody ever says “/dadjoke” then the program will never execute, no compute resources will be used, and it will cost you nothing. At the time of writing you can create this Lambda and run it all within Amazon’s free tier. We’ll also use an API Gateway service, and log to CloudWatch. But we’ll let Lambda configure those for us. Lambda even comes with its own code editor, so we will literally be doing everything in the cloud.

It would be nice if you could connect Lambda to a Git repository for simple version management, but for now the best you can do is link Lambda to S3 and deploy your script to a bucket in a build pipeline. All that is well beyond our simple needs, so we will use the code editor provided by AWS in your browser.

Outline:

1. Create a new “Hello World” Lambda
2. Connect an API endpoint
3. Create a Slack app
4. Test the “Hello World” Bot
5. Implement the Dad Jokes
6. Security enhancement
7. Delayed response hacking
8. Extra credit challenges

During this tutorial, you will use two interfaces. One in Slack and the other in AWS. I recommend leaving them both open in two different browser tabs or windows to make it easy to jump back and forward

Step One: Create a New “Hello World” Lambda

Open your AWS Console and navigate to Lambda. Click the Create Function button to create a new function.

We will “Author from scratch”, but Lambda has a number of blueprints available that include sample code and presets for a wide range of common use cases, and a repository of Lambdas you can instantly deploy without any customisation.

After you select “Author from scratch”, give your function a name. This name is up to you and is only used to help you find the function again in the future. You can call it anything you want. I’m calling mine “SlackDadJoke”.

Select Python 3.6 or higher as the Runtime, but don’t worry about the Permission section. Lambda will automatically create the execution role you need (though if you know what you’re doing, feel free to choose or create your own).

Click the “Create Function” button and wait a few seconds as Lambda provisions the resources you’ll need. After about 10 seconds you should get a congratulatory message and the Function will be open for editing.

Scroll down to the code editor and paste in the following code:

import json

def lambda_handler(event, context):

    return {

        'statusCode': 200,

        'body': json.dumps({

            'text': 'Hello World!'

        })

    }

This simple handler instantly returns a success status (200) and a JSON body that has just one attribute which is the text response “Hello World!”.

Slack will accept plain text here, so we could just return the string “Hello World!” rather than the JSON. Returning JSON lets us get quite complex in our response, so for extra credit read the documentation on the response and have a play with things like formatting and attachments.

Click the button at the top of the page to save your work.

Step Two: Connect an API Endpoint

For now, the only way to invoke our Lambda is to use the inbuilt test functionality. We won’t be covering that in this tutorial so we’ll connect an API endpoint. Then we can trigger the Lambda from a browser.

Above the code editor, you’ll have seen the Designer. This section lets us attach other services like an API endpoint. Open the Designer and click on “API Gateway” in the left column. This will instantly attach an API Gateway to our Lambda.

An API Gateway needs configuring so a new panel will have appeared directly below the Designer. Scroll down and set the Security to Open. This makes the API publicly available which means anyone with the URL can invoke our Lambda. For now, this is OK. In Step Six we’ll implement tight security. Click the Add button to finish configuring the API Gateway.

Make sure you now save your function again using the Save button at the top of the interface. This will update the API Gateway configuration panel and will give you a URL.

Open this URL in a new browser tab and, if everything is working you will get the “Hello World!” JSON payload. If you don’t get the expected result, go back to the start and review each step.

Step Three: Create a Slack App

Let’s attach our brand-new Lambda to Slack. We do this by creating a new “app” in Slack and configuring it to call the API Gateway we created above.

Remember, if you don’t have permission to add new apps to your company Slack account, it’s free to create a new Slack account and invite your friends.

Create a new Slack app by going to https://api.slack.com/apps/new. Slack will ask you for just two things: a name for your app and the Workspace (account) to install the app into. I’ve called mine “DadJoke” and have installed it in my personal workspace.

Slack will ask you what features and functionality to add. We are creating a Slash Command so go ahead and click on that button. On the following screen, you’ll be asked if you’re creating a new command or using an existing one. Create a new command.

The next screen lets us configure the entire slash command by asking just five questions. Set the command you want people to use. I’ve used “dadjoke” so that when people type “/dadjoke” they’ll get a joke.

In the Request URL, paste the API Gateway URL from AWS. It will look something like this:
https://randomcode.execute-api.ap-southeast-2.amazonaws.com/default/SlackDadJoke

Enter a short description so everyone knows what the command does. E.g. “Tell everyone a dad joke!”, and turn on the “Escape channels, users and links” checkbox. We don’t need this right now, but you will need it if you want to complete the extra credit challenge in Step Seven.

Click the Save button and you should get a success message from Slack. If you don’t, go back to the start of this step and double check your work.

We will now customise our bot. In the left-hand navigation click “Basic Information”. Scroll down to the “Signing Secret” and use the Show button, then copy the secret somewhere. We will need it for security in Step Six. Further down you will see the “Display Information”. Set the app name to something like “Dad”, set a description, pick a background color and upload an icon (Slack can be a bit picky about this icon, so follow the on-screen prompts)

Step Four: Test the “Hello World” Bot

You would expect that by selecting your workspace in Step Three, the command would be instantly available. But it isn’t. We need to install it.

You’ll see “Install app” in the left-hand navigation in the Slack UI. After clicking the navigation you’ll be able to click a button to “Install app to Workspace”. Go ahead and click it, then Authorize the installation on the subsequent screen.

If you accidentally closed the browser, you can find your app by going to “Your Apps” or clicking here: https://api.slack.com/apps

Your app is now installed in your Slack workspace. Slack will be showing you an OAuth token. Ignore this as our app doesn’t need to connect to Slack via oAuth.

Jump into your workspace, find a quiet corner and type “/dadjoke”. As you type, Slack will show you autocomplete and tell you what the command does from where we set it up in Step Three.

Finish the command, hit enter, and your Lambda should execute. You’ll see the Hello World message appear in Slack. This is what Slack calls an “Ephemeral” message. Only you can see it.

Congratulations! You now have a complete and working Serverless Slack Bot. But where are the jokes? And how do we make sure everyone else can enjoy the LOLs? Nobody needs a bot that just says “Hello World” right?

Step Five: Implement the Dad Jokes

Would you be surprised to know that someone has created an open API for dad jokes? Probably not. In fact, they’ve also built a Slack app. But using that would be cheating. They even have an endpoint especially for Slack, but again: cheating.

If you make a GET request to their endpoint, with an Accept header that says you want plain text (text/plain), you’ll get back a random dad joke. Try it from Postman or any other REST client: https://icanhazdadjoke.com/ (If you use your browser, it will give you back HTML as you can’t set the ‘Accept’ header. The API will also respond to requests for JSON).

We’ll use the Python “request” library to make this call. AWS provides the requests library and others via the botocore.vendored package.

This code updates the Lambda handler to return the joke to Slack and make it visible to everyone in the channel:

import json

from botocore.vendored import requests

def lambda_handler(event, context):

    joke = get_joke()

    return {
        'statusCode': 200,
        'body': json.dumps({
            'text': joke,
            'response_type': 'in_channel'
        })
    }

def get_joke():

    url = 'https://icanhazdadjoke.com/'
    headers = {
        'Accept': 'text/plain'
    }
    result = requests.get(url, headers=headers)

    if result.status_code == 200:
        return result.text

    return None

Paste the above code into the Lambda editor (remove the old code first) and hit the Save button. There’s no need to update anything else as the API Gateway still links to this Lambda, and the Slack app still calls the API endpoint.

Now in Slack you should be able to type “/dadjoke” and get a joke on demand.

Step Six: Security Enhancement

Of course, your API is still open to the world. We need to get some security implemented. Slack has this sorted, so we just need to implement their request verification. In Step Three you will have copied your Signing Secret somewhere. We will put this in an environment variable in the Lambda interface and refer to it from our code.

Scroll down below the code editor and find the Environment Variables section. Create a new key called ‘SIGNING_SECRET’ and paste the copied value.

If you forgot to keep your Signing Secret, you can go back to the Basic Information panel in your Slack app interface and get it again.

Using the request headers, the request body and this Signing Secret we can confirm that the request came from Slack. Details on the process are here: https://api.slack.com/docs/verifying-requests-from-slack. An implementation of this verification process is below and is also included in the final code at the end of this tutorial.

def verify_request(event):

    # Refer to this document for information on verifying requests:
    # https://api.slack.com/docs/verifying-requests-from-slack

    signature = event['headers']['X-Slack-Signature']
    req = 'v0:' + event['headers']['X-Slack-Request-Timestamp'] + ':' + event['body']
    request_hash = 'v0=' + hmac.new(
        os.environ["SIGNING_SECRET"].encode(),
        req.encode(), hashlib.sha256
    ).hexdigest()

    return hmac.compare_digest(request_hash, signature)

Step Seven: Delayed Response Hacking

Finally, you’ll notice that whenever you trigger a joke in Slack, your slash command is visible to everyone in the channel. This is a ‘feature’ of Slack, but there’s a way to avoid it. Rather than responding immediately with the joke, we can post it to Slack as a delayed response (even if the delay is microseconds).

This delayed response can be very useful. You have up to 30 minutes to send the delayed response, so this would give you time to execute several long-running processes – and even include some time-limited human interaction. We’ll just use it to avoid showing the slash command in the channel.

The payload from Slack includes a parameter called “response_url”. We can POST to this URL up to five times, so long as we are within the 30-minute period. The body of the POST should be the same JSON we were using in our Lambda return.

When we use the delayed response, we still need to respond immediately with a 200 OK – just with no content. If we don’t do that, Slack will tell the user that their command failed – even if we’re intending to send a delayed response.

You might be thinking to yourself, “how can we send a delayed response after we return from the Lambda function?”. Luckily, Slack isn’t fussy so we will send our delayed response before we send the immediate success message. Other options include using AWS Step Functions and a second Lambda. But that’s overkill for our purposes.

    # Send the joke to the channel as a delayed message
    request = urllib.parse.parse_qs(event['body'])
    url = request['response_url'][0]
    response = {
        'text': joke,
        'response_type': 'in_channel'
    }
    result = requests.post(url, json=response)

Wrapping everything up, here’s the final code. Paste this into your Lambda, hit the Save button and type “/dadjoke” in your Slack account.

import json
import os
import hmac
import hashlib
import urllib.parse
from botocore.vendored import requests

def lambda_handler(event, context):

    # Make sure this request has come from Slack
    if not verify_request(event):

        # If you're having problems, uncomment this line and check the cloudwatch logs:
        # print(json.dumps(event))
        return {
            'statusCode': 401
        }

    # Get a joke from icanhazdadjoke.com
    joke = get_joke()

    if not joke:
        return {
            'statusCode': 200,
            'body': json.dumps({
                'text': 'No jokes are available at this time',
                'response_type': 'ephemeral'  # Only tell the requester
            })
        }

    # Send the joke to the channel as a delayed message
    request = urllib.parse.parse_qs(event['body'])
    url = request['response_url'][0]
    response = {
        'text': joke,
        'response_type': 'in_channel'
    }
    result = requests.post(url, json=response)
    # If the delayed response was successful then we'll send an empty success message to Slack

    if result.status_code == 200:
        return {
            'statusCode': 200,
        }

    # If the delayed response failed for any reason, we'll send the joke in the API response
    return {
        'statusCode': 200,
        'body': json.dumps({
            'text': joke,
            'response_type': 'in_channel'
        })
    }

def get_joke():
    url = 'https://icanhazdadjoke.com/'
    headers = {
        'Accept': 'text/plain'
    }
    result = requests.get(url, headers=headers)
    if result.status_code == 200:
        return result.text
    return None

def verify_request(event):
    # Refer to this document for information on verifying requests:
    # https://api.slack.com/docs/verifying-requests-from-slack

    signature = event['headers']['X-Slack-Signature']
    req = 'v0:' + event['headers']['X-Slack-Request-Timestamp'] + ':' + event['body']
    request_hash = 'v0=' + hmac.new(
        os.environ["SIGNING_SECRET"].encode(),
        req.encode(), hashlib.sha256
    ).hexdigest()

    return hmac.compare_digest(request_hash, signature)

Step Eight: Extra Credit Challenges

If you want some extra credit, here are some challenges:

• When someone types “/dadjoke @username” have your bot mention the username in the response so it’s properly highlighted and they get an alert:
  “Hey @username, what do you call a pile of cats? A meowtain.”
• Use a serverless data store to remember the jokes already told. If you get back a duplicate, request another until you get a new joke.
• Use what you’ve learned to implement another data source – like your local weather.

About the Author

Rick Measham has been telling dad jokes for over 11 years. When he’s at work he runs MessageMedia’s Web Portal and brands teams with the philosophy of “hire good people and get out of their way”. In his spare time, he’s a part of the team that run events like The Art of Bulls**t and Mixup Melbourne/Mixup Sydney.

The post Writing a Serverless Slack Bot appeared first on Sinch MessageMedia.

Today we’re talking about Familiar Sender – a feature that threads messages for a recipient so that they’re all sent from the same number.

Familiar Sender ensures all communication sent to a customer is using the same sender number. This allows the number to be associated with an identity on the customer’s handset and once those identities are formed, the conversation can continue without break in trust.

Let’s consider a multi-SMS application where you send appointment reminders to your customers. “Hi John, it’s Alice from ABC. We’d like to..”. Fantastic, you’ve established your identity. Now you’d like to send John another reminder a week later. He receives the second appointment reminder, but he finds it a bit strange and confusing that he’s got appointment messages coming in from different numbers. A different sender number means verifying yourself again which means a different conversations chain. Can you see where this leads to?

Familiar Sender allows you to grasp the opportunity to have a single recognized point of contact and enables customers to access historical information. Instead of having send-outs like “Hi, it’s Alice from ABC..”, you can have something along the lines of “Hi, it’s us again..”.  A simple yet effective way to build trust and communicate more confidently with your customers.

The post Shape your messages into a conversation appeared first on Sinch MessageMedia.

Data-cleanliness can be a tedious task to perform and is often seen as daunting and can reduce the speed to market for customer engagement activities. As a developer, chances are you would be spending quite some time writing a script that would do the dirty work. But what parameters will the filtering be based on? Same delivery address or will there be a window of time? Will it run on every broadcast?

It is now easier than ever to avoid the data-cleanliness obstacle by using our latest feature: De-Duplication. De-Duplication helps businesses avoid having to undertake data cleansing before commencing a send. We write all the code for you and take care of automatically detecting and withholding messages deemed to be duplicates. If you are already using MessageMedia, there’s no need for changes to your application, just an account configuration change by Support. And that is it.

This isn’t an exclusive offering by MessageMedia. However, we like to do things a bit differently through the use of a 24 hour window – if a business sends a message to the same customer with the same content within a 24hr period, the subsequent message(s) will be withheld and rejected. In technical terms, a “rejected” error code status is returned in your response and essentially, you’ll be checking for this specific status instead of writing a script to filter out duplicates. Below is a code snippet from the Node.js messages SDK demonstrating how this can be achieved:

controller.createSendMessages(body, function(error, response, context) {
    console.log(response['messages'][0]['status'])
});

SMS still has its own valuable place in the messaging world. Depending on your industry and use cases, SMS is often the go-to channel for reaching your customers. With De-Duplication enabled, you can systematically assess duplicate records with MessageMedia returning a unique error and including that detail within message reports. Thus, ensuring the message is delivered, but its importance is not diluted by receiving duplicates.

The post Putting an end to duplicate sending appeared first on Sinch MessageMedia.

The most popular standard of encoding is referred to as GSM (Global System for Mobile Communications) and contains all Latin characters, digits and several special characters. An SMS sent using the GSM alphabet can contain up to 160 characters.

Then there’s the Unicode UCS-2 standard which allows you to go beyond the GSM character sets in order to support a wide range of languages and technical symbols. For instance, if you’d like to send an emoji, you can do so, but it will be sent as a UCS-2 message. If you send an SMS message that contains even a single UCS-2 character, the length per message is reduced to 70 characters.

Now, why am I telling you all of this? Take a look at this table:

The table above illustrates the majority of the apostrophes in the UCS-2 character set. Wait, it gets better. The below table shows the different whitespaces that exist in the UCS-2 character set.

Often these characters – an apostrophe (❛), or a Unicode whitespace – slip in and are hard to identify and eventually cause your message to split. Remember how a message which is encoded in UCS-2 has a maximum of 70 characters? Well if you were to send a message with 150 GSM-7 compatible characters and a single USC-2 character, then your message will be split into 3 messages leading to 3 outgoing messages against your account and thus tripling the cost.

Enter Character Converter. This feature re-interprets the ‘unusual’ characters as one that’s supported via GSM-7 – the characters won’t be exact but will more than communicate the original intent. Best part? It automatically detects and changes the characters for you once it’s turned on and will ensure that the maximum number of characters are fit into your SMS.

Don’t be fooled by innocent-looking UCS-2 characters. Be wise and aware of where your money is being spent.

The post How a single whitespace can triple your cost appeared first on Sinch MessageMedia.