4.6 - UserID - Properties & Methods

VBScript 1.1.0

The usual way of working with persistent variables is most likely from within a call routing script. From v1.1.0 the persistent variables can also be used outside of a call routing script, i.e. in a standard windows scripting file (.wsf) or an asp web page.

In these cases the persistent variables switch their default Scope from User/Group to Global to reflect the fact, that they don't have access to a SwyxWare user id, and therefore can't use the User Scope completely by themselves.

If for what reason ever you need to access a persistent variable in the user scope of a certain user from outside a call routing script, you need to specify the SwyxWare user id belonging to that user and switch the scope to User:

<package>
<job id="set_variable_in_user_scope">      
<script language="VBScript" src="PersistentVariables.vbs"/>
<script language="VBScript">

Dim Announcement
Set Announcement    = new PersistentVariable
Announcement.Name   = "Welcome"
Announcement.Scope  = SCOPE_USER
Announcement.UserID = 15

Announcement.Value  = "Beep.wav"

Set Announcement    = Nothing

WScript.Quit

</script>
</job>
</package>

If you save the above code into a text file and name it SetAnnouncement.wsf you can call it directly from the command prompt: (the PeristentVariables.vbs file needs to be in the same folder!)

C:\PersistentVariables> SetAccouncement

The above example demonstrates the usage of persistent variables in a standard windows scripting host file (.wsf).

There are many way to figure the user id of a SwyxWare user:

Assuming you are accessing the variable also from inside a call routing script you can simply take a look into the PersistentVariables table and take the user id from there.
You can also trace it into the server trace file from within a call routing and read it from there.
Use any of the SwyxWare APIs (Server Script API, Client SDK, ConfigDataStore SDK, Powershell) to obtain it from SwyxWare.
...