Tom Wellige

VBScript Once the CDRs are written into the database an additional table and a so called trigger must be configured. To do so, use the SQL script LongestWaiting_1.0.0.sql from the SQL folder of the installation package. After having executed this script the created trigger will automatically take newly written CDRs from the SwyxServer, extract the user and disconnect time from it and stores these information within the LongestWaiting table. Some more documentation on how to execute SQL statements on an MS SQL Server (i.e. making use of the Microsoft SQL Server Management Studio) can be found in the Open Queue Manual, chapter 3.2 Database. In order to get this working correctly two parameters need to be configured within the Parameters table: ExtensionRange - the number of digits of SwyxWare’s extension range, default: 3 PublicLineAccess - number to be dialed for public line access, default: default: 0 Once everything is configured correctly you can check the proper functionality by having a look into the LongestWaiting table to check if records for current timestamps/calls will be written.

VBScript As the SwyxServer does not provide the needed information about “Latest Disconnect Time” of a user directly, the Call Detail Records (CDRs) are used to get this information. So the CDRs must be written into a database. Details on setting up CDRs written into a database can be taken from the Enreach Help Center: Write Call Details Records into a database The needed SQL script (IpPbxCDR.sql) to setup the IpPbxCDR table should be taken from the above linked article. Please note, that the following step expects the call details table to be named IpPbxCDR!

VBScript You can now use the Longest Waiting action directly within a call routing script, as a replacement for the Connect To block. The Longest Waiting action has a similar parameter and return value set so it's in fact nothing more than replacing a Connect To block by the Run GSE Action block to call the Longest Waiting action. Create a new GSE rule and import the rse file (SimpleLongestWaiting.rse) from the "rse" subfolder of the download package (File - Import...). Double click the Longest Waiting / Run GSE Action block and switch to the Parameters page You can now configure the parameters according your needs. ProviderParam Connect string to the database holding the IpPBXCDR and LongestWaiting table Destination Number of the SwyxWare usergroup containing all agents who are to handle incoming calls. ConnectTimeout Timeout in seconds to connect a call to a certain agent (like in Connect To) Connect Alert Sound Caller will listen to this while call is connected to an agent. Leave it blank (i.e. = "") to use the system a l e r t sound. IgnoreBusyInternal 0 - If an agent is either internaly or externaly busy he won't get calls deliverted. 1 - If an agent is internaly busy he will get calls delivert, if he is externaly busy he won't. The Longest Waiting action has the following exits (need to be enabled on the "Links" tab in the Properties windows): 0 - Connected 1 - Not Reachable 3 - Disconnected 9 - Failure For Longest Waiting the "Not Reachable" exit means, that for what reason ever the action wasn't able to connect the call to any of the users of the group. This could be because none of them is logged in or all of them are busy, or each connect to attempt to each of the group members ran into a timeout. So in fact, the "Not Reachable" exit is used for all of the possible states (timeout, busy, not delivered), but it's not possible to differ these states afterwards as the action tries to deliver the call to every user of the group, and "Not Reachable" is just the final conclusion over all users, not just one.

VBScript The Longest Waiting extension is designed as GSE actions. To install these GSE actions you need to use the SwyxWare Administration. Step 1 Open the SwyxWare Administration and open the properties of your Swyx Server. Step 2 Switch to the Files page and click on Edit.... Step 3 Click on Add... Step 4 1. Select all files from the ase folder from the download package. 2. Select Global as Scope. (you can also select User to load the files into the user scope a your script user) 3. Select CallRoutingScripts (in SwyxWare < 13.10) or Call Routing VBS scripts (in SwyxWare >= 13.10) as Category. 4. It is recommended to enter Longest Waiting into the Description field, but not necessary. Step 5 To check if the GSE action is available within call routing scripts open the Call Routing Manager of any user and click the button Sequence of Actions. Scroll the list on the left side down until you reach the Longest Waiting action. The (System) behind the GSE action name shows that this is a global action being available for every SwyxWare user. The PersistenVariable GSE action is now installed completely and persistens variables can now be fully used within GSE call routing scripts.

VBScript Download the latest version of this project.

VBScript This project originates from the Open Queue project here on Swyx Forum and can also be used completely separated from that project. Because of that I decided to showcase it here, in the Open ECR Extensions project. When connecting a call to a group, there are currently the following hunt groups available within SwyxWare: parallel sequential rotary random A Longest Waiting hunt group selection is missing and therefore there was a need to develop it as a new, stand-alone GSE action. Whith this extension it is possible to connect a call to a user of a group who has been idle for the longest time of all members of the group. The extension sorts the users of the group by their longest waiting/idle time, and then tries to connect the call in that order until it is either connected or no one in the group took it (not logged in, busy or timeout). The blog article #10: I can't anmore! explains a little bit in detail how this functionality was implemented. Please refer to the Forums to discuss the Longest Waiting Hunt Group or for support requests. Please find the download for this project here. A complete documentation explaining the setup and usage can be found further down of this post. As with all other Swyx Forum Open Source Projects, Support is EXCLUSIVELY provided in the Project Froum (see link above). License Longest Waiting Hunt Group v1.0.0 This is a Swyx Forum Open Source Project. https://www.swyxforum.com/projects/ Copyright (c) 2007-2017 by Swyx Forum Copyright (c) 2007-2017 by Tom Wellige All Rights Reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. This project was originally published as part of the Open Queue project: Open Queue Project v2.x Copyright © 2007-2014 by Swyx Forum Copyright © 2007-2014 by Tom Wellige All Rights Reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANT-ABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON INFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

VBScript 1.1.0 This example demonstrates how to make use of Persistent Variables in a WSF (Windows Scripting Host File) file, i.e. a VBScript file. You will find it in the download package in the following folder \examples\External\vbs This little script is meant to be connected with a shortcut SwyxIt! skin element. By clicking on that shortcut the .wsf file will be started. By starting this .wsf file the current status of the installed Night Switch will be toggled. Toggle.wsf <package> <job id="Toggle_Example"> <script language="VBScript" src="PersistentVariables.vbs"/> <script language="VBScript"> ' configure the complete db connect string g_sPersistentVariableConnectString = _ "Provider=sqloledb;" & _ "Data Source=WS-WELLIGE04;" & _ "Initial Catalog=" & PERSISTENT_VARIABLE_DATABASE & ";" & _ "User Id=PersistentVariables;" & _ "Password=PersistentVariables" ' initialize persistent variable Dim NightSwitch Set NightSwitch = new PersistentVariable NightSwitch.Name = "NightSwitch" NightSwitch.Default = 0 if NightSwitch.Value = 0 then NightSwitch.Value = 1 else NightSwitch.Value = 0 end if Set NightSwitch = Nothing WScript.Quit </script> </job> </package> You can call this .wsf file directly from a command prompt: C:\PersistentVariables> Toggle You have to make sure, that the PersistenVariables.vbs file is in the same folder as the Toggle.wsf file. Please find a complete explanation of the usage of persistent variables outside of call routing scripts here: 6.6 - Usage of Persistent Variables outside of a call routing script

VBScript 1.1.0 This example demonstrates how to make use of Persistent Variables in an ASP (Active Server Page) web page. You will find it in the download package in the following folder \examples\External\asp This little web page is meant to be used within a WebExtension in a SwyxIt! skin. It displays the current status of the installed Night Switch example (see chapters A.1 and A2). By clicking into the web page the status of the night switch will be toggled. The page also refreshes itself every 2 seconds, so if the night switch is getting switched from somewhere else, this page will also automatically shows the new status. Default.asp <meta http-equiv="refresh" content="2;url=<%=Request.ServerVariables("SCRIPT_NAME")%>"> <style> body.on { background: #FFFF00; } body.off { background: #C0C0C0; } a { padding: 48% 50%; } </style> <!-- #include file = "PersistentVariables.inc"--> <% ' configure the complete db connect string g_sPersistentVariableConnectString = _ "Provider=sqloledb;" & _ "Data Source=WS-WELLIGE04;" & _ "Initial Catalog=" & PERSISTENT_VARIABLE_DATABASE & ";" & _ "User Id=PersistentVariables;" & _ "Password=PersistentVariables" ' initialize persistent variable Dim NightSwitch Set NightSwitch = new PersistentVariable NightSwitch.Name = "NightSwitch" NightSwitch.Default = 0 ' evaluate url parameter sUrlSwitch = Request.QueryString("switch") if (sUrlSwitch <> "") and IsNumeric(sUrlSwitch) then NightSwitch.Value = CInt(sUrlSwitch) ' set display styles if NightSwitch.Value = 0 then sStyle = "off" sSwitch = "1" else sStyle = "on" sSwitch = "0" end if Set NightSwitch = Nothing sURL = Request.ServerVariables("SCRIPT_NAME") & "?switch=" & sSwitch %> <body class="<%=sStyle%>"> <a href="<%=sURL%>"> </a> </body> You have to make sure, that the PersistenVariables.inc file is in the same folder as the default.asp file. Please find a complete explanation of the usage of persistent variables outside of call routing scripts here: 6.6 - Usage of Persistent Variables outside of a call routing script

VBScript This script is an example to show how to use the Night Switch in any call routing script of any user. How to install it Make sure you have the Persistent Variable extension properly installed Open Call Routing Manager of the user you want a Night Switch enabled call routing script for Create a new ruleusing the GSE Import the file NightSwitchEnabledScript.rse from the download package Save the rule and exit the GSE How to use it Just call the user. If the night switch is off the call will be connected to the user. If the night switch is on you will end up in his voicemail. How it works The persistent variable NightSwitch will be initialized. It's global scope makes sure that it can be accessed from any user. The content of the NightSwitch variable will be passed to the exits of the block. If the content is 0 the default exit will be taken, meaning the night switch is off. If the content is 1 the "1" exit will be taken, meaning the night switch is on. The default value of the night switch is 0, meaning if the NightSwitch variable hasn't been set by any other script before (i.e. the A.1 - Night Switch Manager script) the night switch is off. Please note that the value of the persistent value is converted into an integer using CInt before being passed into the UseExit variable. This is just to make sure that regardless of what datatype has been passed into the persistent variable, it is used here in the correct data type. The above mentioned script to manage the status of the night switch can be found here: A.1 - Night Switch Manager Hint: the Persistent Variables can be used with ANY SwyxWare version. The inlcuded examples and the GSE Action itself however might be stored with the most recent SwyxWare version of the time the Persistent Variable version was released. This means that you might need to use the latest SwyxWare version to be able to open the included GSE Rules (.rse files) and the GSE Action (.ase file) within your GSE.

VBScript The Night Switch Manager script is used to enable or disable the night switch. How to install it Make sure you have the Persistent Variables extension properly installed Create or use a dummy/test user Open it's Call Routing Manager Create a new rule using the GSE Import the file NightSwitchManager.rse from the download package You might want to record your own announcement for the Get DTMF Char block explaining the usage of the menu (press 0 to switch the night switch off, press 1 to switch it on). Save the rule and exit the GSE How to use it There are two ways to use the Night Switch Manager: Simply call the dummy user. You will hear the current status of the night switch (0 for off and 1 for on). Afterwards you are in the DTMF menu to enable or disable the night switch. If you have recorded your own announcement you will hear it now. Press 0 to disable the night switch, press 1 to enable it. Afterwards the new status of the night switch will be announced. You can skip the DTMF menu by passing the desired new status of the night switch (0 for off and 1 for on) as post dialing digit when calling the dummy user. By doing so the night switch will be set accordingly and you will only listen to the new status. This enables you to configure two speed dial keys in your SwyxIt! or on your SwyxPhone (assuming your dummy user has the internal number 300): - Label: Night Switch ON Number: 3001 - Label: Night Switch OFF Number: 3000 How it works Initialize the NightSwitch persistent variable. Store post dialing digits into own variable. Do we have any post dialing digits ? DTMF menu. If we have any post dialing digits witin our own variable they will be taken as DTMF input. The block also returns the pressed DTMF key or the post dialing digit in another variable. Store the selected new status of the night switch into the persistent variable. To make use of the Night Switch in any call routing script see here: A.2 - Night Switch enabled call routing script Hint: the Persistent Variables can be used with ANY SwyxWare version. The inlcuded examples and the GSE Action itself however might be stored with the most recent SwyxWare version of the time the Persistent Variable version was released. This means that you might need to use the latest SwyxWare version to be able to open the included GSE Rules (.rse files) and the GSE Action (.ase file) within your GSE.

VBScript 1.1.0 The persistent variables have been developed to be used inside of call routing scripts. But as the underlying technology is plain VBScript they can also be used everywhere else where you can use VBScript. Please note that for this to work some adaptions needed to be make in the initial releases. The idea behind is of cause to have the same comfort in using persistent variables somewhere else, like e.g. in web pages or standard VBScripts. When using the persistent variables outside of a call routing script there is however a difference to the normal usage within call routing scripts: the default Scope is not User but Global. This is because from outside the call routing there is no SwyxWare user easily available and therefore no User scope possible by default. So without defining the scope explicitly, it is global by default. Dim NightSwitch Set NightSwitch = new PersistentVariable NightSwitch.Name = "NightSwitch" If you need to access a variable in the user scope of a specific SwyxWare user all you need to know is it's SwyxWare user id. There is a UserID property that needs to be set in that case. Dim RedirectTo Set RedirectTo = new PersistentVariable RedirectTo.Name = "RedirectTo" RedirectTo.Scope = SCOPE_USER RedirectTo.UserID = 15 If you need to access a variable in the group scope of a specific SwyxWare user group all you need to know is it's SwyxWare group id. There is a GroupID property that needs to be set in that case. Dim RedirectTo Set RedirectTo = new PersistentVariable RedirectTo.Name = "RedirectTo" RedirectTo.Scope = SCOPE_GROUP RedirectTo.UserID = 3 There are many ways to figure the id of a SwyxWare user or group: 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 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. and more... In order to use the persistent variables in other VBScript file, they need to get included. In a call routing script this is done by adding the PersistentVariable GSE action into the GSE rule. Standard VBScript doesn't doesn't know an include statement, but fortunately there are two environments like a call routing script, that add this missing functionality: Active Server Pages (ASP) and Windows Scripting Files (WSF). Active Server Pages (.asp) These are simply web pages hosted on an MS IIS webserver. The internet is full of documentation on ASP pages, so here it is just shown how to include persistent variables into an own asp page. <!-- #include file = "PersistentVariables.inc"--> <% ' vbscript code follows here ' ... %> Please note, that it is not the PersistentVariables.vbs file that is being included, but the PersistentVariables.inc file. This is because for asp pages <% and %> needs to be placed around VBScript code. You can find this file in the \examples\External\asp folder of the download package. There you will also find a complete example. Windows Scripting Files (.wsf) These are VBScripts that can be directly called by their filename, not even the .wfs file extension is needed when calling them. <package> <job id="Example"> <script language="VBScript" src="PersistentVariables.vbs"/> <script language="VBScript"> ' vbscript code follows here ' ... WScript.Quit </script> </job> </package> You can find the PersistentVariables.vbs file either in the \vbs as also in the \examples\External\vbs folders of the download package. There you will also find a complete example. The next step before being able to use any persistent variable is to configure them. While there is no configuration needed if you have installed everything according the suggestion, here it is now necessary to give one important parameter: the database connect string. This is stored into the global variable g_sPersistentVariableConnectString being defined by the persistent variables. ' configure the complete db connect string g_sPersistentVariableConnectString = _ "Provider=sqloledb;" & _ "Data Source=SQL_SERVER_NAME;" & _ "Initial Catalog=" & PERSISTENT_VARIABLE_DATABASE & ";" & _ "User Id=PersistentVariables;" & _ "Password=PersistentVariables" The Data Source is the sql server machine name, i.e. the SwyxServer machine name. The Initial Catalog is the name of the database. If you installed everything according the suggestion this is IpPbxExtensions. This name is defined in the constant PERSISTENT_VARIABLE_DATABASE. You most likely can't use integrated security to login to the database, so you need to configure a login with username and password (see 2.1 - Setup Database, Step 5 onward, instead of of Windows authentication you have to use SQL Server authentication). The chosen username and password need to be given as User Id and< Password. From now on everything is just like the usage of persistent variables in a call routing script, i.e. like the two first code snippets on this page.

VBScript When setting up the Persistent Variables extension you are free to use any type of database on any machine in your network. If you do so you need to give the Persistent Variable extension a clue of it by giving the complete Connect String. This is done in the properties of the Run GSE Action block that loads the PersistentVariables GSE action. Please note: it is highly recommended to use the suggested defaults for the database (local MS SQL Server, IpPbxExtensions database)! Samples for a connection strings for the different available type of database can be found here: ConnectionStrings.com

VBScript When setting up the Persistent Variables extension you are free to create/use into another database than the recommended IpPbxExtensions database. The Persistent Variables extension uses the IpPbxExtensions database by default. If you use another database you need to tell the Persistent Variables extension the name of it. This is done in the properties of the Run GSE Action block that loads the PersistentVariables GSE action. Please note: it is highly recommended to use the suggested defaults for the database (local MS SQL Server, IpPbxExtensions database)! Alternatively you can also use the 6.5 - Use different database configuration.

VBScript When setting up the Persistent Variables extension you are free to setup the IpPbxExtensions database into an SQL server on another machine than the one SwyxWare is installed on. The Persistent Variables extension is able to connect to the local SQL Server automatically. If you create the database into an SQL Server on another machine you need to tell the Persistent Variables extension where to look for the database. This is done in the properties of the Run GSE Action block that loads the PersistentVariables GSE action. Please note: it is highly recommended to use the suggested defaults for the database (local MS SQL Server, IpPbxExtensions database)! In order to create the database for the Persistent Variable extension into another SQL Server you have to configure the SwyxWare services to run under a domain user instead of the default local user. By doing this you will be able to grant access for this domain user also to the IpPbxExtensions on the other machine. Alternatively you can also use the 6.5 - Use different database configuration.

VBScript By default persistent variables are not compatible to Master Standby scenarios. This is simply to the fact that the IpPbxExtensions database is not replicated automatically into the MS SQL server of the Standby machine. To use persistent variables in a Master Standby scenario you have two possibilites: Setup the IpPbxExtensions database along with the PersistentVariables table also on the Standy system and configure a replication between the both database. This has to be done manually as SwyxWare's config wizzard does not know about the IpPbxExtensions database. Do not setup a replication, ignore possible switches from Master to Standby and just rely on proper Default values for the persistent variables. This is most definately not recommended.

VBScript This is how the PersistentVariables table with it's fields is defined: PersistentVariables --------------------------------------------------------------------------------- PersVarID int unique id of variable Name nvarchar(50) variable name Value nvarchar(1024) * value of variable Scope int scope of variable ( SCOPE_SCRIPT 1, SCOPE_USER 2, SCOPE_GLOBAL 3, SCOPE_GROUP 4) UserID int * SwyxWare UserID of user who is allowed to access this variable (SCOPE_USER) GroupID int * SwyxWare GroupID of group which is allowed to access this variable (SCOPE_GROUP) NameSpace nvarchar(128) * Namespace in which this variable is available (SCOPE_NAMESPACE) Created datetime * Timestamp of when the variable was initially created in database CreatedByName nvarchar(80)* Name of caller in call routing script in which the variable was initially created in database CreatedByNumber nvarchar(80)* Number of caller in call routing script in which the variable was initially created in database Modified datetime * Timestamp of when the variable was stored last time in database ModifiedByName nvarchar(80)* Name of caller in call routing script in which the variable was stored last time in database ModifiedByNumber nvarchar(80)* Number of caller in call routing script in which the variable was stored last time in database * = Allow Nulls

VBScript This is a VBScript constant defined to the value of 3. This constant will be used to set the Scope of a persistent variable to the global scope. Variables in the global scope are visible/accessable for all scripts of all users and groups. This is the default scope of every new persistent variable if being used outside a call routing script (new in v1.1.0). If being used inside of a user call routing SCOPE_USER is the default scope. If being used inside of a group call routing SCOPE_GROUP is the default. Dim Announcement Set Announcement = new PersistentVariable Announcement.Name = "Welcome" Announcement.Scope = SCOPE_GLOBAL The above example defines a persistent variable in the global scope. This variable is visible and accessable for all scripts of all users and groups.

VBScript This is a VBScript constant defined to the value of 2. This constant will be used to set the Scope of a persistent variable to the user scope. Variables with a scope seto to SCOPE_USER are visible/accessible for all scripts of the current script user. This is the default scope of every new persistent variable if being used within a call routing for a user. If the variable is used in a call routing for a group the default is SCOPE_GROUP. If being used outside of a call routing script (new in v1.1.0) the default is SCOPE_GLOBAL. Dim Announcement Set Announcement = new PersistentVariable Announcement.Name = "Welcome" Announcement.Scope = SCOPE_USER If you use the persistent variable in a user call routing, the default scope is SCOPE_USER, so you an shorten your code to: Dim Announcement Set Announcement = new PersistentVariable Announcement.Name = "Welcome" The above examples define a persistent variable Welcome in the User scope. This variable is visible/accessible for all scripts of the same user. Another script of another user which defines also a persistent variable Welcome does not interfere.