Saisonales Call Routing
Hallo Zusammen
Gibts es im Call Routing Manager die möglichkeit ein saisonales Callrouting einzustellen?
Im Call Routing Manager gibt es ja die Möglichkeit eine Zeitspanne zu definieren. Hierfür ist aber ein festes Datum für Beginn und Ende die Voraussetzung. Hier suche ich jedoch nach einer Möglichkeit ein Callrouting, basieren nur auf Tag und Monat zu erstellen, also jährlich wiederkehrend. So ein Routing wäre ideal, um bestimmte saisonale Einflüsse auf die Rufverteilung zu steuern. Z. B. in der Landwirtschaft oder auch im Hotelgewerbe.
Hat Jemand eine Idee ob so etwas möglich ist, und wenn ja wie, graphisch oder per script?
Alternativ wäre es eine idee für kommende Versionen.
Dankeschön vorab für eure Unterstützung
Henning
-
Hallo Hennning,
eine komplett fertige Lösung habe ich nicht. aber einen Ansatz.
Im Regel Assistenten als auch im Grafischen Skript Editor ist wie Du richtig beschreibst die Zeitraum Überprüfung starr implementiert. Im Regel Assistenten ist da auch nichts dran zu ändern, im Grafischen Skript Editor kann man aber die Zeitraum Überprüfung selber in die Hand nehmen mit ein ganz klein wenig VBSkript. Das was dazu notwendig ist, wird hier erklärt:
Um jetzt Deine Anforderung ins Spiel zu bringen, müsstest Du bei dem Start- und Enddatum einfach nur das aktuelle Jahr setzen bevor Du die Zeitraum ÜBerprüfung machst.
Basierend auf dem Beispiel aus dem obigen Blockartikel könnte das z.B. so aussehen:
In einen "Skript Code einfügen" Block den Du vor die Überprüfung setzt, packst Du folgenden Code:
sStartDate = Left(sStartDate, 6) & Year(Now)
sEndDate = Left(sEndDate, 6) & Year(Now)
UseExit = 0Du ersetzt einfach das Jahr in den angebenen Daten durch das aktuelle Jahr.
Sag Bescheid, ob Dir das so schon weiter hilft, oder Du noch Unterstützung brauchst.
Viele Grüße, Tom.
-
Hallo Tom
Sorry es hat etwas gedauert und ich bin auch mit dem Routing noch nicht final fertig aber der Script-Code dafür funktioniert so in meiner Entwicklungsumgebung.
Er sieht so aus:
Public Function IstSaisonZeit(ByVal AktuellesDatum As Date) As Boolean
Dim PruefDatum As Long
Dim AktuellesJahr As Integer
Dim Saisonbeginn As Long
Dim SaisonEnde As LongPruefDatum = 0
AktuellesJahr = 0
Saisonbeginn = 0
SaisonEnde = 0PruefDatum = CLng(AktuellesDatum)
AktuellesJahr = Year(AktuellesDatum)
Saisonbeginn = CLng(CDate("25.09." & AktuellesJahr))
SaisonEnde = CLng(CDate("27.09." & AktuellesJahr))If PruefDatum > Saisonbeginn And PruefDatum < SaisonEnde Then
IstSaisonZeit= True
UseExit = 1
Else
IstSaisonZeit= False
UseExit = 0
End IfEnd Function
Zum Inhalt:
Die gewünschten Datumsangaben, bzw. werden der Funktion übergeben. In der Funktion werden sie in fortlaufende Zahlen umgewandelt und in einer If Auswertung abgefragt. Je nach Wahrheitswert wird dann ein unterschiedlicher Ausgang (0 / 1) angesteuert und das dahinter liegende CallRouting ausgelöst.
Das ist zumindest die Idee.
Aber wie gesagt ich muss es im tast. Routing (Wirkbetrieb) noch testen
Henning
-
Hallo Tom
Ich habe den Code getestet und er funktioniert leider nicht.
Zur Vorgehensweise:
Ich habe die Function im Start-Block unter Parameter definiert. Dieser Funktion erwartet als Startparameter das aktuelle Datum und gibt als Ergebnis 0 oder 1 zurück. Diese Werte können dann als UseExit in einem Script-Code-Einfügen-Block ausgewertet werden. So zumindest meine Idee.
Im folgenden Script-Code-Einfügen Block wird die Funktion wie folgt aufgerufen:
UseExit = IstSaisonZeit(curedate(now))
Über die Registerkarte Verbindungen wird dann der Rückgabewert 0, bzw. 1 ausgewertet und dann das jeweilige Callrouting dahinter aktiviert.
Wenn man das Callrouting aktiviert funktioniert es leider nicht. Der testzeitraum liegt dabei ausßerhalb der Saisonzeit.
Wo liegt mein Fehler??
Dankeschön vorab für deine Unterstützung.
HenningAls Anlage Screenshots:
-
Hallo Henning,
ich würde Datumsvergleiche immer mit DateDiff machen. Deine Variante habe ich ehrlich gesagt noch niemals probiert.
Ebenso würde ich Dir empfehlen, Deine Funktion mit ein wenig Tracing zu versehen, so dass Du ihren Verlauf und die Ergenisse zu denen sie kommt im Server Trace nachvervolgen kannst. Mehr dazu findest Du hier:
https://www.swyxforum.com/blogs/entry/37-9-dont-be-shy-be-chatty/
Und dann würde ich Dir in Fall Deiner Funktion auch empfehlen, statt des "Script Code einfügen" Blocks, einen "Variable auswerten" Block zu nehmen. Dazu müsstest Du Deine Funktion allerdings einen boolschen Werte (true oder false) zurück geben lassen. Im "Variable Auswerten" Block musst Du Deine Funktion nur einfach aufrufen, und nicht extra erst noch einen weiteren Ausgang sichtbar schalten. Ist etwas schneller und einfacher gemacht. Mehr dazu findest Du hier:
https://www.swyxforum.com/vbscript-function-collection/introduction/introduction-r1/
-
Hallo Tom
Dankeschön für deine schnelle und hilfreiche Antwort.
Diese Code-Variante habe ich schon häufig in VB und VBA genutzt und auch getestet. (Zum Testen kann man den Code z. B. im VBA-Editor von MS-Office einsetzten und laufen lassen). Der Funktion IstSaison() wird ein Datum übergeben. (Hier bin ich mir allerdings nicht sicher was curedate() für einen tatsächlichen Wert zurückgibt, benötigt wird ein Datum im bei uns -in good old Germany- gültigen Datumsformat: xx.xx.xxx). Dabei ist das lokal gültige Datumsformat eigentlich egal. Alle Datumsangaben werden dann in eine fortlaufende Zahl, beginnend ab dem 1.1.1900 umgewandelt und dann anschließend in der If-Prüfung abgefragt. Liegt das aktuelle Datum dann innerhalb der "Saison" gibt die Funktion 1 zurück, liegt das Datum außerhalb des Bereiches, und dabei ist es egal ob vorher oder nachher, wird eine 0 zurückgegeben.
Die Deklaration der Funktion erfolgt im Startblock, der Aufruf dann folgenden VB-Block. In diesem Block wird dann das Ergebnis an UseExit übergeben. Hinter dem Ausgang 0 "hängt" dann das normale Call-Routing und hinter dem Ausgang 1 das Call-Routing für die Saison-Zeit.
Die Idee zu dieser Variante habe ich hier gefunden:
Was mir bisher fehlte, war die Möglichkeit den Ablauf des Codes zu verfolgen, um zu erkennen wo ein Fehler generiert wird. Dazu werde ich mir deinen 1. Link nochmal genauer ansehen. In diesem Zusammenhang meine Frage: Was ist gemeint mit etwas mehr Tracing. Aus VB kenne ich dort den Debug-Modus, gibt es so etwas ähnliches auch innerhalb der SWYX?
Die Idee mit der Variablen Auswertung ist mir auch schon durch den Kopf gegangen. Mir fehlt nur leider die Routine im Umgang mit dem Call-Routing da es nicht meine Kernaufgabe ist. Zudem kommt, dass sich das Call-Routing auf den Zentralruf unserer Netphone bezieht.
Sorry, ich hoffe meine Fragen klingen nicht zu banal. Das Thema Programmierung ist mir nicht gänzlich unbekannt, mir fehlt allerdings die Routine der Einbindung in das Call-Routing, deshalb bin ich dir sehr dankbar für deine Unterstützung.
Ich muss schauen wann ich wieder ein Zeitfenster bekomme um die Anregungen auszuprobieren und würde dich weiter informieren, wenn es für die Ok ist.
Nochmals mein herzliches Dankeschön für die Geduld und deine Unterstützung.
Henning -
Hallo Zusammen
Aktuell habe ich leider noch ein kleines Problem:
Die Debug-Informationen des VB-Scripts werden in eine Trace-Datei geschrieben und sind dort auswertbar, so weit so schön. Wo befindet sich nun die Trace- / Log-Datei in einer Netphone Cloud? Bei einer lokalen IpPbx befindet sie sich im Verz:
C:\ProgramData\Swyx\Traces\IpPbxSrv-xxx-yyy.logZur Administration nutze ich ausschließlich IpPbx-MMC, da ich keine eigene RNr. aus der Anlage besitze. (kein SwyxIT / SwyxON)
Im Eigenschaften Menü von SwyxServer der IpPbx-MMC gibt es zwar eine Registerkarte Dateien, dort kann ich aber keine Datei mit der Bezeichnung IpPbxSrv-xxx-yyy.log erkennen.
Ich bin an der Konsole als Advanced UC Tennant Administrator (ohne eigene RNr.) angemeldet.
Wo und wie kann ich die Trace-Datei in der Netphone lokalisieren.
Dankeschön vorab für den Support und allen ein sonniges Wochenende
Henning
-
Hallo Zusammen, hallo Tom
Ich habe einen Weg gefunden wie man ein Saisonales Callrouting einbauen kann.
Der Scriptcode war in dieser Situation nicht mein Problem, was mir fehlte war eine Idee wie ich den Code sinnhaft in das Callrouting einbaue. In der finalen Lösung habe ich dann einen "Variable auswerten" Block zwischen dem Startblock und dem eigentlichen Callrouting gesetzt. Als Parameter wird dann folgender Code übergeben:
CLng(Date) >= CLng(CDate("25.06." & Year(Date))) And CLng(Date) <= CLng(CDate("05.09." & Year(Date)))
In der Funktion wird ein Beginndatum (im Beispiel der 25. Juni) festgelegt und zwar unabhängig vom jeweiligen Jahr. Im weiteren Script wird dann das Endedatum fixiert (in diesem Fall der 5. September). Über das logische UND wird das aktuelle Datum dahingehend abgefragt, ob es sich innerhalb des Zeitfensters (25.06. bis 05.09.) befindet oder eben nicht. Liegt das aktuelle Datum innerhalb des genannten Zeitfensters, ist das Ergebnis True (Wahr), außerhalb der Saison dann False (Falsch). Über die Ausgänge des "Variable auswerten" Blocks lassen sich dann die verschiedenen Callroutings bedienen.
Die Funktion CLng wandelt dabei einen Datumswert in eine fortlaufende Zahl um. Aus meiner Sicht ist das von Vorteil, wenn man mit dem Datum rechnen möchte / muss oder man die Werte, z. B. im Tracefile vergleichen möchte. Eine fortlaufende Zahl ist dann m. E. im Bezug auf > oder < als leichter zu bewerten als ein Datum. In der Datenbankprogrammierung hat sich das für mich in der Vergangenheit immer als vorteilhaft erwiesen.Mein Dankeschön an Tom für die Tips und Ideen wie man es im Callrouting-Manger aktivieren / einbauen kann.
Falls jemand ähnliche Gedanken für ein saisonales Callrouting hat gern den Code testen.Henning
Please sign in to leave a comment.
Comments
7 comments