| 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 also have client-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 conversion tools perform 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 have run it through the conversion analysis to provide hints of the conversion process. We have also taken a simple DNIS driver application and done the same. The results can be accessed by selecting the Examples 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 proto-VoiceXML file per PeriPro container. It represents the container as a pseudo-VoiceXML form. Depending upon the complexity of the container's logic, this file may or may not be a syntactically correct VoiceXML form, but it faithfully represents the logic of the container, with input requests as fields, spoken output as prompts, and logic as if-elseif-else constructs. Subdialog parameters and returns are identified, and logic which is associated with input repetition is moved to <catch> elements.
In this phase, all of the various types of PeriPro expressions, such as assignment expressions and conditional expressions, are converted to equivalent ECMAScript expressions. All variable names are derived from the PeriPro application, in order to provide continuity from the original application to the converted application.
Phase 1 also produces a set of HTML files, one per container, which can be displayed with 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 examined and modified if necessary to be syntactically correct VoiceXML forms. Logic which may be outside of form items is moved to <block> or <filled> elements of <field>'s or <subdialog>'s. The movement of logic is intended to create a form with items that flow in document order, and require a minimum of form item guard conditions.
Some areas of the application which are specifically examined at this point include:
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 be eliminated. This is often true of containers which manipulate dates. These tend to be complicated in PeriPro, but in VoiceXML they reduce to calls on the ECMAScript Date object. Common subdialog library functions can be identified at this phase.
This phase also fills out the identified host interfaces 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.
A host interface return wrapper is a VoiceXML document returned by the host which carries the values of a number of variables which are then set as properties of the subdialog form item variable through the namelist attribute of the wrapper's <return> element. A wrapper might look like the following.
<?xml version="1.0"?> <vxml version="2.0"> <form> <var name="valid" expr="true"/> <var name="balance" expr="'65.53'"/> <block> <return namelist="valid balance"/> </block> </form> </vxml>
Some areas in PeriPro that require host interfaces are:
This phase merges logically related individual forms into one or more VoiceXML documents. This process is concerned with the global flow of the application and consolidates forms into larger documents. Catch for global error handling logic is filled out. Common exits, both failure and success, are merged into dialog or document level <catch> handlers. PeriPro source/destination connector pairs are handled at this point, because they represent arbitrary unstructured jumps from one point of the application to another.
This phase also concentrates on placing all global information and functions into a single root document, and structuring the application in such a way that the root document is available to all forms that need it without generating extraneous execution contexts.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 provide stubs for the actual host interfaces and serve to define the interface to the converted documents.
This is an optional phase which can tailor the converted application to a customer environment. The phase will transform the application to in ways that will fully integrate it into the customer's execution environment. Subdialog libraries can be accessed. Customer conventions can be incorporated. Design change suggestions, which can result from the detailed analysis performed in the preceding steps, can be applied here. Efficency concerns can be addressed. Parts of the application can be moved to semi-static or dynamic VoiceXML. The final result can be a different application.
VoiceXML serves vocabulary files from a web server. The simplest way to convert PeriPro vocabulary files is to export them from PeriStudio.
In order to unit test without requiring any of the vocabulary files, converted VoiceXML files are generated with parallel synthesized and recorded prompts. Synthesized or recorded output is selected by an option in the root document. The vocabulary items retain the names they had in the unconverted program, with a vocabulary name being converted to a directory name, and item names converted to .wav file names. If the text of the vocaulary files is provided during conversion, it will be mapped to the file names, and will become the backup TTS responses for missing vocabulary files.
Invores uses its IQAT quality assurance tool for VoiceXML testing. A test plan is created, and then executed by the tool. The test plan exercizes all the logic paths of the application. Execution produces a log of the tests which is one of the converted application deliverables.
Invores normally simulates the host interfaces with 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. These are normal written in Perl, but any suitable web language, such as Java, may be used instead, at the customer's requests.
Copyright (c) 2005 by Invores Systems. For more information, contact info@invores.com.