In all of the examples thus far, we have collected input but stopped
short of submitting the form fields to a back end script. In this edition
of the VoiceXML Developer, we will complete our pizza ordering application
by accepting the order, logging the transaction in an Access database,
and playing an order confirmation for the user. We will also utilize many
of the techniques that we have learned over the course of this tutorial to
create a high quality voice application.
It’s time to put all of the skills you’ve learned to use. We are going to
start by designing a dialog flow. Then we will develop an application architecture
and data model based upon the dialog flow. From the dialog flow, we will develop
our VoiceXML forms and add the back-end scripting capability that will allow the
system to recognize and create customer records as well as add a pizza order to a table
in an Access database. We will be using PerlScript for Active Server Pages
to perform SQL queries. We could have also used PHP, Cold Fusion, or JSP as well,
but I’m most familiar with Perl and prefer its text processing capabilities,
which come in handy when we’re parsing text representations of user utterances.
Creating a dialog flow
I used Microsoft Viso to create a dialog flow that contains all of the prompts,
decision trees, and processing instructions that are required for this application.
I’ve split the whole diagram into two separate pieces. The first piece contains the
flow for getting the customer’s phone number and address. The flow starts by playing
a greeting and is followed by a prompt asking the user for their phone number. The
system confirms the number by speaking the number back and asking the customer to
confirm that the number that was recognized as the number they uttered. If it’s not,
the system will prompt the customer for their phone number again until the customer
confirms that the correct phone number was recognized.
When the customer does confirm that we have the correct number, we submit the
VoiceXML form to a back-end ASP script, which uses we uses the phone number
as a key to look up the customer’s record in the Access database. If the number
doesn’t exist, we create one and prompt the user for their address. Their address
is recorded as a .wav file and submitted to another ASP script, which saves the file
and associates it with the customer’s record.
If the customer has previously
used the system to place an order and they provide the same phone number, the database
will ask the user to confirm the address or provide a new one. If the customer confirms
the address, we move on to the next dialog flow, which takes the customer’s order.
If the customer does not confirm the address, the system prompts the user to record
their address, and the resulting .wav file is saved and associated with their customer
This VoiceXML dialog is different from the others we’ve looked at so far,
because it is an ASP script rather than a static VoiceXML document. It mixes
PerlScript code that queries the Access database with VoiceXML content. The
first thing we do in this dialog is to query the database for the phone number
that the user provided in the telephone_number.vxml dialog.
If a record doesn’t exist, the resulting VoiceXML output will transition the
dialog to the record_address form, which records the user’s
address and submits it along with the phone number to save_address.asp.
If we did find an address that goes with the phone number, we transition the
dialog to the confirm_address form, which plays the address
and asks the user to confirm that it is indeed the correct address. If the user
says yes, we proceed on to the take_order.vxml dialog. Otherwise,
we transition the dialog to the record_address form so that
they can record a new address.
This is the final dialog, an ASP script, which creates a new record
in the Access database for the pizza order, and plays a thank you message
for the user. The form fields are retrieved from the ASP Request object,
and a bit of PerlScript code parses the input and saves the record via
an ADO transaction. At this point, because there are no other dialogs to
transition to, the call ends.
This is the dialog that is utilized by several other dialogs to get
confirmation from the user. It’s not very fancy, but it works and it’s better
than having to create three separate confirmation dialogs.
Well, so far we’ve created a dialog flow that provides us with a clear
idea of how the dialog is to take place. We took this dialog flow model
and solidified it into a high-level application diagram that contained
a number of VoiceXML and ASP files. Then we boiled each of those dialogs
into specific dialog elements. We are almost ready to write the code
for this application. But first, we need to create an Access data model,
and record the prompts. We’ll tackle that in the next edition of the
About Jonathan Eisenzopf
Jonathan is a member of the Ferrum Group, LLC based in Reston, Virginia
that specializes in Voice Web consulting and training. He has also written
articles for other online and print publications including WebReference.com
and WDVL.com. Feel free to send an email to [email protected] regarding
questions or comments about the VoiceXML Developer series, or for more
information about training and consulting services.