Follow these simple steps to get it to work fast:
Using Amazon Lex console, make sure you do this using V2 and make sure you pick the correct region.
Create a new bot based on the BookTrip Sample Amazon provides. Call the bot MyBookingAssistant.
This configuration is used on the parameter “Name” of the block that instantiates the chatbot on “SSChatbot” module
Publish the bot and give it the alias name MBA_OS_DEV.
This configuration is used on the parameter “Alias” of the block that instantiates the chatbot on “SSChatbot” module
On Amazon Identity and Access Management (IAM) console create a user called lexbot with programmatic access and grant the existing policy AmazonLexRunBotsOnly to retrieve the AccessKey and SecretKey for this user.
On your OutSystems environment publish the “Self-Service Chatbot” and its corresponding Demo.
This module has dependencies towards “Amazon Lex” which will need to be installed on your environment.
Create a new application from scratch and use the AWS Intent Processor template. To minimize configurations, call the new module you’re creating AWSIntentProcessor.
You may skip this step if you have already done the quick tutorial for the Alexa and you want to re-use the intent processor.
If you have not used AWSIntentProcessor as the name of the module, you need to configure this module name on “SSChatbot” module’s site property IntentProcessorModuleName.
On ServiceCenter go to “SSChatbot” and configure the RegionName, AccessKey and SecretKey (from step 4).
You’re ready to test “Self-Service Chatbot Demo” application.
Go ahead and tell Jarvis “I need to book a room”!
The Self-Service Chatbot accelerator provides you with the Chatbot web block, ready to be used. When you’re using this block, you’ll be prompted for an input parameter with the following data:
BotDisplayName: the name that will appear on the messages sent by the bot itself.
Building a sample screen using our accelerator will have this look when invoking the block:
And the output, when using the Preview On Devices will look like:
So, are we done? We are close, but not yet. The purpose of using our own self-service chatbot is to process our users requests without having to involve any human intervention – at least for this interaction. We are currently accepting the inputs, processing them and our bot gives the outcome to the user – and to us, developers. So, what is missing? Processing the outcome.
In order to process the outcome, we will use a broker. This broker is developed by us, and we are calling it the “intent processor”. Why? Since it processes intents, Intent Processor seems like an appropriate name.
The Self-Service Chatbot comes with a Service Template as a starting point from where you can build this broker.
The SSChatbot module is pre-wired to a Intent Brooker called AWSIntentProcessor, so if you change the name of the module, you need to reconfigure the IntentProcessorModuleName on SSChatbot's site properties.
NOTE: If you have previously created an Intent Processor module in the scope of Alexa, you can re-use it by pointing SSChatbot to this pre-existing Intent Processor.
Our broker receives the name of the intent, a dictionary list (list of key-value pairs) and returns if the outcome was successful or not. With this, in laymen terms, we just parse the IntentName and proceed to invoke the corresponding server action to process the request. This is a very simple example of how to process the intent, to parse the input (DictionaryList) and create a database record for it.
Now, why the dictionary list? The answer is simple: currently the platform doesn’t support lists of “key : value” pairs in JSON responses when the key is variable – like a dynamic list -, as AWS returns to our integration, so we need to use a parser to convert the “key : value” to a list of “Key” : <actual key name>, “Value” : <key value>. Then we need to filter out the slots based on our expected keys and then map to the structure – or just do what you need to do with them.
Whenever you want to modify your business logic – or add new intents -, just modify the IntentProcessor REST endpoint. Quick and easy, right? Right. You are now ready to go!
REITERATING THE NOTE: don’t forget to configure your IntentProcessor endpoint!
Now, an infamous Post Scriptum: in the image below, we are showing you what the Accelerator does when the intent is ready to be fulfilled. We check the AWS response and, if the DialogState is “ReadyForFulfillment”, we invoke our Intent Processor – and this works... kind of. When does this work? This works when the final message is controlled by us, the developers (so there is no response configured in the AWS console). If you want to have a response configured, you will need to keep track of the slots “saved” when the ConfirmIntent state is returned and then just process over them when the “Fulfilled” (or ElicitIntent, depending on your bot configuration) is returned.