| Invores ReProduce |  |
| Invores ReProduce | |
|
|
PeriPro to VoiceXML Conversion
The Invores approach to conversion of PeriPro to VoiceXML uses software tools that partially automate the conversion process. These tools have been developed by Invores Systems, whose staff includes the inventor and developer of PeriPro.
Original PeriPro source code is stored as an ASCII file in a format that is equivalent to an XML document. In order to convert it, a series of automated analyses decompose the PeriPro source code into its components. After decomposition, a multi-phase analysis abstracts component details and matches them against a set of different templates. The templates can be refined and expanded, so that the conversion process can increase its code coverage over time. A template match results in an equivalent VoiceXML document, with the details filled in from the PeriPro application.
One challenge to PeriPro conversion comes from the two part approach that VoiceXML takes to presentation and logic. VoiceXML divides an application into client-side presentation and server-side logic. Although PeriPro applications tend to have more client-side logic, they actual also divide into IVR and host-access components. Using the approach of VoiceXML wrappers, the amount of extra server logic can be minimized. By viewing the web server as equivalent to the "host" in PeriPro terms, an application goes to the host when it needs data. If the data comes back in a VoiceXML wrapper, then full VoiceXML document generation with accompanying server logic rarely needs to be created. This limits full document generation to those cases where VoiceXML has no allowance for client-side computation of a value, such as the attributes of a <property> element.
In general, the bulk of any PeriPro program should be programmatically decomposable into client and server components, with the client components convertible to VoiceXML in a semi-automated fashion. The Invores tool performs this decomposition to note the areas where server logic is needed. This provides lines along which to split the application. Then the client-side code is converted to VoiceXML, with a number of annotations that must be examined in more detail by a developer.
As an example this approach, we have taken the NumDemo application (selected solely because it is familiar to every PeriPro developer and available on every PeriPro installation), and run it through the analyzers to provide hints of the conversion process. The the results can be accessed by selecting the Available menu item. The displayed table lists the available converted applications, and the links provide access to the high level summaries, and to the conversion tracker.
The PeriPro program is input to a series of analyses which produce several files per PeriPro container. All files are saved in a directory which is named for the PeriPro program. In general, there is one directory per converted PeriPro program. One set of files produced by the Phase 1 analysis is the set of proto-VoiceXML files. There is one of these files per container. It represents the container as a pseudo-VoiceXML form. It is not a syntactically correct VoiceXML form, but it represents the essence of the container, with input requests as fields, spoken output as prompts, and logic as if-elseif-else constructs.
Phase 1 also produces a set of HTML files, one per container, to be displayed by a standard browser. These files are linearized representations of the PeriPro program containers. They show the details of the program without requiring any special display software. They provide a reference for the program logic, which can be used in subsequent phases.
In the conversion directory, a conversion tracker for the program provides hyperlinks to all the above files. This allows a developer to quickly move between the various representations of the containers. The conversion tracker in turn is linked from an overall document representing all the converted programs within a directory hierarchy representing a higher level group such as a department or an organization.
In this phase, the proto-VoiceXML files are modified to be syntactically correct VoiceXML forms. Logic which is outside of form items is moved to blocks or filled elements of fields or subdialogs. Additional form variables are declared and subdialog parameters and returns are identified. Logic which is associated with input repetition is moved to catch elements. The movement of logic is intended to create a form which flows in document order.
Phase 3 is a simplification phase where the sometimes verbose expressions in a PeriPro program are reduced to simpler VoiceXML expressions. For example, the PeriPro condition check:
LocalFolder.FifteenDigitNumber.FifteenDigitBreakdown.First2digitString.Firstdigit == \"3\" {And}
LocalFolder.FifteenDigitNumber.FifteenDigitBreakdown.First2digitString.Seconddigit == \"7\" "
is the same as
FifteenDigitNumber.substring(0,2) == '37'
In this phase, entire containers will sometimes be eliminated. This is often true of containers which manipulate dates. These tend to be complicated in PeriPro, but in VoiceXML reduce to calls on the built-in Date object. Common subdialog library functions can be identified at this phase.
This phase also identifies the host interfaces and replaces them with VoiceXML subdialogs. The intent is to represent as many of the host interfaces as possible with VoiceXML wrappers. This simplifies the host interfaces, minimizes the host logic required, and reduces the complexity of generated VoiceXML documents.
The host interface for a simple passwrod verification program might look like the following. The account number is sent to the host as the namelist parameter "InputCustAcct" and the associated password is returned in a VoiceXML wrapper that looks like:
<?xml version="1.0"?> <vxml version="2.0"> <form> <var name="passwd" expr="'1234'"/> <block> <return namelist="passwd"/> </block> </form> </vxml>
This design would parallel the logic of the unconverted program, which uses the account number as a key to retrieve the password from a file. An alternate approach would be to pass the account number and password to the host and have the host perform the verification. If there were some concern for the security of the connection between the IVR and the host, this could be done with the MD5 representation of the password, in order to avoid the excessive overhead of HTTPS. The returned wrapper might look like:
<?xml version="1.0"?> <vxml version="2.0"> <form> <var name="valid" expr="true"/> <block> <return namelist="valid"/> </block> </form> </vxml>
At the end of this phase, the number of containers will be significantly reduced.
This phase merges logically related individual forms into one or more VoiceXML documents. This process tends to consolidate subdialogs and fields and reduce the overall number of form items. Prompts tend to move into the fields with which they are associated. Catch logic is filled out. Looping requirements are accommodated. Fields that are associated can be treated as a unit. Common exits, both failure and success, are merged into form or document level catch handlers.
This phase produces the final converted document or documents that are the output of the conversion process. Unit testing can be done with host scripts which simulate the actual host interfaces and serve to define the interface to the converted documents.
This is an optional phase which can tailor the converted documents to a customer environment. Custom logging can be added. Additional customer subdialog libraries can be accessed. Customer conventions can be incorporated. Vocabulary files can be treated by convention. Design change suggestions, which can result from the detailed analysis of the preceding steps, can be applied here. The final result can be a very different application.
In order to go through unit testing without requiring any of the vocabulary files, the proto-VoiceXML files are generated with parallel synthesized and recorded prompts. Synthesized or recorded output is selected by the rcd variable. The vocabulary items retain the name they had in the unconverted program, with a vocabulary name being converted to a directory name, and item names converted to .wav file names.
When doing a conversion, Invores simulates the host interfaces with Perl CGI files. The CGI files accept the passed parameters and return either computed or constant information packaged as VoiceXML wrapppers. The wrappers serve to document the expected interface and the return documents. Any suitable web language, such as Java, may be used instead of Perl.
Copyright (c) 2005 by Invores Systems. For more information, contact info@invores.com.