Tom Wellige

Schau mal ob Du eine Datei

C:\ProgramData\Swyx\license.dat

findest. Wenn ja, lösche sie.

Die Nummer die der Anrufer sieht wird automatisch aktualisiert, sobald der Ruf verbunden ist. Er wird also sehen, mit welchem der 4 MAs er verbunden ist.

Es ist nicht möglich, dem Anrufer etwas anderes zu signalisieren.

Du könntest ihm evtl. eine Ansagen vorspielen, die ihm sagt, mit welchem "Dienst" er verbunden wird.

Enreach hat einen Posten als Operations Engineer (all genders) zu besetzen.

Alle weiteren Details hierzu finden Sie hier:

https://www.enreach.de/unternehmen/karriere/stellenangebote.html?jh=uzr62wbg6hh3qp3c2t2gnjih0fui262

Hallo Basti,

bzgl. eines Schalter in der Skin eines Clients: das geht wohl am einfachsten mit einem "WebExtension" Skin Element. Mit ihr kannst Du eine Webseite in einem Bereich Deiner Skin anzeigen. 

Der GEdanke ist, dass Du eine kleine Webanwendung erstellt, die nichts weiter macht, als den Schalter passend zur aktuellen Gruppenzugehörigkeit anzuzeigen und bei einem Klick auf den Schalter die Gruppenzugehörigkeit ändert. Die Webseite ruft dazu dann einfach den Powershell Befehl auf. Ein kleines Beispiel für eine solche funktionale WebExtension befindet sich übrigens in den Persistenten Variablen.

23 hours ago, bastixko said:

Hier haben wir uns glaube ich missverstanden. Ich benötige genau das Gegenteilige. Im Prinzip soll derjenige, der den Support anruft, in den jeweiligen Szenarien individuelle Status-Meldungen (Uni, Urlaub, etc.) zurückgemeldet bekommen. 

Sind das interne oder externe Anrufer?

Versuch den Aufruf mal über die folgende Funktion. Die schreibt alles was das aufgerufene Programm zurück gibt ins Server Trace. Damit kommst Du evtl. weiter.

'----------------------------------------------------------------
' LaunchCmdEx
'
' Executes the given command and writes its output into the
' server trace.
'
' Parameter:
'   sCommand            command to be called
'
' Return:
'   none
'----------------------------------------------------------------
Function LaunchCmdEx( sCommand )
    PBXScript.OutputTrace "------> LaunchCmdEx ( " & sCommand & " )"

    On Error Resume Next

    Dim objWsh, objWshScriptExec, objStdOut, objStdErr
    Dim sStdOut, sStdErr

    Set objWsh = CreateObject("Wscript.Shell")
    Set objWshScriptExec = objWsh.Exec(sCommand)

    if Err <> 0 then
        PBXScript.OutputTrace "Error executing command!"
        PBXScript.OutputTrace Err & ": " & Err.Description
        Err.Clear
    end if

    Set objStdOut = objWshScriptExec.StdOut 
    sStdOut = Trim(objStdOut.ReadAll)
    if sStdOut <> "" then
        PBXScript.OutputTrace "StdOut:"
        PBXScript.OutputTrace sStdOut
    end if

    Set objStdErr = objWshScriptExec.StdErr 
    sStdErr = Trim(objStdErr.ReadAll)
    if sStdErr <> "" then
        PBXScript.OutputTrace "sStdErr:"
        PBXScript.OutputTrace sStdErr
    end if

    Set objWsh = Nothing    

    PBXScript.OutputTrace "<----- LaunchCmdEx"
End Function

Last weekend I had released the version 1.3.0 of the Persistent Variables. 

This version had some improvements for using the varibles in group call routings and also provided information about who created or modified a variable and when.

Turned out I was too quick or in other words didn't thought too deep about those two improvements. They both needed a more or less complete rework to make them fully functional.

The outcome is version 1.4.0 with a lot of the new properties. The variables are now fully functional in user and group call routings!

All changes are listed here:

You can download the new verion here:

And finally read all documention here (including necessary update instructions):

Enjoy!

11 hours ago, bastixko said:

Die Funktion LaunchCmd habe ich wieder im Start-Block eingefügt. Dann rufe ich in einem weiteren "Skript Code"-Block folgendes auf:

UseExit = LaunchCmd(powershell -command "Connect-IpPbx; Remove-IpPbxGroupMember -GroupName "EDV-Support" -UserName 'XXXX, XXXXX' -Confirm:$false; Disconnect-IpPbx"")

 

Die Funktion erwartet einen String Parameter. Das was Du dort als Parameter rein geschrieben hast ist ungültiger VBSkript String. Du musst den String mit " beginnen and beenden und alle " in der Zeichenketter als "" schreiben damit VBSkript erkennt, dass sie Bestandteil der Zeichkette sind und diese nicht beenden.

Hiermit sollte es besser gehen:

UseExit = LaunchCmd ("powershell -command ""Connect-IpPbx; Remove-IpPbxGroupMember -GroupName ""EDV-Support"" -UserName 'XXXX, XXXXX' -Confirm:$false; Disconnect-IpPbx""""")

11 hours ago, bastixko said:

Hier meinte ich tatsächlich das Telefon des Anrufers. Gibt es da auch eine Möglichkeit oder ist das vergebene Mühe?

Dann gilt das, was ich in meiner letzten Antwort geschrieben habe. Ich weiss nicht, ob die manipulierten Were von Ascom angezeigt werden oder nicht. Du musst das einfach mal ausprobieren.

What's New in Version v1.4.0:

This version adds the following features and fixes:

• Added new read-only properties CreatedByName, CreatedByNumber, ModifiedByName and ModifiedByNumber.
• Removed previously added properties "CreatedBy" and "ModifiedBy" again.
• Added new properties CallerName and CallerNumber to overwrite the defaults for the above new properties.
• Added new property GroupID for better handling of group call routing scripts.
• Added new scope SCOPE_GROUP for better handling of group call routing scripts.
• Fixed a problem with group call routings where user and group scopes could interfere.
• Fixed a problem with tracing which was most likely cause by a Micosoft Scripting Engine bug at a 29th of February.

Setup instructions on how to update your existing installation to this version can be found here:

• 2.4 - Setup updated versions

Hallo Mathias,

ich würde Dir hier gerne helfen, aber mit diesem Thema habe ich bisher genau gar keine eigene Erfahrung gesammelt. Habe also leider kein Wissen, was ich mit Dir teilen kann.

2 hours ago, bastixko said:

Ist das so richtig? Hier bekomme ich leider immer noch den Wert "0" zurückgewiesen. Getestet habe ich es mit dem Gruppen-Call-Routing. Als User-Call-Routing funktioniert es.

Ja, das hast Du richtig konfiguriert. Wenn Dein Call Routing auf einer Gruppe läuft, dann funktioniert die Statusabfrage anderer Benutzer derzeit aber leider nicht. Da Du in Deinem initialen Post von einem Dummy Benutzer gesprochen hattest, hatte ich das zuvor nicht erwähnt. Du musst also tatsächlich in diesem Fall noch über einen Dummy Benutzer gehen.

2 hours ago, bastixko said:

Dann habe ich es nicht gut erklärt. Ich möchte, dass auf dem Telefon ein individueller Status übermittelt wird.

Auf dem Telefon des Anrufers oder des angerufenen? Da Du von Euren D843 sprichst, vermute ich mal, dass Du das Telefon des angerufenen meinst.

Prinzipiell kannst Du vom Call Routing aus den Namen und die Nummer des Anrufers manipulieren. Ob das Ascom Handset das auch entsprechend anzeigt, weiss ich nicht. Das müsstest Du einfach mal ausprobieren.

Wie man die beiden Werte manipuliert wird hier erklärt:

• PBXCall.CallingPartyName
• PBXCall.CallingPartyNumber

Denkbar wäre also, dass Du den angezeigten Namen einfach manipulierst und den gewünschten Status vor den originalen Namen setzt. Das ganze machst Du, bevor Du den Ruf per "Durchstellen" an den MA gibst.

PBXCall.CallingPartyName = "Uni-" & PBXCall.CallingPartyName

Moin!

Das Call Routing sieht alles erstmal gut und richtig aus. 

Zu Deinen Fragen:

23 minutes ago, bastixko said:

MA3 und MA4 sollen sich dynamisch aus dieser Gruppe an- und abmelden können.

Das geht nicht so ohne weiteres, da Benutzer ihre Gruppenzugehörigkeit nur abfragen aber nicht beeinflussen können. Zumindest nicht über die normalen Call Routing Schnittstellen. Das lässt sich aber über den "Config Data Store" und damit auch über PowerShell machen. Hier ist ein entsprechendes PowerShell Beispiel:

• Benutzer aus Gruppe entfernen

Mittels der folgenden Funktion kannst Du das Skript ganz einfach vom Call Routing aus aufrufen:

• LaunchCmd

Denbar wäre also ein Call Routing auf einem Dummy Benutzer, welchen die Mitarbeiter (3 und 4) anrufen können. Dieses Skript prüft welcher der beiden MAs anruft, und setzt ihn anschliessend in die Gruppe wenn oder gerade nicht drin ist oder anders herum. Prakrisch wäre es dann auch dem MA mit einer kurzen Ansagen mitzuteilen ob er setzt drin ist oder nicht. Statt des automatischen hin und her schaltens kannst Du dem MA natürlich auch ein DTMF Menü anbieten ("DTMF Zeichen empfangen" Block) in welchem er sich selbst dazu oder weg bucht.

33 minutes ago, bastixko said:

Der Anrufer soll signalisiert bekommen, zu wem er gerade durchgestellt wird.

Das geht nicht. Das was der Anrufer zu sehen bekommt, kann nicht manipuliert werden. Seine Anzeige ändert sich erst, wenn das Ruf verbunden wurde, d.h. entweder Dein Call Routing eine Ansage abspielt oder ein MA den Höhrer abgenommen hat.

35 minutes ago, bastixko said:

Hier habe ich deine Funktion CheckCallerInDatabase etwas angepasst. Dieser Block funktioniert einwandfrei.

Top! 

36 minutes ago, bastixko said:

Zweiter Schritt ist dann zu prüfen, ob der Mitarbeiter auch swyxseitig erreichbar ist. Hierzu nutzen ich deine Funktion "UserStatus". Im Gruppen Call-Routing erhalte ich immer den Rückgabewert 0 "State Unavailable". Bug?

Nö, kein Bug. Schau nochmal etwas genauer auf die Seite der UserStatus Funktion, der erste Satz unter dem VBScript Code. Du bekommst eine "0" zurück, wenn zwischen dem Benutzer unter dem Dein Call Routing läuft und dem Benutzer dessen Status Du abfragst keine gegenseitige Status Signalisierung konfiguriert ist.

39 minutes ago, bastixko said:

Eine zusätzliche Frage ist mir aufgekommen. Kann ich die Signalisierung "besetzt" manipulieren in bspw. "Urlaub" oder "Uni"?

Du kannst doch vollkommen frei entscheiden, was Du im Besetzt Fall i Call Routing machtst. Ich verstehe daher die Frage nicht so ganz.

Die Frage aus Deinem Call Routing:

Quote

Wenn die User sich den Status "Nicht stören" setzen bekommen Sie den Anruf nicht weitergeleitet. Ich möchte irgendwie verhindern, dass alle Mitarbeiter sich zeitgleich den Status "nicht stören" setzen.

Denkbar wäre, dass wenn Du in Deinem Call Routing feststellst, dass alle MAs ihren Status auf "nicht stören" gesetzt haben, Du dann gezielt bei einem MA diesen Status wieder ausschaltest. Dazu musst Du eine kleines Call Routing bei diesem Benutzer an den Start bringen, welches sinnvoller Weise erst prüft ob Dein grosses Call Routing anfruft, und wenn ja, den Status PBXUser.DoNotDisturb auf False setzt. In Deinem grossen Call Routing Script musst Du im "Durchstellen" Block den Parameter "mit dem Call Routing des Ziels fortfahren" setzen.

Es bietet sich auch an, dieses kleine Call Routing um den "nicht stören" Status des Benutzer zu manipulieren im "PreProcessing" dieses Benutzer zu hinterlegen. Damit taucht es nicht im Call Routing Manager des Benutzers auf und er kann es somit auch nicht selbst deaktivieren.

Hast Du Zugang zum Enreach Partner Net? Wenn ja, findest Du hier ein Webinar, welches umfassend erklärt, was das "PreProcessing" ist und wie man es sich zu Nutze machen kann. In Deinem Fall bleibt das "PreProcessing" auf alle Fälle lokal bei dem entsprechenden Benutzer und Du macht es nicht global.

Soderle, ich denke damit habe ich Dich erstmal eine Zeit lang beschäftigt

Hallo,

der Übersichtlichkeit halber habe ich Deinen Post mal aus dem Englishen Topic rausgeholt und in hier im Deutschen Bereich in einen eigenen Topic verwandelt.

Beschreibe doch mal ein bisschen besser wie genau Du den Status der einzelnen Mitarbeiter ermittelts, und ob überhaupt. 

Ich denke am einfachsten wäre es, wenn Du Deine GSE Regel als .rse Datei über das "Datei" Menü exportierst und hier mit anhängst. 

Ansonsten ist die Gefahr viel zu gross, dass wir hier Ping-Pong artig an einander vorbei reden.

Da ich die kommenden Tage mit anderen Dingen komplett dicht bin, habe ich die Entscheidung gerade selber gertroffen (Variante 1 - NULL) und eine neue Version der Persistenten Variablen erstellt, die Deinen Feature Request enthält.

What's New in Version v1.3.0:

This version adds the following features:

• New read-only properties "Created", "CreatedBy", "Modified" and "ModifiedBy" added. 
• New method "Forget" added to forget a variable. This deletes the variable from the database.

Setup instructions on how to update your existing installation to this version can be found here:

• 2.4 - Setup updated versions

Hint: if you do not need the new features of this version and are in general hesitent when it comes to work directly on a database, there is no need to update to version 1.3.0. Beside the new features this version does not contain any bugfixes/changes compared to 1.2.1.

Hallo Marvin,

wenn ich das implementiere, würde ich 2 verschiedene Zeitstempel verwenden: "Created" und "Modified". 

Man wird also sehen können, wann eine Variable erstmalig und zuletzt gesetzt wurde. 

Soweit so gut. Wenn eine Variable aber noch niemals verändert wurde, habe ich zwei Möglichkeiten, was ich in diesem Fall bei "Modified" zurück geben könnte:

1. NULL 
   Du kannst dann sehr einfach vorab mittels "IsNull" prüfen ob Du einen Zeitstempel bekommen hast, bevor Du irgendetwas damit versuchst zu machen was dann evtl. über das NULL stolpert
    
2. Ein Standard Datum (z.B. 01.01.2000)
   Damit bekommst Du in jedem Fall ein gültiges Datum zurück und musst Dir keine Sorgen machen, dass Dein Code nachfolgend über ein NULL stolpern könnte. Du siehst dem Rückgabewert aber nicht mehr auf den ersten Blick an, dass die Variable noch niemals verändert wurde.

Da Du Dir das Feature gewünscht hast, überlasse ich die Entscheidung einfach Dir. Ich selbst tendiere für den ersten Fall.

Für den Fall, dass eine persistente Variable verwendet wird, die mit einer älteren Version erzeugt wurde, ist natürlich der "Created" Zeitstempel nicht erzeugt worden. Das heisst, hier würde dann die gleiche Logik greifen.

Das ist ein interessanter Feature Request für die persistenten Variablen.

Ich setze das mal auf meine Liste für ein nächstes Update. 

Einen zeitlichen Rahmen dafür kann ich Dir im Augenblick allerdings nicht geben.

Tut mir leid, dazu kenne ich im Augenblick keine Möglichkeit. 

Guten Morgen Antonio,

freut mich zu hören, dass alles so läuft wie es soll  

Liebe Grüße, Tom.

Hallo Antonio,

noch eine kleine Anmerkung zu dem "Variable auswerten" Block: Du kannst dort alles rein tun, was Du möchtest. Die einzige Bedingung ist, dass es nach VBScript Syntax insgesamt entweder Wahr (True) oder Falsch (False) ergeben muss.

Und für den Fall, dass Du darüber noch nicht selbst hier im Forum gestolpert bist, es gibt eine umfgangreiche Sammlung von Links zu allem was irgendwo online zum Thema Call Routing verfügbar ist. Da lohnt es sich ggf. auch mal in Ruhe durch zu stöbern.

• ECR - Useful Link Collection

Hallo Marvin,

wenn Du das ganze über den Status verschiedener Benutzer lösen willst, dann kommt Du tatsächlich nicht an mehreren Lizenzen vorbei. 

Du kannst im Call Rouing nicht den Status eines anderen Benutzers setzen, sondern nur den eigenen. 

Den Ansatz über persistente Variablen würde ich an dieser Stelle auf alle Fälle vorschlagen wollen.

Schau Dir dort mal das Beispiel B.1 an. Hier zeigt eine einfache kleine Webseite den Inhalt einer persistenten Variable an (in diesem Fall in Form von unterschiedlichen Hintergrundfarben). 

In der Skin des SwyxIt! Clients kannst Du nun hergehen, und ein "WebExtension" Element hinzufügen. Dieses Element zeigt den Inhalt einer konfigurierten Webseite an. Damit ist es also ganz einfach möglich, eine oder mehrere verschiedene persistente Variablen für den Benutzer zu visualisieren.

Hallo Antonio,

ja, Du kannst in "Variable auswerten" Blöcken auch Vergleiche in der Art > oder >= oder < oder <= oder = verwerden. Das ist kein Problem, Du musst nur darauf achten, dass Du nicht Äpfel mit Birnen vergleichst. Alles was als DTMF eingegeben wird, ist eine Zeichenkette (String). Du musst also darauf achten, dass Du diese Eingabe auch nur mit Zeichenketten vergleichst, also z.B. 

sDTMF >= "12345"

Du kannst auch mehrere Vergleiche gleichzeitig anstellen, und diese mittels "and" miteinander verknüpfen. In diesem Fall würde ich aber die einzelnen Vergleiche in Klammern setzen. Das erhöht die Lesbarkeit enorm:

(sDTMF >= "12345") and (sDTMF <= "54321")

Aber...

Statt der vielen "Variable auswerten" und "Durchstellen" Blöcke die Du dann benutzt um auf Deine 16 verschiedenen VG Warteschlagen durchzustellen, würde ich das (zumindest aus meiner Sicht) noch etwas eleganter lösen: mittels einer kleinen VBScript Funktion. Damit sieht Dein Call Routing dann so aus:

Im "Durchstellen" Block wird eine VBSkript Funktion "GetDestination" aufgerufen (die sich im "Start" Block befindet). Die verschiedenen PLZ Bereiche werden in einem Array zusammen mit dem dazugehörigen Durchstell Ziel definiert. Die Funktion geht einfach durch dieses Array durch, sucht den passenden Bereich und gibt dessen Durchwahl zurück. Wird kein Bereich gefunden wird eine Standard Durchwahl zurück gegeben.

Const DEFAULT_DESTNATION = "100"

Dim PLZ_Array
'         Min,     Max,     Destination
PLZ_Array = Array( _
    Array(80000,   80999,   "101"), _
    Array(81000,   81999,   "102"), _
    Array(82000,   82999,   "103"), _
    Array(83000,   83099,   "104"), _
    Array(83100,   83199,   "105"), _
    Array(83200,   83299,   "106"), _
    Array(83300,   83399,   "107"), _
    Array(83400,   83499,   "108"), _
    Array(83500,   83599,   "109"), _
    Array(83600,   83699,   "110"), _
    Array(83700,   83799,   "111"), _
    Array(85000,   85999,   "112"), _
    Array(86000,   86999,   "113"), _
    Array(88000,   88999,   "114"), _
    Array(89000,   89999,   "115"), _
    Array(91000,   91999,   "116") _
 )


Function GetDestination ( sPLZ )
    PBXScript.OutputTrace "-----> GetDestination ( " & sPLZ & " )"

    Dim sReturn
    sReturn = DEFAULT_DESTNATION

    If IsNumeric(sPLZ) Then 
    
        Dim nPLZ
        nPLZ = CLng(sPLZ)

        Dim i
        For i = LBound(PLZ_Array, 1) to UBound(PLZ_Array, 1)

            If (nPLZ >= PLZ_Array(i)(0)) And (nPLZ <= PLZ_Array(i)(1)) Then
                PBXScript.OutputTrace "Found PLZ range " & i+1 & "(" & PLZ_Array(i)(0) & "-" & PLZ_Array(i)(1) & ")"
                sReturn = PLZ_Array(i)(2)
            End If

        Next

        If sReturn = DEFAULT_DESTNATION Then
            PBXScript.OutputTrace "No PLZ range found, using default destination."
        End If

    Else
        PBXScript.OutputTrace "Invalid PLZ, using default destination."
    End If

    GetDestination = sReturn

    PBXScript.OutputTrace "sReturn = " & sReturn
    PBXScript.OutputTrace "<----- GetDestination"
End Function

Dieser Ansatz ist maximal flexibel. Du kannst mit fast keinem Aufwand die PLZ Bereiche beliebig erweitern.

Die Funktion hat wie Du siehst auch einige Trace Ausgaben, d.h. man kann über das Server Trace auch alles genau nachvollziehen, was dort passiert. Hinweise zum lesen des Server Traces (aus Call Routing Sicht) findest Du hier.

Ich hänge Dir auch noch meine GSE Regel mit an, in der ich das gerade ausprobiert habe:

PLZ.rse

Einfach eine neue leere GSE Regel öffnen und dort über das Menü "Datei | Importieren..." diese Datei auswählen.

Das geht natürlich auch

Oops, das hatte ich vergessen zu beatworten.

Das kannst Du über das PBXConfig Objekt abfragen:

Hallo Dirk,

wenn Du eine Ansage selber spielen willst, musst Du die Konfiguration im Trunk wieder wegnehmen, damit mehr als 2 Anrufe reinkommen können. 

Ein dritter und vierter Anrufer bekommen dann Deine Ansage, jeder weitere bekommt ein besetzt und Du kannst dann auch nicht mehr raus telefonieren.

Die Lösung ist evtl. auf Seite Deines Providers zu suchen, der eine Ansage ab dem zweiten Ruf einspielt. Damit landen weitere Rufe nicht mehr bei Dir und machen Dir die weiteren Kanäle nicht mehr dicht (nur damit Du eine Ansage spielen kannst).

Hallo,

Du hast da schon die richtige Zeile im Server Trace gefunden. Das "Reject" ist genau das, wonach Du Ausschau halten musst.

Es einfacher sollte es aber sein, wenn Du in die Call Detail Records (CDR) der SwyxWare schaust. Dort findest Du das "Reject" in der "Reason" Spalte in diesen Fällen.