Blueworx Voice Response includes three types of variable:
Use the AssignData action to set the value of a variable and the EvaluateData action to check the value.
System variables are global variables predefined by Blueworx Voice Response; they are available to any Blueworx Voice Response state table or prompt, but not to 3270 servers or custom servers. There are a large number of system variables, and they are documented in the Blueworx Voice Response for AIX: Application Development using State Tables information.
In the window for selecting system variables (shown in Figure 1), the variables are organized into groups, and listed by names that reflect those groupings. Each system variable also has a shorter numeric identifier preceded by “SV”. For example, the System : Call Info : Called number system variable (SV185) holds the number dialed by the caller (the called number passed by the switch), and the System : Call : Channel number system variable (SV165) holds the logical channel number of the channel currently in use by the application.
The values of some system variables are read-only (RO) and cannot be changed by an application; other system variables are read-write (RW) and their values can be set using the AssignData action.
Blueworx Voice Response supplies 60 read-write system variables for your use. These include 45 string variables (SV51 through SV80 and SV82 through SV96), each of which can contain up to 3583 characters, and 58 numeric variables (SV241 through SV298), which are implemented as 32-bit signed integers. These variables, like other system variables, are global within a state table and all the state tables nested within it. They are not accessible by state tables running on other channels. When the main state table starts, the string variables are initialized to null and the numeric variables are set to 0.
Local variables are variables that you define for use by a single state table. You provide the names that identify each local variable and define the type of the variable as a string of characters or as a number.
Local variables are not permanent. When the application is finished using a state table, it destroys the local variables you defined for that state table. The next time the application is invoked and uses the state table, it recreates the local variables.
The information the local variable contains is accessible to any action in the state table in which you defined the variable. But only that state table can access or alter the contents of the variable. If you use an InvokeStateTable action to call another state table, the local variables defined for the invoking state table are not available to the invoked state table, unless they are passed as parameters.
Input parameters are used to define variables received by programs, including prompts, 3270 scripts, custom servers, or state tables, from the invoking state table. When you use the InvokeStateTable action to invoke a state table, parameters are passed by reference to the invoked state table: in other words, they are global variables accessible to, and modifiable by, both the invoking and invoked state tables.
To pass parameters from a state table to another state table, prompt, custom server or 3270 server, click the Parameters pushbutton in the InvokeStateTable window, the PlayPrompt window, or the SendData and ReceiveData windows. This displays a window that lists the parameters required by the invoked state table, prompt, custom server or 3270 server, as shown in Figure 2. Parameters are passed by value to prompts, custom servers, and 3270 servers.
Some state table actions require parameters to tell them what to do. For example, the PlayPrompt has a Force Play parameter that specifies that the prompt must be played through to the end. Some parameters can be constant values or variables.