Blogs
Our community blogs
-
- 24
entries - 9
comments - 10233
views
Recent Entries
To understand the so called PreProcessing we first need to take a look into the Call Routing Manager.
In there we see the list of all call routing rules, the system ones and the own ones.
But this picture is not complete. There are two more rules, which are hidden in the list, but are getting executed for every call. The PreProcessing rule which is started before the user's call routing, and the PostProcessing which is started after the user's call routing.
As both rules are hidden, it is not possible to deactivate them. They can also not that easily get manipulated by a user.
In the following we will focus on the PreProcessing, as this is the one which can be used best in some own call routing tasks. But every that is said in the following is also true for the PostProcessing (except that in the PostProcessing the call is already disconnected).
The default PreProcessing is an empty GSE rule, which is left through the Rule skipped exit. This ensures that following rules (the entire user call routing) will be executed.
Before going into detail on how to create your own PreProcessing I want to take a look on what the it can be used for. There are multiple usage examples:
- User based/Global name resolution against own database.
- User based/Global black/white listing of calls.
- User based/Global break through redirections for certain callers.
- User based/Global own call logging (in combination with a user based/global PostProcessing).
- A identical call routing for all users of a company. In this case I would highly recommend to place that call routing into a global GSE Action which is called by the PreProcessing rule. This makes the maintenance of the call routing more easy. There will be another blog article soon explaining all there is to know about GSE Actions.
From the above list you can take that a PreProcessing rule is either a local rule to a user or a global rule being used by all users.
By the way: beside GSE Actions the Pre- and PostProcessing rules are the only call routing functionalities, which can be made global.
To create your own PreProcessing all you need to do is to create a new GSE rule on your test user and name it PreProcessing.You are absolutely free to do what every you want within this rule, just keep a few things in mind:
-
If you leave the rule through the Rule executed exit, no following rules will be started, i.e. you completely disable the user's own call routing rule.
This might be totally fine and wanted (like in a black/white listing task, to block callers), just be aware of what you are doing. - If you leave the rule through the Rule skipped exht, the users own call routing will be executed. This should be the default behaviour of your rule.
After having created the PreProcessing rule, it is a local rule of the current user, and you have it in the list of rules of the Call Routing Manager. I strongly advise to use a test user for creating the needed PreProcessing, regardless if you need it afterwards only for one other user or all users within your SwyxWare. This ensures that you can modify and re-test it at any time.
Now that you have the PreProcessing rule on your test user, how do you get it to another user or make it even global?
All you need to do is to get one certain file out from the SwyxWare configuration database, the generated VBScript/Lua code for your rule:
- rulePreProcessing.vbs or
- rulePreProcessing.lua.
To get this file follow these steps:
- Open the SwyxWare Administration
- Open the Users branch in the tree view on the left
- Right click your test user to open his context menu
- Select Special properties, and then Administration...
- Switch to the Files tab and click Edit...
- Select the file rulePreProcessing.vbs or ruleProcessing.lua in the list and click Save As...
- Selet a local folder on your hard drive to store the file in.
- Close the File List window and the Administration Properties again.
If you want to have the PreProcessing rule local to selected user(s):- Repeat the above steps 1-5
- Click Add...
- Click "..." and select the previously stored file
- As Category select either Call Routing VBS scripts or Call Routing Lua scripts
- Click Ok
If you want to have the PreProcessing global, i.e. it will be used for ALL users:- Open the SwyxWare Administration
- Right click your SwyxServer name in the left tree view to open his context menu
- Select Properties
- Switch to the Files tab and click Edit...
- Click Add...
- Click "..." and select the previously stored file
- As Sope make sure that Global is selected (should be the default)
- As Category select either Call Routing VBS scripts or Call Routing Lua scripts
- Click Ok
There are a few things you really have to keep in mind when making a PreProcessing rule global:
- Test you PreProcessing rule extensivley before making it global!
- Worst case: no one within your company can be called anymore (internally or externally) if your rule contains an error.
- So again, test, test, test!
- When including own VBScript/Lua code, make sure to Implement proper error handling! For VBScript code check the CheckCallerInDatabase function as an example for proper error handling. For Lua code check the CheckCallerInTextFile() function.
- Unhandled runtime errors lead to disconnection of the call, i.e. no one within your company can be called anymore.
- Consider the resource and time consumption of your PreProcessing script, as it will be called vor EVERY call.
I have already pointed on two different rulePreProcessing files: .vbs and .lua
For users you have switched to Lua based call routing, you need a PreProcessing also made on a Lua based test user and the rulePreProcessing.lua file.
For users using the default (at the time of writing this blog article) VBScript based call routing, you need a PreProcessing also made on a VBScript based test user and the rulePreProcessing.vbs file.
If you make your PreProcessing global and have VBScript based as also Lua based call routing users in your system, you need to create the PreProcessing also in both environemts and make both files global.
There is also a webinar available to all Enreach Partners within the Enreach Partner Net, explaining all above again in a video and even providing a short live demo. The webinar is available in German and English language (Partner login required!) and was already recorded a few years back, before Swyx turned into Enreach and before Lua became an option within the call routing.
Enjoy!
PS: don't miss to take a look into the ECR Useful Link Collection.
- Read more...
-
- 0 comments
- 24
-
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
-
- 6
entries - 44
comments - 3669
views
Recent Entries
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" 🙂
- 6
-
- 9
entries - 0
comments - 3260
views
Recent Entries
- 9
-
Blog Statistics
-
Total Blogs4
-
Total Entries86
-
-
Blog Comments
-
By Tom Wellige · Posted
I have just updated the download link in the article with a correctly working version. -
-
By Tom Wellige · Posted
Nein, das Skript läuft auf JEDER SwyxWare Version. Das ist das schöne am Call Routing Ich habe aber nochmal etwas genauer nachgesehen, und einen logischen Fehler gefunden. Der ist nun behoben und das Skript läuft einwandfrei auf meinem 13.25er Testsystem. Der Download oben im Blog Post ist aktualisiert. Das war allerdings nur ein logischer Fehler, d.h. das Ende des Urlaubs wurde nicht richtig erkannt. Das hat aber zu keinen Skript/Ruf Abbruch geführt. Das klingt mir ehe -
By Martin Schulze · Posted
Hallo Herr Wellige 😀 ich bin gerade dabei ein Call Routing zu bauen, wo die Nutzer "einfach" Ihre Urlaubszeit eintragen können. Das hier angebrachte Skript funktioniert leider nicht mehr, das Gespräch wird beendet. Gibt es hier ggf. ein Update für die momentan aktuellste Version 13.25? Danke schon einmal M. Schulze getestet mit VBS nicht LUN -
Hello Tom, thanks for your reply. As we´re not running the server on premise, I´ll have to make some calls to find out how to get my hands on the logfiles. The only logs we have are the mmc logs from the maschine the swyxware administration is running on. And my usual called tech guy seems to be in holidays already I´ll come back as soon as I get any info - when ever that will be.
-
