Custom VBScript Code - Caller verification in database

Summary:

Since SwyxWare v4.0 it is possible to define own custom scripts with the Graphical Script Editor (GSE). To create scripts using the GSE you have to license the Option Pack - Extended Call Routing.

This articles describes, how to implement a simple Check in a database (e.g. MS Access) if a caller is known.

• Custom VBScript Code - Call logging into textfile
• Custom VBScript Code - Call logging into database
• Custom VBScript Code - Check for Bank Holiday

Further informations about the new features within the Graphical Script Editor can be found in the article:

• Changes in Graphical Script Editor (Update from 3.20 to 4.00)

Information:

Installation of the example rule

Download the complete example code usig the link at the end of this article and copy all included files into the

c:\gse_demo

To load the CheckCaller.rse file as rule into your Call Routing Manager i.e. Graphical Script Editor please follow these steps:

• Open the Call Routing Manager.
• Click the New... button.
• Select Graphical Script Editor and click on Ok.
• Within the GSE open the File | Import... menu.
• Select the CheckCaller.rse. The rule will be imported and your GSE will look like this:

                                                            Graphical Script Editor

• Save the new rule using the File | Save menu.
• Close the GSE.
• Activate the rule by moving it to the right list box of the CRM.

                                                     Call Routing Manager

How it works

Custom code can only be added to the Start rule. All consts, variables and functions you'll define here are available all over the script, i.e. can be used in all blocks e.g. the Evaluate block. Please note, that the final script being created by the GSE places the VBScript statement option explicit to the top of the script. This forces all variables to be used within the script to be declared properly.

                                  Properties - Start rule

To check an incoming call in the database, we use the Evaluate block. As comparison we simply state our function KnownCallerId with the caller id of the current caller as parameter.

                                  Properties - Check Caller in DB

This function returns True if the caller is known, otherwise False. In the following we have connected the Match exit with a Play Announcement block to play a simple beep.wav. The No Match exit is directly connected to the exit of the script.

This is how the custom code looks like:

1.   ' CursorTypeEnum Values
2.   Const adOpenForwardOnly = 0
3.   Const adOpenKeyset = 1
4.   Const adOpenDynamic = 2
5.   Const adOpenStatic = 3
6.  
7.   ' LockTypeEnum Values
8.   Const adLockReadOnly = 1
9.   Const  adLockPessimistic = 2
10.   Const adLockOptimistic = 3
11.   Const adLockBatchOptimistic = 4
12.  
13.   ' CommandTypeEnum Values
14.   Const adCmdUnknown = &H0008
15.   Const adCmdText = &H0001
16.   Const adCmdTable = &H0002
17.   Const adCmdStoredProc = &H0004
18.  
19.  
20.   Function KnownCallerId ( callerID )
21.  
22.       Dim bReturn
23.       bReturn = false
24.  
25.       Dim sDsn
26.       sDsn = "Provider=Microsoft.Jet.OLEDB.4.0;" & _
27.           "Data Source=c:\gse_demo\demo.mdb"
28.   
29.       ' open connection to database
30.       Dim db
31.       Set db = CreateObject("ADODB.Connection")
32.       db.Open sDsn
33.  
34.       ' open recordset
35.       Dim sSQL
36.       Dim rs
37.       sSQL = "select * from callers where callerid = '" & _
38.           callerID & "'"
39.  
40.       Set rs = CreateObject("ADODB.Recordset")
41.       rs.Open sSQL, db, adOpenDynamic, adLockOptimistic, _
42.           adCmdText
43.  
44.       ' if there are records in recordset,
45.       ' this caller seems to be known
46.       bReturn = not rs.EOF
47.  
48.       rs.Close
49.       Set rs = Nothing
50.    
51.       db.Close
52.       Set db = Nothing
53.  
54.       KnownCallerId = bReturn
55.  
56.   End Function 

After activating this rule a beep will be played if the user with extension 100 calls us, otherwise nothing happens. Note that we exit the script using the Rule skipped block. This will enable us to use other rules after this one within our call routing.

Notes

• All callrouting scripts, and therefore also your code, runs under the SwyxWare Service Account. Please make sure that this account has the needed priviliges to access the file/database.
• This example utilizes an MS Access database. For demonstration purpose this is totally fine, but not for production environments! In production environments you should use real databases, like MS SQL Server, only!

• The script in this example does contain no Error Handling. If an error occurs at runtime, e.g. when trying to access a database, this error will not be handled, the script will stop and the call get lost. If you have enabled Server Tracing for SvrScript on level Info3 you will find the original Microsoft Script Engine error message within the server trace file.

  To get your own error handling you have to disable the standard error handling by the Script Engine:

  On Error Resume Next

  Place this line of code at the beginning of your function. Now you have to check for error at every potential place and do your own error handling:

  ' Open connection to Database

  db.Open sDsn

  If Err <> 0 then

  'do something, e.g.:

  FunctionName = False

  Exit Function

  End If

• This example show the so called DSN-less Connection to the database. Of course it is possible to connect to any database via ODBC as long as an ODBC datasource is configured on the SwyxServer machine. There is just one line of code to change in the script. Instead of 
  
  sDsn = "Provider=Microsoft.Jet.OLEDB.4.0;" & _
  "Data Source=c:\gse_demo\demo.mdb"

         you simply have to set the name of the ODBC datasource