Das Rollenmodell des jtel Systems

Ein jtel-System (jtel|ACD oder jtel|IVR oder die Kombination aus beidem) ist nach einem Rollenmodell organisiert. Folgende Rollen sind in einem solchen System definiert:

Rolle Datastore (STORE)

Die Rolle STORE ist im Prinzip ein File-Server, der eine zentral verfügbare Freigabe für alle vom System bereitzuhaltenden und zu speichernden Daten zur Verfügung stellt. Dies umfasst unter anderem:

• Das zentrale Repository für die Software und Applikationen
• Bewegungsdaten der Plattform
  • Das angepasste Skin (CSS und Logos) für das gesamte System und für die definierten Reseller
  • Die Symbole der Elemente der Routingapplikationen
  • Die mitgelieferten Systemansagen
  • Die mitgelieferten Berichte
  • Die hochgeladenen Ansagen
  • Gesprächsmitschnitte
  • ...
• Logdaten
  • Die Protokolldateien der Telefonie-Server
  • Protokolldataeien der einzelnen Anrufe

Das Storage kann innerhalb der Plattform zur Verfügung gestellt werden. Bei kleinere Installationen empfiehlt sich es dies mit auf der Rolle LB zu installieren. Bei größere Installationen kann dies separat installiert werden. 

Noch empfehlenswerter, ist dass die Rolle STORE durch die virtuelle Infrastruktur zur Verfügung gestellt wird, beispielsweise durch die Bereitstellung eines File-Shares auf einen redundanten HA Storage System.

Die Plattform greift auf die Rolle STORE mittels CIFS-Protokoll (Samba / SMB / Windows File Share), damit sowohl Linux- als auch Windows-Maschinen gleichermaßen darauf zugreifen können.

Die Rolle STORE kann auch redundant ausgelegt werden, mittels DRBD mit Samba + PCS Cluster: In dieser Lösung übernehmen zwei Maschinen die Rolle. Das Filesystem wird in Echtzeit vollrepliziert. 

Rolle Database (DATA)

Die Rolle DATA wird von einem oder mehreren MySQL Datenbankservern unter CentOS Linux 7.x eingenommen. Hier werden alle Prozeduren zur Business-Logik gespeichert und ausgeführt, die gesamten Konfigurationsdaten (Modellierung) der ACD bzw. IVR und alle Verkehrsdaten gespeichert. Diese Rolle kann (und sollte) auf verschiedenen Servern aufgeteilt werden:

• Primärer Datenbank Server: Auf diesem Server erfolgen sowohl schreibende wie lesende Zugriffe. Er wird sowohl von den Telefonie-Servern als auch von den Web Applikations-Server angesprochen. Dieser Server ist Mindestvoraussetzung und kann notfalls alle Aufgaben alleine Übernehmen.
• Statistik-Slave: In großen Anlagen ist es unter Umständen sinnvoll, auch alle Anfragen zur Bereitstellung der Echtzeitstatistiken (Supervisor und Wallboards) auf einem eigenen Datenbankserver auszulagern. Die Belastung daraus ist zwar nicht vergleichbar mit jener die sich aus den Berichten ergibt, aber bei sehr großen Anlagen sollte der primäre Server soweit wie möglich entlastet werden, da er einzig und alleine für die Verteilung im Contact-Center zuständig ist. Der Statistik-Slave wird lediglich von den Webservern angesprochen. Der Einsatz eines solchen Servers ist optional.
• Reporting-Slave: Dieser Server erlaubt nur lesende Zugriffe und wird dediziert eingesetzt, um alle Berichte darauf auszuführen. Dies bezieht sich sowohl auf abonnierte als auch unmittelbar angeforderte Berichte. Der Einsatz einen solchen Servers ist optional aber zu empfehlen, da die Queries die den Berichten zu Grunde liegen hoch komplex sind und sich negativ Verteilung und normale Operation des Systems auswirken können. Sobald bei einem Kunden regelmäßig Berichte während der Geschäftszeiten abgerufen werden, wird der Einsatz dringend empfohlen. Der Reporting-Slave wird von den Webservern angesprochen. 
• Kunden-Slave: Falls der Kunde eigenen Auswertungsroutinen schreibt, kann ein Kunden-Slave zum Einsatz kommen. Es ist zu empfehlen dafür einen dedizierten Slave zur Verfügung zu stellen, da das Risiko extrem hoch ist, dass derartige vom Kunden erstellten Anfragen ungewollte Nebeneffekte im System verursachen. Der Einsatz eines solchen Servers ist optional.

Die Rolle DATA kann auch redundant ausgelegt werden. Eine Active-Active Redundanz mit zwei Master-Server (davon einer primär) und zwei Slave Server kann über die Rolle LB so konfiguriert werden, dass einer der Master für die Schreibzugriffe genutzt wird, und die zwei Slaves für lesende Zugriffe genutzt werden. 

Rolle Web Application Server (WEB)

Die Rolle WEB wird von einem oder mehreren CentOS Linux 7.x Server eingenommen. Der Dienst wird durch eine Java-Applikation unter einen modifizierten JBOSS Applikations-Server zur Verfügung gestellt. Der Server greift schreibend und lesend sowohl auf die Rolle STORE als auch auf die Rolle DATA zu. Der Zugriff auf das jtel Portal und die jtel SOAP Schnittstellen wird mittels HTTP auf Port 8080 zur Verfügung gestellt. Benutzer-Sitzungen auf das Portal sind an dem jeweiligen Web-Server gebunden. Dies gilt auch für die SOAP v1 Schnittstelle. Die neue SOAP v3 Schnittstelle, die ab Version 3.06 zur Verfügung steht, erlaubt hingegen das Ausführen der SOAP-Abfragen einer Sitzung auf beliebige Web Server.

Rolle Load Balancer (LB)

Die Rolle LB wird von einem CentOS Linux 7.X Server eingenommen. Dieser Server stellt eine zentrale Adresse für den Zugang zum Portal und zu den SOAP Schnittstellen zur Verfügung. Hier erfolgt dann die Verteilung der Anfragen auf die zur Verfügung stehenden Web Application Server unter Berücksichtigung einer gleichmäßigen Lastverteilung, des möglichen Ausfalls einer oder mehrerer Web Server und der Dienst-Spezifischen Einschränkungen. Des Weiteren übernimmt diese Rolle auch das Bereitstellen der mittels TLS verschlüsselten Verbindung über HTTPS. Der Dienst kann sowohl auf HTTP (Port 80) und HTTPS (Port 443) angeboten werden. Bei der redundanten Auslegung der Rolle DATA, übernimmt die Rolle LB auch die Verteilung der MySQL Datenbankverbindungen.

Rolle Telephony und Application Server (TEL)

Die Rolle TEL wird von einem oder mehreren (noch) Windows Server (2012 R2 oder 2016) Maschinen eingenommen. Diese Server führen folgende Aufgaben aus:

1. Ausführung der Call-Flow-Applikationen (r5-Applikationen ausgeführt vom 8-Server) die die Media-Server Komponente ansteuern die die Telekommunikationsfunktionen ausführt. Diese Komponenten können:
   1. In Form der Software "Aculab Prosody S" (SIP) als Software auf der Maschine jeweils mit installiert sein (Standard-Installation bei den meisten Kunden)
   2. In Form von Hardware-Boxen "Aculab Prosody X" (S2M/PRI Schnittstellen mit SS7 oder QSig bzw. SIP) bereitgestellt werden
2. Ausführung von zentralen Verwaltungs- und Steuerfunktionen (r5-Applikationen ausgeführt vom 8-Server) wie z.B. Anrufverteilung, Logfile-Cleaning/Moving, Event-Processing, Autologout, Notification, usw.
3. Ausführung von Softwarekomponenten, die zur Zeit nur für Windows zur Verfügung stehen, wie z.B. Innovaphone-Connector, Starface-Connector, TAPI-Connector, E-Mail Connector.

Von diesen drei Aufgaben kann die erste redundant ausgelegt werden, wobei das Zuführen der Telekommunikation (SIP oder traditionell) jeweils dafür speziell eingerichtet werden muss.  

Genau so wie die Rolle WEB, greift die Rolle TEL lesend und schreibend auf die Rollen STORE und DATA zu. Im Gegensatz zur Rolle WEB ist hier jedoch nur Kontakt zum primären Datenbank Server erforderlich. 

Rolle Presence (PRES)

Die Rolle PRES wird von einem oder mehreren der Server eingenommen, und hat folgende Aufgaben:

• Aufnehmen von Events von externen Systemen bezüglich Zustand der Teilnehmer.
  • Telefonstatus / Status der Nebenstelle.
  • Angemeldet / Abgemeldet.
• Diese Daten dem jtel System zur Verfügung stellen indem:
  • Der entsprechende Status im jtel System vermerkt werden.
  • Ggf. je nach dem wie der Connector eingerichtet ist, die Benutzer oder TK-Benutzer im jtel System anlegen und updaten.

Je nach connector, kann die Rolle PRES auf unterschiedliche Betriebssysteme installiert werden. Die Connectoren die Javabasierend sind, können sowohl auf Windows oder Linux installiert werden. TAPI Basierende Connectoren benötigen hingegen Windows.

Referenzen:

• Plattformunabhängige Software zum Bearbeiten der originalen Diagramm-Datei: yEd Graph Editor
• Originale Diagramm Datei (yEd Format)