Tom Wellige

Hallo Stefan,

was ich meinte, war die komplette Fehlermeldung aus dem Server Trace. So wie Du sie ja auch vorher schonmal gepostet hattest.

Poste doch bitte mal die komplette Fehlermeldung und häng auch Dein Skript als .RSE Datei exportiert mit an.

Zwei Dinge:

Setz mal in der Mitte noch ein "rs.Close"

	End If

	rs.Close

	sSQL = "select * from bereit_nummern where (bereit_name = '" & name_bereit1 & "'") or (bereit_name = '" & name_bereit2 & "'")

Und am Ende ist ein "End If" zu viel:

PBXScript.OutputTrace "vTelefon1 ="  & vTelefon1
PBXScript.OutputTrace "vTelefon2 ="  & vTelefon2

PBXScript.OutputTrace "<--------- KnownCallerId"

Hallo Stefan,

mit den beiden gefundenen Namen aus der "bereit_plan1" Tabelle musst Du in der "bereit_nummern" Tabelle suchen:

sSQL = "select * from bereit_nummern where (bereit_name = '" & name_bereit1 & "'") or (bereit_name = '" & name_bereit2 & "'")

Denk abe bitte daran, dass diese Abfrage voraussetzt, dass Du immer beide Namen gesetzt hast. Für den Fall, dass nur ein Kollege Bereitschaft macht, würde ich in da sowas wie "xxx" oder irgendeine andere Zeichenkette eintragen. Hauptsache ist, das Feld ist nicht Null.

Da Du das "rs" Objekt bereits hast, musst Du es für die 2. Abfrage nicht noch einmal mittels

Set rs = CreateObject("ADODB.Recordset")

anlegen. Lass diese Zeile einfach weg.

Anschliessend musst Du davon ausgehen, dass Du 1 order 2 Datensätze zurück bekommst. Das könnte dann z.B. so aussehen:

Dim nFeld
nFeld     = 1
vTelefon1 = ""
vTelefon2 = ""

while not rs.EOF

	select case nFeld
		case 1
			vTelefon1 = rs("bereit_nummer")
		case 2
			vTelefon2 = rs("bereit_nummer")
	end select

	nFeld = nFeld + 1

	rs.MoveNext

wend

Hi all,

until now the login into the Swyx Forum was with your display name and password.

For security reasons I have changed that. From now on you need to login using your email address and password. The display name can no longer be used for logging in.

Tom.

Hi all,

an update of the forum software on the weekend ran into a problem and I needed some assitance from the manufacturer to get it up and running again.

As you can see, it is up and running again, although there are a few glitches which still need my attention.

If you find anything broken please feel free to comment in this topic. I will try to get everything fixed.

Sorry for the trouble, Tom.

Hello Ben,

this is the default behaviour of SwyxWare (for security reasons), but can be changed via a registry key.

The Enreach support is able to provide that key.

Hast Du schonmal wie von mir vorgeschlagen das Server Trace überprüft um sicher zu stellen, dass der Status der einzelnen Gruppen Mitglieder auch richtig ermittelt wird?

Das hat dann aber überhaupt nichts mit der obigen Funktion IsUserInGroup zu tun.

Da Gruppen selbst kein Call Routing haben, legt man dazu einen Dummy Benutzer an, gibt dem die ööfentliche Gruppen Nummer und das Call Routing, welches dann per "Durchstellen" an die Gruppe zustellt. Das ist auch nochmal etwas ausführlicher hier beschrieben:

• How to configure call routing for a group

Die Zuordnung in der obigen Funnktion IsUserInGroup erfolgt über den Namen des Benutzers und nicht dessen Rufnummer. Da ein Benutzer ja beliebig viele interne Durchwahlen und externe Rufnummer zugeordnet haben kann, ist der Weg über den Namen der einfachste.

Die Funktion bekommt als Parameter den Namen einer Gruppe und schaut dann, ob der aktuelle Skript Benutzer (also der für den das Call Routing gerade läuft) sich in dieser Gruppe befindet.

Ist das wirklich exakt das, was Du brauchst?

Werf doch mal einen Blick ins Server Trace, was an Status Werten ermittelt wird.

Hier wird erklärt, wie Du die das Server Trace auf einzelne Rufe und nur Call Routing Ausgaben filtern kannst:

• How to filter SwyxWare traces for call routing output of single call

Wenn ein Benutzer seine Leitungstaste sperrt sollte sein Status aus "besetzt" signalisiert werden.

Da das bei Dir scheinbar nicht passiert, stimmt vermutlich die Berechtigung zum Abfragen des Status noch nicht.

Die Berechtigung kann entweder auf Benutzer oder Gruppen Basis in der SwyxWare Administration festgelegt werden. 

Auf Benutzer Basis:

Auf Gruppen Basis (empfohlen!):

Die möglichen Status Werte werden u.a. in der UserStatus hier aus dem Forum beschrieben.

1 bedeutet abgemeldet, alles über 1 bedeutet der Benutzer ist angemeldet.

Für Deine Anwendung muss die obige Funktion IsGroupLoggedOff etwas abgewandelt werden. Die überprüft ja, ob ALLE Benutzer abgemeldet sind, Dir reicht es aber ja zu wissen, ob wenigstens ein Benutzer abgemeldet ist. Der Code für die Funktion könnte dann also wie folgt aussehen:

Please find the IsAtLeastOneMemberOfGroupLoggedOff function in the Function Collection (VBScript) and Function Collection (Lua) area of the Programming References section of the SwyxPEDIA here on Swyx Forum. 

Ich würde einen anderen Ansatz wählen:

Über die die Call Detail Records würde ich ein wenig Statistik betreiben. Mit denen kannst Du ja ermitteln, wie lange Anrufer in der Warteschlange waren (d.h. im Call Routing), was der Wartezeit entspricht.

Die Statistik würde ich in 2 Stunden Schritten für jeden Wochentag ermitteln (also z.B. Mo 08-10, Mo 10-12, Mo 12-14, etc.) und die Ergebnisse in einer extra Tabelle ablegen. Das Erstellen der Statistik läuft komplett getrennt vom Call Routing und kann beliebig erneuert/aktualisiert werden.

Wenn jetzt ein Ruf rein kommt, musst Du nur noch da nachsehen, was dort für die aktuelle Zeit und den aktuellen Wochentag hinterlegt ist und es entsprechend ansagen.

Coole Webseite! 👍

Hallo Stefan,

werf doch mal einen Blick hier drauf:

• PBXScript.PreviousScripts

Hier kannst Du abfragen, in welchen Call Routings der Ruf vorher schon gewesen ist, bevor er bei Dir ankommt.

Hallo Stefan,

sorry, sehe Deine Frage erst jetzt. Du kannst nach dem "Verbunden" Ausgang des "Durchstellen" Blocks die folgenden beiden Eigenschaften über die Server Script API abfragen. Dort drin ist jeweils die Nummer bzw. der Name des Benutzers enthalten, mit dem der Ruf verbunden wurde:

• PBXCall.ConnectedName
• PBXCall.ConnectedNumber

Wenn der Ruf später noch weiterverbunden werden sollte, werden die beiden Eigenschaften entsprechend aktualisiert. Wenn Dich das also auch interessieren sollte, musst Du nur dafür sorgen, dass Dein Skript zu dem Zeitpunkt noch läuft, und Du es noch nicht verlassen hast. Dabei hilft der "Warten auf Verbindungsende" Block. Dort kannst Du einen Timeout von z.B. 1 Sekunde setzen und die beiden Eigenschaften abfragen und dann wieder in den "Warten auf Verbindungsende" Block gehen. Wenn Du bei der Abfrage im Vergleich zur vorherigen Abfrage nun andere Werte bekommst, weisst Du, dass der Ruf weiterverbunden wurde und auch zu wem.

VisualGroups wird ausschliesslich über die entsprechende Administration konfiguriert. Dinge die dort nicht enthalten sind, stehen als Feature auch nicht zu Verfügung.

VisualGroups hat nichts mit den im GSE eingebauten Warteschlagen Blöcken zu tun, sondern ist ein komplett anderes eigenständiges Produkt, welches ins ECR lediglich eingebettet ist.

Aus Voiceworks wird Enreach: Das Unternehmen übernimmt den Namen seiner Gruppe und firmiert zukünftig als Enreach Communications GmbH.

Die beiden deutschen Unternehmen der europäischen Gruppe Enreach, die Voiceworks und die Enreach (bis 2021: Swyx Solutions) GmbH, sind in den vergangenen Jahren eng zusammengewachsen. Daher treten sie künftig auch nach außen vereint unter dem gemeinsamen Namen Enreach und einem einheitlichen Markendach im deutschsprachigen Markt auf. Zeitgleich firmiert auch Voiceworks in den Niederlanden zu Enreach um.

„Voiceworks wird Enreach, damit macht unsere Gruppe einen weiteren wichtigen Schritt auf dem Weg zu einem einheitlichen Markenauftritt und Selbstverständnis in ganz Europa. Durch die Kombination der individuellen Stärken aller Enreach Unternehmen und die vielfältigen Synergien innerhalb unserer Gruppe profitieren unsere Partner und Kunden jetzt noch direkter von unserer umfassenden Lösungskompetenz, die in Europa einzigartig ist. Dabei können sich unsere Wholesale-Partner natürlich darauf verlassen, dass wir unser Angebot weiterhin konsequent daran ausrichten, sie erfolgreich zu machen und sie in ihrem Geschäft zu unterstützen“, sagt Christoph Wichmann, Geschäftsführer der Voiceworks GmbH.

Lösungen, die Menschen in Kontakt bringen

Enreach bietet seinen Partnern und Kunden ein breites Lösungsportfolio rund um die Digitalisierung von Kommunikation und Zusammenarbeit. Das Angebot reicht von Unified Communications – aus der Cloud, als Inhouse-Installation und im hybriden Modell – über Collaboration-Lösungen, Cloud-Contact-Center-Dienste sowie KI-basierte Chat- und Voicebots bis hin zu Connectivity-Services. „Enreach ist die europäische Marke, die Menschen miteinander in Kontakt bringt. Unsere Lösungen bringen Menschen näher zusammen, ganz egal, wo sie sich aufhalten und welches Endgerät sie verwenden, damit durch Kommunikation echte Mehrwerte entstehen“, erläutert Christoph Wichmann den Anspruch von Enreach.

Fachhändler und Systemhäuser können durch eine Partnerschaft mit Enreach ihr Angebot erweitern und vom schnell wachsenden Cloud-Kommunikationsmarkt profitieren. Eine White-Label-Option ermöglicht es ihnen dabei, gegenüber ihren Kunden als eigenständiger Anbieter aufzutreten.

Durch das Rebranding ändert sich für Wholesale-Partner von Voiceworks wenig. Alle bestehenden Verträge behalten unverändert ihre Gültigkeit. Detaillierte Informationen finden Partner im InTouch-Partnerportal.

Pressemitteilung auf enreach.de

Aus Voiceworks wird Enreach: Das Unternehmen übernimmt den Namen seiner Gruppe und firmiert zukünftig als Enreach Communications GmbH.

Die beiden deutschen Unternehmen der europäischen Gruppe Enreach, die Voiceworks und die Enreach (bis 2021: Swyx Solutions) GmbH, sind in den vergangenen Jahren eng zusammengewachsen. Daher treten sie künftig auch nach außen vereint unter dem gemeinsamen Namen Enreach und einem einheitlichen Markendach im deutschsprachigen Markt auf. Zeitgleich firmiert auch Voiceworks in den Niederlanden zu Enreach um.

„Voiceworks wird Enreach, damit macht unsere Gruppe einen weiteren wichtigen Schritt auf dem Weg zu einem einheitlichen Markenauftritt und Selbstverständnis in ganz Europa. Durch die Kombination der individuellen Stärken aller Enreach Unternehmen und die vielfältigen Synergien innerhalb unserer Gruppe profitieren unsere Partner und Kunden jetzt noch direkter von unserer umfassenden Lösungskompetenz, die in Europa einzigartig ist. Dabei können sich unsere Wholesale-Partner natürlich darauf verlassen, dass wir unser Angebot weiterhin konsequent daran ausrichten, sie erfolgreich zu machen und sie in ihrem Geschäft zu unterstützen“, sagt Christoph Wichmann, Geschäftsführer der Voiceworks GmbH.

Lösungen, die Menschen in Kontakt bringen

Enreach bietet seinen Partnern und Kunden ein breites Lösungsportfolio rund um die Digitalisierung von Kommunikation und Zusammenarbeit. Das Angebot reicht von Unified Communications – aus der Cloud, als Inhouse-Installation und im hybriden Modell – über Collaboration-Lösungen, Cloud-Contact-Center-Dienste sowie KI-basierte Chat- und Voicebots bis hin zu Connectivity-Services. „Enreach ist die europäische Marke, die Menschen miteinander in Kontakt bringt. Unsere Lösungen bringen Menschen näher zusammen, ganz egal, wo sie sich aufhalten und welches Endgerät sie verwenden, damit durch Kommunikation echte Mehrwerte entstehen“, erläutert Christoph Wichmann den Anspruch von Enreach.

Fachhändler und Systemhäuser können durch eine Partnerschaft mit Enreach ihr Angebot erweitern und vom schnell wachsenden Cloud-Kommunikationsmarkt profitieren. Eine White-Label-Option ermöglicht es ihnen dabei, gegenüber ihren Kunden als eigenständiger Anbieter aufzutreten.

Durch das Rebranding ändert sich für Wholesale-Partner von Voiceworks wenig. Alle bestehenden Verträge behalten unverändert ihre Gültigkeit. Detaillierte Informationen finden Partner im InTouch-Partnerportal.

Pressemitteilung auf enreach.de

Die Warteschlange stellt die rufe in ihr auf ein bestimmtes Ziel zu (egal ob einzelner Benutzer oder Benutzergruppe).

Beim Ziel wird jedoch in keinem Fall das Call Routing des Ziels gestartet. Das wäre kontraproduktiv, da sich dieses Call Routing den Ruf dann schnappen würde, und er damit aus Sicht der Warteschlange zugestellt wäre. 

Umleitungen sind grundsätzlich Bestandteil des Call Routings, somit werden sie ebenfalls nicht ausgeführt, wenn das Ziel für sich eine sofortige Umleitung konfiguriert.

Wenn der Benutzer unter dem das Warteschlangen Call Routing läuft und der Ziel Benutzer jedoch identisch sind, dann sollte Deine Anwendung funktionieren. Dazu muss die Wartenschlangen Regel nur unter den Weiterleitungsregeln im Call Routing Manager stehen.

Wenn die beiden Benutzer jedoch nicht identisch sind, hat der Ziel Benutzer keine Möglichkeit der Einfussnahme auf das Warteschlagen Call Routing Skript. Denkbar wäre hier aber eine Lösung über die persistenten Variablen (PV). In einer solchen (globalen) PV wird das Ziel der Warteschlange gespeichert. Der Ziel Benutzer kann einem "Manager" Benutzer anrufen, dess Call Routing per DTMF nach dem neuen Ziel fragt, und dieses dann in die PV schreibt. Das Warteschlangen Call Routing schaut seinerseits in diese (globale) PV im Ziel Feld.

Hallo Jochen,

der folgende Blog Artikel beschreibt die Möglichkeiten die Du hast:

• https://www.swyxforum.com/blogs/entry/11-4-take-me-to-your-leader/

Hallo Stefan,

gern geschehen. Und nun weisst Du auch noch zusätzlich wo Du ECR Hilfe bekommen kannst

Ein schönes Wochenende wünsche ich!

Tom.

Prinzipiell gibt es einen VBScript Debugger, es gibt aber zahlreiche Gründe, weswegen der im Call Routing keine gute Idee ist. 

Für das debuggen gibt es das SwyxWare Server Trace. Der folgende Post erklärt, wie man das so weit eindampft, dass man nur noch einen einzigen Ruf sieht, und für den auch nur Call Routing relevante Ausgaben:

• https://www.swyxforum.com/topic/4037-how-to-filter-swyxware-traces-for-call-routing-output-of-single-call/

Der folgenden Blog Artikel beschreibt, wie man eigenes Tracing ins Call Routing (sinnvoll) einbaut:

• https://www.swyxforum.com/blogs/entry/37-9-dont-be-shy-be-chatty/

Hallo Stefan,

ohne die Funktion "GetUserState" im Detail zu kennen, sollte der Aufruf in etwa so aussehen:

if GetUserState(PrimaryGroup, 20, True) then
	'...

elseif GetUserState(SecondaryGroup, 20, True) then
	'...

end if

Was Du dann in den jeweiligen Fällen machst hängt von Deiner Anwendung ab, die ich nicht kenne.