Jump to content

Verwendung von PBXUser.DoNotDisturb()


Marcel Bahlke
 Share


Go to solution Solved by Tom Wellige,

Recommended Posts

Guten Tag,

 

folgende Problemstellung bei Verwendung von Netphone 12.20.:

Wir haben ein umfangreiches Call-Routing für die Telefonzentrale mit diversen Ansagen und Prüfungen auf Bürozeiten. Die Zentrale ist an einen Arbeitsplatz und eine Person gebunden.

Wenn die Person an diesem Arbeitsplatz z.B. krank ist, möchten wir auf einfachem Wege das Ganze umleiten unter Beibehaltung und ohne Änderung des Routings, aber ohne Verzögerungen (Bei nicht-Annahme des Gesprächs wird nach 30s weitergeleitet, dass soll aber in diesem Fall nicht sein).

Gedacht war nun, ein Call-Routing einzurichten, dass PBXUser.DoNotDisturb()  (oder PBXUser.Away()) per VB auf true zu setzen und das Haupt-Call-Routing dann um eine Abfrage dieses Status zu erweitern

image.png.cdf3a8da4bfe46d628722f2d436b8678.png

 

Das Setzten des Statuts führt aber dazu, dass die Nummer von außen nicht mehr erreichbar ist (angeblich ist die Nummer nicht vergeben). Was mache ich falsch?

Oder denken wir zu kompliziert und es gibt eine einfachere Lösung?

 

Vielen Dank für Eure Tipps!

 

 

Link to comment
Share on other sites


Wenn ich Dich richtig verstehe, willst von quasi von Hand die Zustellung von Rufen auf diesen Benutzer (im Call Routing auf das "urpüngliche Ziel") auf einen anderen Benutzer umstellen können. Als Flag dafür willst Du DND benutzen.

 

Sofern Du Deinen Zentrale Benutzer nicht von Hand auf "Lua" umgestellt hast, basiert Dein Call Routing auf "VBScript". In Deinem Screenshot verwendest Du aber "Lua" Syntax. Ich hab das nicht ausprobiert, glaube aber nicht, dass VBScript damit glücklich ist.

 

Du bist in der Server Script API Referenz vermutlich versehentlich in der "Lua" Version gelandet. Hier findest Du die "VBScript" Version.

 

ABER...

 

Ich würde als Flag mit welchem Du markieren willst, wohin zugestellt werden soll nicht DND oder Away nehmen. Die haben um Zweifelsfall Einfluss auf die Rufzustellung auf den Benutzer. Statt dessen würde ich persistente Variablen (PV) vorschlagen wollen. Eine solche merkt sich ihren Inhalt dauerhaft auf über das Skript Ende hinaus in einer Datenbank und ihr Inhalt kann entweder nur für die aktuellen Benutzer oder alle Benutzer erreichar sein. Keine Sorge, die PVs kümmern sich um die Datenbank, Du hast damit nichts zu tun. Für Dich ist das nur eine Variable in die Du etwas rein tust oder heraus liest.

 

In dem PV Projekt findest Du ein Beispiel für eine Nachtschaltung, die Du hier eins zu eins übernehmen kannst! Statt den Status von DND abzufragen bevor Du zustellst, fragst Du einfach die persistente Variable ab. Das sieht in der Praxis dann wirklich einfach und übersichtlich aus (siehe hier). In dem Beispiel ist ein Manager Skript enthalten, über das Du die PV entweder einfach per DTMF Menü oder Nachwahlziffer umstellen kannst (siehe hier).

 

 

Link to comment
Share on other sites


Hallo Tom,

 

erstmal herzlichen Dank für die Tipps. Die Lösung mit dem Night Switch ist echt elegant!

 

Ich habe aber bei der Umsetzung ein Problem.

Die Datenbank und die Tabelle habe ich auf dem Server entsprechend der Anleitung angelegt (Ist bei mir Netphone und der Service User heißt dann NetPhoneService - aber das nur nebenbei).

 

image.png.2fc71fcf90db605877f7f854d0536782.png

 

Anschließend die Scripte importiert und einem Dummy-User das Call Routing aus NightSwitchManager.rse verpasst. 

 

image.png.9101f78cb792edda8618ce939b47017e.png

 

Wenn ich jetzt die Durchwahl anwähle wird mir "0" angesagt, dann ein Piep und wenn ich dann 1 drücke (oder auch Durchwahl&1 direkt wähle) wird mir wieder "0" angesagt. In der Tabelle wird anscheinend keine Variable gespeichert.

Muss irgendein Dienst noch neu gestartet werden?

Könntest Du mich in die richtige Richtung schubsen?

In den Ereignisanzeigen (Windows + SQL-Server) finde ich zumindest keine Fehlermeldung.

 

Viele Grüße

Marcel

 

image.png

Link to comment
Share on other sites


  • Solution

Hallo Marcel,

 

spontan sehe ich da kein offensichtliches Problem. Wenn Du willst, kannst Du mir ein aktuelles Server Trace schicken (per Forum Nachricht, bitte nicht hier öffentlich posten), dann werfe ich da mal einen Blick rein. Die PVs erzeugen einiges an Trace Ausgaben mit deren Hilfe das Problem schnell zu finden sein sollte.

 

Hier findest Du eine Anleitung wo das Trace zu finden ist, und wie Du es für Dich ganz einfach lesbar machen kannst.

 

Link to comment
Share on other sites


Für die, die es interessiert:

Das Problem war, dass wir mit einer älteren GSE-Version arbeiten und daher nicht die neueste Script-Version verwenden konnten, deshalb wurden die Parameter im GSE-Block des Call Routings "Night Switch" nicht angezeigt.

Diese waren aber erforderlich, da der Standard Connection String zur Datenbank nicht funktioniert (Dieser enthält Data Source=Server\SQLEXPRESS - unsere DB hatte aber keinen Instanznamen).

Leider wurde anscheinend irgendwo etwas gecached. Die neueste Script-Version musste entfernt werden, in dem erst die "actionPersistentVariable" in der Aktionsfolge-Definition gelöscht wurde und dann erst die Dateien des Scripts über die Server-Administration gelöscht und durch die älteren Versionen ersetzt wurden. Danach hieß es dann in der Aktionsfolge-Definition richtig nur "PersistentVariable", die Parameter im GSE-Bock des "Night Switch" wurden angezeigt und in meinem Fall brauchte ich nur Server und Tabellenname eintragen und es lief!

Herzlichen Dank an Tom für die erstklassige Hilfestellung!

 

Viele Grüße!

Link to comment
Share on other sites


Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and have taken note of our Privacy Policy.
We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.