Online IVR Tutorial
Basic Features

This section describes the basic features of Xtend IVR script language. For detailed information about the commands and their syntax please refer Commands and Functions. The language consists of Internal Commands, Loop Statements, Conditional Statements, Arithmetic Expressions, Unconditional Jumps, Plugins and External Program Execution.

Internal Commands

Internal Commands are those commands, which are implemented internally by the Xtend IVR engine. To use these commands the user is not required to install any additional Plugins. For more information about the internal command set supported by the Xtend IVR engine, please refer Language Reference. There are some built-in functions available for string manipulation and for character conversion. In addition, the language supports user-defined functions also.(For more information refer Plugins)

Loop Statements

The only loop statement currently supported by the script is the WHILE... ENDWHILE. You can nest any number of WHILE...ENDWHILE inside another WHILE...ENDWHILE statement. You can break out of an infinite loop by calling the BREAK command or by using the GOTO command.

Conditional Statements

Currently the language supports two variants of IF statements.


First one is used to jump directly to a label specified after the THEN clause. Second type is used to execute a block of code inserted inside the IF...ELSE...ENDIF clause.Third one which represents the IF...ELSEIF ladder executes the block which succeeds the IF, ELSEIF or ELSE condition.

Arithmetic Expressions

Language supports any valid arithmetic expressions for Addition, Subtraction, Multiplication and Division such as:

$a = $a + $b
$a = $a+ $b * $c

Arithmetic operations are permitted only on numerical values. For more information please refer Language Reference.

Unconditional Jumps

You can use the GOTO command to unconditionally jump to another statement. GOTO can be used anywhere and at any time. That means you can even use it inside a WHILE...ENDWHILE loop to break from the loop.


There are two methods by which we can execute an external application from the Xtend IVR script. First method is to use the RUN command, which is the recommended method and is discussed in more detail at the Executing External Programs. The second method is called the Plugin mechanism.

Commands, which are not documented as an internal command, can be called as Plugins. That means if you mistype an internal command, the script parser will report that the specified Plugin was not found. The engine will search for the Plugins under the Plugins directory and if not found would report an error.

The syntax for a Plugin and a RUN command is different. The difference lies in how the parameters are passed to the external application and how the status values are returned to the script. Under a RUN command it is the responsibility of the developer to pass the $VarFile as one of the parameters. But in the case of Plugins the Xtend IVR Engine will automatically pass $VarFile as the first parameter. This parameter is hidden from the developer. So whatever parameters the user passes, it will all come after the first hidden parameter which is the $VarFile. Hidden in the sense that it is automatically passed by the Xtend IVR Engine. Plugins can also take the syntax of a function call.


Lets see how a Plugin can be used inside a script.


The above example shows how to use the MsgBox Plugin, which is shipped with the Xtend IVR Toolkit. The first example uses the most common syntax. The second example shows the Plugin as a function call. There are some reserved variables used only by the Plugins. They all start with the $Plugin key word. These variables are


If you are using the Plugin on the right side of an assignment expression you should always set the variable $PluginReturn to the value you are returning from the Plugin. Xtend IVR Engine will automatically copy the contents of the $PluginReturn to the variable on the left side of the assignment expression.


$a = SomePlugin $param1 $param2
$a = SomePlugin($Param1,$Param2)

In the above example variable $a is assigned the value found in the variable $PluginReturn after the Plugin, SomePlugin, is executed.

$PluginParamCount contains the number of parameters passed to the Plugin. In the above example $PluginParamCount variable will contain the value two.

Xtend IVR Engine will automatically copy the Plugin parameters to the variables $PluginParam1, $PluginParam2, …, $PluginParamN, where N is the last parameter in the sequence. You can also retrieve these parameter values as run time arguments inside your Plugin module. But the first parameter will always be the value of the $VarFile. In the above example $PluginParam1 will contain the value of $Param1 and $PluginParam2 will contain the value of $Param2.

Executing External Programs

This is the mechanism by which the developers can integrate their module with the Xtend IVR. You invoke an external program by using the RUN command. The RUN command takes multiple parameters. But the first parameter should always be the executable program.


RUN "sample.exe" $VarFile

Where sample.exe is the executable program developed by you. If you don’t give the absolute path, Xtend IVR assumes that the module is residing inside the script directory (Directory where the script (.dt) file was loaded from). If the module is not found in that directory, Xtend IVR engine will report an error. Suppose you wish to execute a Java class, then the command you should give is given below....

RUN "c: \ jdk1.2 \ bin \ java.exe myclass.class" $VarFile

Another variant of the RUN command is available which has got a different syntax. It is given below ...

! "c: \ jdk1.2 \ bin \ java.exe myclass.class" $VarFile

Both mean the same thing. Except that the latter starts with an "!" (For Clipper, dBase and Foxpro programmers, this would not come as a surprise). Now an important question arises as to how does Xtend IVR communicate with the external program? The answer is through the $VarFile. When the Xtend IVR engine finds a RUN command, it will create a temporary file and dump all active variables and their values to this file. The reserved variable $VarFile contains this file name and an external program can open this file and read all the variables and their values. They can change the values within the module and can re-write to the same file before they exit. The Xtend IVR engine will re-read this file and will update the active variables. You can also introduce new variables by appending the variable and its value to this temporary variable file. This temporary variable file is written in a special format and the user has to be careful when modifying the file. The contents of a sample temporary file are given below.

$VarFile temp\0.var
$ScriptFile test.dt
$DeviceId 0
$RecordFile temp\0.rec
$Ring 1
$ExitCode 0
$Error Unable to open Data File
$RETRY 1000
$Date 02/03/2000
$Time 11:00:40
$Timeout 0
$HallTicketNo 12345
$Sample c: \ ivr \ sample.mdb ; ADDRESS ; ; ; MDB

As you can see every line begins with a "$" sign followed by the actual variable name then a space and finally the value of the variable. Variables and their values are defined in a single line, which means that, there should not be any new line character within the variable definition other than the line separator. There should not be any empty line in between two variables. If there is any empty line then the Xtend IVR engine will take it as the end of the variable list. The Xtend IVR engine will ignore everything below that empty line.

* Every variable should start with a "$" sign.
* Value of the variable should be in a single line. If the value overlaps to the
second line, the Xtend IVR engine will ignore the overlapped value.
* Variable name should not contain any spaces.
* Variable name containing a "." has special meaning and should be avoided.
There are some variables pre-defined (Reserved variables) by the Xtend IVR, which the user should not modify. These variables are modified by the Xtend IVR itself and contain information regarding the origin of the call and the state of execution of the script. These variables are...

$AppPath : Gives the path where Xtend IVR is installed.
$CallType : Type of call - Normal, Redirect, RedirectBusy, RedirectNoReply or RedirectUncondititional.
$Cli : The caller line identification that was received.
$Date : The current date expressed as mm/dd/yyyy.
$Debug : Will be 1 if running under Developer mode and 0 if running under Standard mode.
$DecimalPrecision : Sets the precision for all floating point numbers used by Xtend IVR.
$DeviceId : A unique ID for each incoming line.
$DeviceName : Name of the currently active channel/port in the voice driver.
$DisplayPrefix : The contents of this variable will be automatically added to all the display commands.
$Dli : Device Line Identification.
$DriverName : Name of the Voice driver used.
$Error : Contains the error messages if any from the previous operation.
$ExitCode : The exit code of program executed by the last RUN command.
$InputMode : Mode of Input - Pulse, Tone or Speech Recognition.
$LastKey : The last key pressed by the user.
$LogFile : Name of the active Log file.
$PluginParamCount : Number of arguments to the Plugin.
$PluginReturn : Return value from the Plugin.
$RecordFile : Path of the recorded file.
$Ring : The number of times the phone has rung.
$Rli : Redirect line Identification when the call is diverted.
$ScriptFile : The name of the script.
$Time : The current time expressed as hh:mm:ss.
$Timeout : The amount of time remaining for script termination.
$VarFile : The name of parameter file containing the list of variables. 
$WavDir : Content of variable gives the wav file directory if not found in any of the current directory, ivr directory, wave directory or in the script directory.
$WavPass : Password of the encrypted wave file.
$XivrVer : Content gives the version of Xtend IVR. 


Developers are advised to use the RUN command for executing an external module. The Plugin concept is introduced for adding additional functionality like Database Access, Debug Support etc.

If the plugin return value is non zero then the execution will automatically jump to the ONSYSTEMERROR label.