Variables Project and Workflow
This page discusses Project, Workflow, and internal variables.
Types of Variables
As can be seen in the Application Variables dialog box, Composer uses the following types of variables:
- System—Pre-defined system variables hold Project and application-related values. You cannot delete system variables, but applications can modify their values.
- User—User-defined custom variables that you create by clicking the Add button in the Application Variables dialog box shown below and selecting User. Applications can delete and modify these types of variables.
- Project_Variables in the Project Variables dialog box, which opens when you click the Access Project Variables button on the toolbar with the IPD in focus. Use Project variables when you need to share information across different workflows. Once defined, Project variables are accessible for use in expressions in Expression Builder.
For example, the Assign block allows you to assign entered values or values created in ExpressionBuilder to variables. Once defined, those variables are accessible for use in expressions in Expression Builder.
Block Properties as Variables
Many block properties can be specified as workflow variable. To name just a few:
- Target Block properties: Statistic, Timeout, Target Name (if type = Variable), Target Component Selected, Target Object Selected, Target Selected, Virtual Queue Selected, Virtual Queue
- Play Application properties: Resource
- Play Sound Block properties: Resource, Duration
- Play Message Block properties: Prompts > Values field in Prompts dialog box
- User Input Block properties: Prompts > Values field in Prompts dialog box. AbortDigits, BackspaceDigits, Collected Digits Variable, IgnoreDigits, Number of Digits, Termination Digits, ResetDigits, Resource, StartTimeout, DigitTimeout, TotalTimeout, Verification Attempts, Verification Data
- Set Default Route Block: Destination property
- Route Interaction Block: Statistics property
- Subroutine Block: Parameters property
- Stop Interaction Block Reason to Stop Interaction Property
- Context Services: All blocks have certain properties that allow you to select a variable.
- eService: All blocks have certain properties that allow you to select a variable.
Upgrading from Composer 8.0.2 or earlier
Prior to 8.0.3 release, Composer defined workflow variables in the data model of the SCXML application so they were required to be accessed by prefixing the name of a workflow variable with "_data.". For example, if you defined a workflow variable named var1, you would access it as _data.var1. Starting with 8.0.3, Composer defined these variables in the ECMAScript scope so the variable is accessed simply as var1.
Application Variables Dialog Box
To define/view variables:
- In the Properties tab, click opposite Variables under Value to display the button.
- Select Project, System, or User Variables.
- Click the arrow to display the selected type. An example dialog box is shown below.
To add a new variable:
- Click Add. Composer add a row for variable and generates a temporary name and number; for example: var7.
- Select the row and supply the Name, Type, Value, and Description fields.
- Click OK.
- system.Language—Holds the application language setting. The value should be the RFC 3066 language tag of an installed language pack. Examples of valid RFC 3066 language tags include en-US and fr-FR. This setting also acts as a default language for the application.
- system.CallID—Call identifier created by the switch. It is initialized from _genesys.ixn.interactions[system.InteractionID].voice.callid (voice only).
- system.DNIS—Number that the caller dialed. It is initialized from _genesys.ixn.interactions[system.InteractionID].voice.dnis (voice only).
- system.ANI—Caller's phone number. It is initialized from _genesys.ixn.interactions[system.InteractionID].voice.ani (voice only).
- system.LastErrorEvent—Stores the last error that was handled in a block.
- system.LastErrorEventName—Stores the name of the error that was handled in a block.
- system.LastErrorDescription—Stores the description of the last error that was handled in a block.
- system.WebServiceStubbing— Flag to control Web Services Stubbing (1 = ON).
- system.TerminateIxnOnExit—Used to automatically stop an interaction that was not stopped by the Route Interaction, Queue Interaction, or Stop Interaction block in a multimedia workflow. New workflow entry blocks have this variable pre-populated with 1.
- system.TenantID—The current Tenant identifier. It is initialized from _genesys.session.tenantid or from _genesys.ixn.interactions[system.InteractionID].tenantid (if available). See the Update Contact, Identify Contact, Create Interaction, or Render Message block for more information.
- system.TenantName—The current Tenant name. It is initialized from _genesys.session.tenant.
- system.LastTargetComponentSelected—Target to which the interaction was routed definitively. See the Target Component Selected property of the Target block.
- system.LastTargetObjectSelected—High-level target to which the interaction was routed definitively. See the Target Object Selected property of the Target block.
- system.LastTargetSelected—DN and Switch name to which the interaction was routed definitively. See the Target Selected property of the Target block.
- system.LastVirtualQueueSelected—The Alias of the Virtual Queue specified in the target list where the interaction was routed. See the Virtual Queue Selected property of the Target block.
- system.LastSubmitRequestId—RequestId value of the last <queue:submit> execution. This variable is automatically updated when a successful (queue.submit.done) or unsuccessful (error.queue.submit) event is received. <queue:submit> is generated when using Target or RouteInteraction blocks. <queue:submit> may also be used if using SCXMLState or BeginParallel blocks.
Operational Parameter Management (OPM): These parameters are defined and provisioned in Genesys Administrator Extension (GAX)
- system.OPM—Used by the OPM Block (App_OPM is used in callflow diagrams).
- system.ThisDN— Initially set to the same value as system.DNIS. The value is updated by the interaction party state changed event handler (see IPD/Events property below) to the value of focusdeviceid. This variable becomes the default value for properties: ForceRoute/From, SingleStepTransfer/From, Target/From.
- system.ParentInteractionID— In case of Transfer scenario, this variable is assigned the ID of the parent interaction of the current interaction being processed.
- system.OriginatingSession— In case of context passing (see 'Pass Context' property description above), this variable holds the context of the originating session.
Outbound Contact Server (OCS) variables used by [http://internalwiki.us.int.genesyslab.com/Outbound%20Common%20Blocks Outbound blocks]:
- system.OCS_RecordURI— Its default value is set when the application starts executing from data passed into the application by the GVP or Orchestration platform. For workflows (SCXML), it is initialized from the userdata key "GSW_RECORD_URI". For callflows (VXML), session.com.genesyslab.userdata.GSW_RECORD_URI is used. This variable points to the 'current' record as determined by OCS and is provided to the application as a convenient way to communicate actions back to OCS for the current record.
- system.OCS_URI— Holds the OCS resource path in the format "http(s)://<ocs host>:<ocs port>". Its default value is deduced from OCS_Record_URI. The application can change this variable's value to use a different OCS application for all Outbound blocks in the workflow. Any downstream blocks will use the new value.
- system.OCS_Record— Holds the Record Handle deduced from the value of OCS_Record_URI.
Upgrading from Composer 8.1.1 or earlier
The system variables have been renamed in Composer 8.1.2 to improve the usability and to support new features. When upgrading a workflow that was initially developed with Composer 8.1.1 or earlier, the old set of system variables is kept, in addition to the new one, to ensure compatibility as some of those variables might be used in the application (for block properties or even in ECMAScript code). However, users are now encouraged to use the variables that are "system." prefixed.
|Composer 8.1.1||Composer 8.1.2|
Project variables encompass all the workflows in a Project. These types of variables are defined in the data model of the interaction process diagram (IPD) SCXML application and so are required to be accessed by prefixing the name of a project variable with "_data.". For example, if you define a project variable named var1, you would access it as _data.var1. Project variables are also accessible in ExpressionBuilder. Select Project Variables and then Variables under the Data Subcategory.
Use Project variables when information needs to be shared across workflows in an IPD. For example, if you want to get the e-mail address in one workflow and would like to create and send out an email in another workflow present in the same project. Genesys suggests defining at least one appropriately named Project variable like varProjectXYZ. Any properties that accept a variable will show this variable prefixed with _data in their list.
To define a project variable in Composer Design perspective:
- Click the default.ixprocess tab (or the tab for a renamed IPD) to bring it into focus (tab is highlighted).
- Click the Access Project Variables toolbar button. This opens the Project Variables dialog box. An example dialog box with one entry is shown below.
- Click Add. The variable Name, Type, Value, and Description fields become editable.
- Name the variable.
- Specify an initial value if appropriate.
- Describe the variable.
- Click OK.
Internal Variables Naming
Starting with 8.1.1, Composer changes its naming policy for internal variables, which are variables that do not appear in any Variable edition dialog. They can be seen only in the generated SCXML code. Composer uses those variables to temporarily store data during an application execution.
Most Composer users will not be affected by this change. However, it is possible that some advanced users may have written applications that use those variables although they were not available "out-of-the-box." In such cases, those users will need to upgrade their application to use the variables with the new names.
In 8.1.0, for a DB Data block named DBDataBlock Composer could declare in the SCXML application the variables:
App_DbDataBlock, App_DbDataBlockDBResult, App_DbDataBlockDBResultColumnNames, App_DbDataBlock_cursor, App_DbDataBlock_mapping
In 8.1.1, for a DbData block named DbDataBlock Composer could declare in the SCXML application only one variable named App_DbDataBlock.
Various properties of this variable will be used, such as App_DbDataBlock[‘requestid’], App_DbDataBlock[‘data’], App_DbDataBlock[‘DBResult’], App_DbDataBlock[‘DBResultColumnNames’], App_DbDataBlock[‘cursor’], App_DbDataBlock[‘mapping’]
Attaching Results to User Data
While you can assign Classify object results to a variable, Genesys does not recommend this. The recommended way of dealing with the classification results is to attach them to the interaction. Then User Data will have the keys listed in the table below with the corresponding values returned by Classification Server. As an example, User Data would have the following pairs after the attachment: