In our first chat bot article, we talked about AI at a high level while introducing our CMC bot. This article provides more detail on how that bot was built. To recap, when designing a bot you’ll need to define the intents that the bot will support. An intent is a question or command that the bot is able to respond to. For our CMC bot, we want to support intents for interacting with CMC. The information the bot needs from CMC is available via force.com API calls.
Here are the main systems to integrate for the bot:
- Hangouts Chat
- Amazon Lex — we’ll use Lex for natural language understanding (NLU) in order to take the user’s text and use it to identify the intent of the request.
- CMC via Salesforce REST API
To break it down a bit further, the Hangouts Chat integration will be connected using a HTTP endpoint. On the AWS side, we’ll use a Lambda function, exposed via API Gateway, to provide this endpoint. The function will provide some Lex session management and call the Lex postText API with the text the user entered. The Lex intents are also implemented using Lambda functions. These Lambda functions are set up to call the Salesforce REST API for data and format the results for Hangouts Chat.
The diagram below shows the sequence for handling a MESSAGE event from Hangouts Chat. The MESSAGE event is sent by Hangouts Chat when the user sends a message to or mentions (using the @ feature) your bot. There are other event types as well but I won’t cover them here as they are generally less complicated than message handling.
The sequence diagram above shows the major components of the bot and the sequence of calls needed to handle a message request. The green components indicate services that are configured and the blue components are services requiring implementation code. These Lambda components will contain the logic for your bot.
More about Lambda
The Hangouts Chat Handler lambda function is the interface to Hangouts Chat. It will read the payload and determine the Hangouts Chat event type. For the MESSAGE event type, it will take the user’s message and send an Amazon Lex request with the user’s text. Since Hangouts Chat does not have a built-in plugin, you may need to maintain session information for improved performance. In order to maintain session information across requests, our handler uses a DynamoDB table in conjunction with the sessionAttributes property of the Amazon Lex payload.
Amazon Lex will determine what the intent of the user is and will call our CMC Lex Handler Lambda function with information about that intent. For example, if the user asked “what are my development stories?”, Lex would determine that this corresponds with an intent we have defined in Lex to manage agile story assignments. Lex will call the Lambda function with the story assignment intent and any other intent information it can gather. In this example, it would also provide information that the user has asked for a subset of all development stories.
CMC Lex Handler
The CMC Lex Handler function takes the Amazon Lex intent information and fulfills the requests with CMC data residing in force.com. The data is retrieved using a REST API to query for the relevant user data. Since authentication is needed, we have created a Salesforce connected OAuth app that the user must first approve before we can make API calls. Once the handler has retrieved the data, the results are packaged into the Lex response. The results take the form of a Hangouts Chat JSON payload.
With that done, the responses flow back through the system to ultimately respond with a message back to the user of the bot. We hope we give you a good understanding of the high-level architecture required to build a Hangout Chat Bot using Amazon Lex.
Do you want to learn more about the ever changing technology industry? Check out our Appirio Hub to see how we keep up with the newest trends!