Simplifying the Conversation Model
The ensure() action behaves like a combination of response() with a Request act and an expect() all in one. Even better, a single ensure() call can achieve the same thing as several response()/expect() pairs.
In order to appreciate the full power of ensure(), consider the three response()/expect() pairs we defined to ask for and receive the trip destination and dates:
| | response( |
| | response=request_destination_apla, |
| | act=Request{ arguments = [ |
| | scheduleTrip.arguments.destination]} |
| | ) |
| | destination = expect(Inform, InformDestinationEvent) |
| | |
| | response( |
| | response=request_departureDate_apla, |
| | act=Request{ arguments=[ |
| | scheduleTrip.arguments.departureDate]} |
| | ) |
| | departureDate = expect(Inform, InformDepartureDateEvent) |
| | |
| | response( |
| | response=request_returnDate_apla, |
| | act=Request{ arguments=[ |
| | scheduleTrip.arguments.returnDate]} |
| | ) |
| | returnDate = expect(Inform, InformReturnDateEvent) |
Although each response() clearly maps to a question that Alexa is asking and each expect() lines up perfectly with the user’s response to those questions, it is a bit verbose. Compare it with the following ensure() action that can be dropped into the sample dialog in place of the response()/expect() pairs:
| | ensure( |
| | RequestArguments { arguments = [ |
| | scheduleTrip.arguments.destination], |
| | response = request_destination_apla }, |
| | RequestArguments { arguments = [ |
| | scheduleTrip.arguments.departureDate], |
| | response = request_departureDate_apla }, |
| | RequestArguments { arguments = [ |
| | scheduleTrip.arguments.returnDate], |
| | response = request_returnDate_apla } |
| | ) |
That’s almost half as many lines of code! But what does it do?
The ensure() action takes a variable list of RequestArguments, each one declaring that a given conversation argument (destination, departure date, and return date) should be required and that the conversation should ensure that they are provided. The response parameter specifies the APL-A document that is used by Alexa to ask the user for the attribute, the same as the parameter used with the response() action.
What’s more is that unlike response()/expect() pairs, you do not need to define multiple dialog samples when using ensure(). When the conversation model is processed in the AI engine, a single ensure() will be expanded into multiple variations of the dialog. So, in fact, ensure() achieves much more than response() and expect().
The one advantage that response()/expect() pairs have over ensure(), however, is that they are more clearly aligned with the structure of the actual conversation. ensure(), on the other hand, is a bit more obscure and magical. But if you can trust that ensure() will do the right thing, it will save you a lot of coding in defining your conversation model.
Our conversation model is now complete. But there are a few loose threads we need to tie up before we can deploy it and try it out. Specifically, we need to define a few APL-A templates that were referenced in various response() actions as well as create the backend fulfillment code that sits behind our scheduleTrip() action. Let’s tackle those APL-A response templates next.