Our community blogs

1. 

   The Call Routing Guy

   A blog by Tom Wellige in General

   • 17
     entries
   • 9
     comments
   • 5438
     views

   Recent Entries

   • #9: Don't be shy, be chatty!
   • #3: Be more flexible on dates!
   • #10: I can't hide anymore!
   • #17: Be more flexible on dates! (Part 2 - Lua)
   • #16: Code, code, code

   

   Latest Entry
   

   #9: Don't be shy, be chatty!

   VBScript Lua

    

   When it comes to develop call routing scripts with some own VBScript code in it, it might become handy to be able to have a look on what your code is doing.

    

   There are lots of so called "debugging" possibilities, but at this point you have to believe me, the only really reliably working method is placing your own log/trace information into the server trace file. 

    

   Before you say that those trace files are way too large and confusing for you, they are not, once you know how to read them and how to filter the stuff you are interested in out. In the forum post "How to filter SwyxWare traces for call routing output of a single call" I have explained already in detail how this can easily be done. So lets focus on how to get your own information into the server trace file.

    

   This can simply be done with PBXScript.OutputTrace (Vbs)/ PBXScript.OutputTrace() (Lua).

    

   For VBScript based Call Routing:

   PBXScript.OutputTrace "Hello World!"

    

   For Lua based Call Routing:

   PBXScript.OutputTrace("Hello World")

    

   So what should be written into the server trace and what not? And how will I find my own trace output quickly and easily?  

    

   By taking a look into the server trace file you figure that the SwyxWare traces quite a lot of stuff, not only errors but also tons of other information and events. You should do the same in your own VBScript/Lua code as well. Do not only trace errors your run into but also every kind of information that might become useful later on when you have to analyse the call routing if for some reason it doesn't work anymore like the many months before. The more information you place into the trace file the more easy it will become to pin point a problem later on. You might not even have to get into the script and work yourself into it if the traces are already informative enough.

    

   Lets assume you have written yourself a VBSscript/Lua function to do what ever you need to do, placed it into the Start block and call it later on e.g. in an Evaluate block.

    

   Taking all said above into consideration, that following is something like a "best practice" function template in terms of tracing.

    

   For VBScript based Call Routing:

   Function DoWhatever ( Parameter1, Parameter2 )
   
       PBXScript.OutputTrace "---------> DoWhatever"
       PBXScript.OutputTrace "Parameter1 = " & Parameter1
       PBXScript.OutputTrace "Parameter2 = " & Parameter2
   
       On Error Resume Next
   
       Dim bReturn
       bReturn = False
   
       ' do what ever your function needs to do
       ' ...
       If Err <> 0 Then
           PBXScript.OutputTrace "Error while doing something!"
           PBXScript.OutputTrace "(Err) " & Err.Description
       Else
           PBXScript.OutputTrace "Successfully did something"
       End If
   
       ' if you "calculate" something, it is always a good idea to trace the result of it
       Dim sSQL
       sSQL = "SELECT * FROM MyTable WHERE value1 = " & Parameter1 & " AND value2 = " & Parameter2
       PBXScript.OutputTrace sSQL
   
   
       DoWhatever = bReturn
   
       PBXScript.OutputTrace "bReturn = " & bReturn
       PBXScript.OutputTrace "<--------- DoWhatever"
   
   End Function

    

   For Lua bsed Call Routing:

   function DoWhatever ( Parameter1, Parameter2 )
   
       PBXScript.OutputTrace ("---------> DoWhatever")
       PBXScript.OutputTrace ("Parameter1 = " .. Parameter1)
       PBXScript.OutputTrace ("Parameter2 = " .. Parameter2)
   
       local bReturn = false
       local oResult = nil
   
       -- do what ever your function needs to do
       -- ...
       if (oResult == nil) then
           PBXScript.OutputTrace ("Error while doing something!")
       else
           PBXScript.OutputTrace ("Successfully did something")
       end
   
       -- if you "calculate" something, it is always a good idea to trace the result of it
       local sSQL
       sSQL = "SELECT * FROM MyTable WHERE value1 = " .. Parameter1 .. " AND value2 = " .. Parameter2
       PBXScript.OutputTrace ("sSQL = " .. sSQL)
   
       PBXScript.OutputTrace ("bReturn = " .. tostring(bReturn))
       PBXScript.OutputTrace ("<--------- DoWhatever")
   
       return bReturn
   end

    

    

   Lets go through the template, step by step...

    

   The first and the last thing you function should do it to trace that you have entered and left it again.

    

   For VBScript based Call Routing:

   PBXScript.OutputTrace "---------> DoWhatever"
   
   PBXScript.OutputTrace "<--------- DoWhatever"

    

   For Lua based Call Routing

   PBXScript.OutputTrace ("---------> DoWhatever")
   
   PBXScript.OutputTrace ("<--------- DoWhatever")

    

   The arrows should tell you that you go into your function and go out of it again. All trace lines in between these two arrow lines will be made by your function. So they also help to find your stuff quickly.

    

    

   If your function takes parameters it is a good idea to trace them. If your function doesn't work and it get already come crap parameters it is not surprising that it fails later on.

    

   For VBScript based Call Routing:

   PBXScript.OutputTrace "Parameter1 = " & Parameter1
   PBXScript.OutputTrace "Parameter2 = " & Parameter2
   

    

   For Lua based Call Routing:

   PBXScript.OutputTrace ("Parameter1 = " .. Parameter1)
   PBXScript.OutputTrace ("Parameter2 = " .. Parameter2)

    

    

   For VBScript based Call Routing: If you have disabled the standard error handling (will be part of a future blog post) you need to check every "dangerous" call yourself, if it succeeded or not. For example you try to write something into a text file it could happen that the file doesn't exist or is read only. Or you try to access a database which is currently not reachable. So if you check for the outcome of such a call do not only trace errors but also that it succeeded.

   If Err <> 0 Then
       PBXScript.OutputTrace "Error while doing something!"
       PBXScript.OutputTrace "(Err) " & Err.Description
   Else
       PBXScript.OutputTrace "Successfully did something"
   End If

    

   For Lua based Call Routing:

   if (oResult == nil) then
       PBXScript.OutputTrace ("Error while doing something!")
   else
       PBXScript.OutputTrace ("Successfully did something")
   end

    

    

   If you calculate something within your function, e.g. build an SQL statement to run against a database and use some current values (e.g. the function parameters) to do so, it is a good idea to write the result of this into the trace. To stay with the SQL statement example this will enable you later on to copy&paste the statement from the trace file and test it directly against your database.

    

   For VBScript based Call Routing:

   Dim sSQL
   sSQL = "SELECT * FROM MyTable WHERE value1 = " Parameter1 & " AND value2 = " & Parameter2
   PBXScript.OutputTrace sSQL

    

   For Lua based Call Routing:

   local sSQL
   sSQL = "SELECT * FROM MyTable WHERE value1 = " .. Parameter1 .. " AND value2 = " .. Parameter2
   PBXScript.OutputTrace ("sSQL = " .. sSQL)

    

    

   And finally, if your function returns a value, just trace this value.

    

   For VBScript based Call Routing:

   PBXScript.OutputTrace "bReturn = " & bReturn
   

    

   For Lua based Call Routing:

   PBXScript.OutputTrace ("bReturn = " .. tostring(bReturn))

    

    

   You don't need to put all trace stuff into your function from the beginning, while you are still developing it. But once it is finished and tested you should put trace output in it.  You can't trace too much information, just too few. The more information you trace the more easy it will become later on to identify a problem if the call routing script ceases to work.

    

    

   Enjoy!

    

   PS: don't miss to take a look into the ECR Useful Link Collection

    

   • Read more...
   • 0 comments
2. 

   Fridays' Swyx Tip

   A group blog by Mirjam Baumberger in General

   • 49
     entries
   • 0
     comments
   • 42404
     views

   Recent Entries

   • Fridays' Swyx Tip: Thank you Mirjam!
   • Fridays' Swyx Tip #48: DND - Advanced DDI Routing
   • Fridays' Swyx Tip #47: Wrap-up time
   • Fridays' Swyx Tip #46: Feature Code Intercom
   • Fridays' Swyx Tip #45: Event Log Monitor

   

   Latest Entry
   

   Fridays' Swyx Tip: Thank you Mirjam!

   By Tom Wellige, September 11, 2020

   This post sums this great article series up. Mirjam spent quite some time to identify all those tips and to publish them here on Swyx Forum.

    

   As the article series dates some years back there had been a couple of articles I have not re-posted again, simply because they were not valid with a current SwyxWare version anymore.

    

   But the vast majority of the tips is still valid with current SwyxWare versions and that's why I decided to re-post them to make them available again after the old Swyx Forum went offline.

    

   Thank you very much Mirjam for all your efforts!

    

   • Read more...
   • 0 comments
3. 

   Anything is Possible ?

   A blog by MarkRussell in General

   • 6
     entries
   • 44
     comments
   • 2546
     views

   Recent Entries

   • Call Parking / Open Hold
   • You want ME! to record the announcements ?
   • VIsual Groups (All Ring)
   • Partner Confernce Live(ish) Blog
   • Buzz Words

   

   Latest Entry
   

   Call Parking / Open Hold

   A common feature request I have had over the years is a Call Park feature, and the usual stock reply to Can Swyx Do..... is NO! but...... of course this is software and anything is possible. I have seen a number of ways of implementing a call park feature some really clever ones that use the conference bridge facility in Swyx to some not so clever ones using analog adaptors to have live logged on extensions which are used to pick up from... sudu call park.
    
   Before I saw the conference room version written by Tom I had a go myself and came up with this solution a couple of years ago and put it online. Recently a couple of requests came in for the source code so I thought I would upload it here.
    
   This is another illustration of how different solutions to problems can be developed with Swyx, there is no right or wrong way, they either work or don't.

    

    

   So next time someone asks if "Swyx can do .........  ?",  reply  "No it can't, but you can"  🙂

    

    

    

    

   Call Park.zip

    

    

   • Read more...
   • 3 comments
4. 

   Digital normal

   A group blog by Swyx Forum in General

   • 9
     entries
   • 0
     comments
   • 2453
     views

   Recent Entries

   • Folge 8: "Service"
   • Folge 7: "Meeting"
   • Folge 6: "Rufumleitung"
   • Folge 5: "Einen Klick entfernt"
   • Folge 4: "Bin im Urlaub"

   

   Latest Entry
   

   Folge 8: "Service"

   By Tom Wellige, September 25, 2019

    

   • Read more...
   • 0 comments