Architectural components - Serverless Bot Framework

Architectural components

Core function

The Core AWS Lambda function transforms and forwards the user input and forwards a request compatible with Amazon Lex. Amazon Lex then determines which of the solution’s available bot microservices can answer the received request.

Weather forecast function

The weather-forecast Lambda function retrieves city weather data based on the “weather forecast” intent from the chat bot. This solution supports using an external weather API to get weather data. AccuWeather and OpenWeather are supported; however, you can add your own custom functions to support different API operations.

Note

This AWS Lambda function caches a call to Systems Manager to retrieve the weather service API key during the creation of the Lambda container. This reduces the costs associated with making calls to Systems Manager. However, if the Systems Manager key is updated, the Lambda function could still be using the old key. You can prevent this by modifying the code that retrieves the Systems Manager parameter into the lambda_handler function so that it refreshes every time a new call is made. Note that this modification might increase cost.

Order pizza function

The sample pizza ordering microservice demonstrates how to integrate a chatbot with a back end database, for example, DynamoDB, to provide a rich and personalized user experience. The order-pizza Lambda function handles all the logic of the pizza ordering microservice.

After Amazon Lex resolves an intent to order a pizza, the order-pizza function is initiated. A customer expresses their intent to order pizza using phrases such as: “order pizza”, “I would like to order pizza”, “pizza ordering”, “pizza”, etc.

The order-pizza function begins by extracting the customer’s email from the authentication data passed by the API Gateway. The email is used as the customerId (the unique identifier) to keep a history of customers’ orders and facilitate a personalized user experience. The function then runs the following flow:

  1. The function uses the customerId to look up the customer’s order history in the pizza-orders DynamoDB table. If the customer has previous order history, the function moves to step 2. Otherwise, it moves to step 3.

  2. The function asks the customer if they would like to place an order similar to their previous orders. If the customer answers “yes”, the function moves to step 4. If the customer answers “no”, the function moves to step 3.

  3. The function displays the pizza menu (retrieved from the pizza-menus DynamoDB table), and begins interacting with the customer, mimicking the way a human agent would interact with the customer to obtain order details (for example, pizza type, pizza size, number of pizzas, and type of pizza crust).

  4. Finally, the order-pizza function provides a summary of the order to the customer and asks for a confirmation to place the order. If the customer answers “yes”, the function generates a unique order’s number, stores the order in the pizza-orders DynamoDB table, and returns the order’s number, with the order’s total bill, to the customer with a closing message to end the interaction with the pizza-ordering microservice. If the customer answers “no”, the function ends the interaction with a closing message and does not store the order.

DynamoDB tables

The sample pizza ordering microservices use a DynamoDB table called pizza-orders. This table uses orderId, a unique and randomly generated ID (for example, 6320-375719-2099), for the partition key. A unique and randomly generated partition key is critical for uniform partitions and avoiding hotspots. Partitioning enables the application to scale and handle a large volume of requests. The table also uses a global index with customerId as the partition key, and orderTimestamp as the sort key. The index is used by the order-pizza function to look up the last order of a customer.

Book appointment function

This function prompts the user choose a date for an appointment and then confirms the scheduled date with the user. Note that this sample function does not save the appointment in a database.

The function is a replication of the built-in Book Appointment example in Amazon Lex. The following conversation is a sample interaction.

User: I'd like to make an appointment Bot: What type of appointment would you like to schedule? User: root canal Bot: When should I schedule your dental appointment? User: Tomorrow Bot: At what time do you want to schedule the dental appointment? User: 9 am Bot: 09:00 is available, should I go ahead and book your appointment? User: Yes Bot: Done.