Systemvoraussetzungen für On-Premises-Betrieb
Auf dieser Seite finden Sie Informationen, wie unser CRM-System in Ihrer Systemlandschaft („On-Premise“) betrieben werden kann.
CURSOR Systemarchitektur
Die CURSOR Systemarchitektur umfasst vier Layer: Presentation, Application, Data und Services.
In der Präsentationsschicht stehen den Anwendern z. Zt. vier Clients zur Verfügung: Rich Client (Windows Client), Web Client, iOS- und Android-App. Über die Infoboard-Technologie können fremde Webapplikationen oder einzelne Webseiten in die Oberfläche dieser Clients eingebettet werden.
Application- und Data-Layer können wahlweise in der Kundenumgebung (On-Premise) oder in einer Private Cloud betrieben werden. Dies kann entweder die von CURSOR betriebene CURSOR Application Cloud oder eine Cloud-Umgebung nach Wahl des Kunden (vCloud, Azure, AWS, ...) sein.
In der auf Microservices basierenden CURSOR Service Cloud stehen ergänzende Dienste zur Verfügung, die den Anwendungsnutzen individuell erweitern. Auf diese Services kann der Application-Layer im Bedarfsfall (on-demand) zugreifen.
An Stelle der Frontend-Clients (Rich Client, Web Client und Apps) können auch Fremdsysteme mit der CRM-Anwendung kommunizieren. In der Regel erfolgt dies über SOAP- oder - wie bei den Apps - über REST-basierte Webservices. Diese können direkt aus fachlich modellierten BPM-Prozessen synchron oder asynchron angesprochen werden, was auch der empfohlene EAI-Ansatz zur Kopplung der CURSOR-Systeme mit anderen Applikationen darstellt.
Datenbank-Server und Applikations-Server
Die Performance der Datenbank ist nach unseren Messungen hauptsächlich durch den Cache und die Plattengeschwindigkeit bestimmt. Die Performance des Applikationsservers wird maßgeblich durch die Anzahl der Prozessoren und die Hauptspeicherausstattung beeinflusst. Bei gut ausgestatteten Maschinen kann der Datenbankserver auch als Applikationsserver fungieren. In diesem Fall ist darauf zu achten, dass bei der Prozessorausstattung die leistungsfähigere Variante (s. u.) zum Tragen kommt. Bei der Hauptspeicherausstattung gibt die Summe der Einzelangaben die gesamte Speicherausstattung wieder (Beispiele weiter unten), wobei zum Betrieb eines JBoss-Applikationsservers mind. 5 GB RAM empfohlen werden. Für die Betriebssicherheit ist es im allgemeinen besser, separate Maschinen zu verwenden, um z.B. ein Reboot eines einzelnen Systems zu ermöglichen.
Topologie 1 bis 10 Anwender
Unter der Annahme von durchschnittlich ca. 5 aktiven Benutzern ist folgende Konfiguration zu verwenden:
Gemeinsamer Applikations- und Datenbank-Server
4 CPU-Cores mit mind. 2,7 GHz
8-16 GB RAM
Solid State Disks (SSD)
Netzwerkverbindung zu sämtlichen Rich Client - Arbeitsstationen: 1 GBit/s
Netzverbindung zu Web Client - Arbeitsstationen: Mind. 1 MBit/s für 10 User
>= 30 GB initialer Festplattenplatz für alle Komponenten (DB-Server, Appl.-Server, CURSOR-CRM),
zusätzlich 50-60 GB erforderlicher Festplattenplatz für LOGs (bei mehrjährigem Betrieb ohne Archivierung)Windows Server 2019 (weitere unterstützte Betriebssysteme im Kapitel "Applikationsserver-Software")
Datenbanksystem Oracle oder MS SQL Server (weitere Informationen im Kapitel "Datenbanksystem-Software")
JBoss EAP 7.4 (aktuell: 7.4.14)
Topologie 11 bis 75 Anwender
Unter der Annahme von durchschnittlich ca. 30 aktiven Benutzern ist folgende Konfiguration zu verwenden:
Gemeinsamer Applikations- und Datenbank-Server
6 CPU-Cores mit mind. 2,7 GHz
16-24 GB RAM
Solid State Disks (SSD)
Netzwerkverbindung zu sämtlichen Rich Client - Arbeitsstationen: >= 1 GBit/s
Netzverbindung zu Web Client - Arbeitsstationen: Mind. 1 MBit/s für 10 User
>= 35 GB initialer Festplattenplatz für alle Komponenten (DB-Server, Appl.-Server, CURSOR-CRM),
zusätzlich 50-100 GB erforderlicher Festplattenplatz für LOGs (bei mehrjährigem Betrieb ohne Archivierung)Windows Server 2019 (weitere unterstützte Betriebssysteme im Kapitel "Applikationsserver-Software")
Datenbanksystem Oracle oder MS SQL Server (weitere Informationen im Kapitel "Datenbanksystem-Software")
JBoss EAP 7.4 (aktuell: 7.4.14)
Bei getrennten Applikations- und Datenbankserver-Maschinen sollten 4 CPU-Cores für den Applikations- sowie 2 CPU-Cores für den DB-Server vorgesehen werden. Hinsichtlich anderer Komponenten (z. B. RAM) wären die Daten der nächsten Topologiestufe ("Topologie 76 bis 150 Anwender") eine gute Orientierung.
Topologie 76 bis 150 Anwender
Unter der Annahme von durchschnittlich ca. 50 aktiven Benutzern ist folgende Konfiguration zu verwenden:
Applikations-Server
4 CPU-Cores mit mind. 2,7 GHz
16 GB RAM
Festplatten-Empfehlung: Solid State Disks (SSD); ansonsten Hardware-RAID und Festplatten mit mind. 10.000 U/min.
Netzwerkverbindung zum Datenbank Server: >= 1 GBit/s (LAN)
Netzwerkverbindung zu sämtlichen Rich Client - Arbeitsstationen: >= 1 GBit/s
Netzverbindung zu Web Client - Arbeitsstationen: Mind. 10 MBit/s für 100 User
>= 5 GB erforderlicher Plattenplatz für JBoss inkl. JDK, Applikationsdateien und Arbeitsverzeichnis,
zusätzlich 50-100 GB erforderlicher Festplattenplatz für LOGs (bei mehrjährigem Betrieb ohne Archivierung)Windows Server 2019 (weitere unterstützte Betriebssysteme im Kapitel "Applikationsserver-Software")
JBoss EAP 7.4 (aktuell: 7.4.14)
Datenbank-Server:
4 CPU-Cores mit mind. 2,4 GHz
>= 12 GB RAM
Solid State Disks (SSD)
Netzwerkverbindung zum Applikations-Server: >= 1 GBit/s (LAN)
Voraussichtliche Datenbankgröße (für Daten, Indizes, Transaktions-Logs und Temp-DB): >= 40 GB
Windows Server 2019 (weitere unterstützte Betriebssysteme im Kapitel "Datenbanksystem-Software")
Datenbanksystem Oracle oder MS SQL Server (weitere Informationen im Kapitel "Datenbanksystem-Software")
Topologie 151 bis 300 Anwender
Unter der Annahme von durchschnittlich ca. 100 aktiven Benutzern ist folgende Konfiguration zu verwenden:
Applikations-Server
>= 6 CPU-Cores mit mind. 2,7 GHz
>= 24 GB RAM
Festplatten-Empfehlung: Solid State Disks (SSD); ansonsten Hardware-RAID und Festplatten mit mind. 10.000 U/min.
Netzwerkverbindung zum Datenbank Server: >= 1 GBit/s (LAN)
Netzwerkverbindung zu sämtlichen Rich Client - Arbeitsstationen: >= 1 GBit/s
Netzverbindung zu Web Client - Arbeitsstationen: Mind. 10 MBit/s für 100 User
>= 5 GB erforderlicher Plattenplatz für JBoss inkl. JDK, Applikationsdateien und Arbeitsverzeichnis,
zusätzlich 50-100 GB erforderlicher Festplattenplatz für LOGs (bei mehrjährigem Betrieb ohne Archivierung)Windows Server 2019 (weitere unterstützte Betriebssysteme im Kapitel "Applikationsserver-Software")
JBoss EAP 7.4 (aktuell: 7.4.14)
Datenbank-Server
4 CPU-Cores mit mind. 2,6 GHz
>= 16 GB RAM
Solid State Disks (SSD)
Netzwerkverbindung zum Applikations-Server: >= 1 GBit/s (LAN)
Voraussichtliche Datenbankgröße (für Daten, Indizes, Transaktions-Logs und Temp-DB): >= 65 GB
Windows Server 2019 (weitere unterstützte Betriebssysteme im Kapitel "Datenbanksystem-Software")
Datenbanksystem Oracle oder MS SQL Server (weitere Informationen im Kapitel "Datenbanksystem-Software")
Topologie 300 bis 500 Anwender
Unter der Annahme von durchschnittlich ca. 160 aktiven Benutzern ist folgende Konfiguration zu verwenden:
Applikation-Server
>= 8 CPU-Cores mit mind. 2,7 GHz
>= 32 GB RAM
Festplatten-Empfehlung: Solid State Disks (SSD); ansonsten Hardware-RAID und Festplatten mit mind. 10.000 U/min.
Netzwerkverbindung zum Datenbank Server: >= 1 GBit/s (LAN)
Netzwerkverbindung zu sämtlichen Rich Client - Arbeitsstationen: >= 1 GBit/s
Netzverbindung zu Web Client - Arbeitsstationen: Mind. 10 MBit/s für 100 User
>= 5 GB erforderlicher Plattenplatz für JBoss inkl. JDK, Applikationsdateien und Arbeitsverzeichnis,
zusätzlich ca. 100 GB erforderlicher Festplattenplatz für LOGs (bei mehrjährigem Betrieb ohne Archivierung)Windows Server 2019 (weitere unterstützte Betriebssysteme im Kapitel "Applikationsserver-Software")
JBoss EAP 7.4 (aktuell: 7.4.14)
Datenbank-Server
6 CPU-Cores mit mind. 2,7 GHz
>= 24 GB RAM
Solid State Disks (SSD)
Netzwerkverbindung zum Applikations-Server: >= 1 GBit/s (LAN)
Voraussichtliche Datenbankgröße (für Daten, Indizes, Transaktions-Logs und Temp-DB): >= 100 GB
Windows Server 2019 (weitere unterstützte Betriebssysteme im Kapitel "Datenbanksystem-Software")
Datenbanksystem Oracle oder MS SQL Server (weitere Informationen im Kapitel "Datenbanksystem-Software")
Topologie 500 bis 800 Anwender
Unter der Annahme von durchschnittlich ca. 250 aktiven Benutzern ist folgende Konfiguration zu verwenden:
Applikation-Server
12 CPU-Cores mit mind. 2,7 GHz
>= 40 GB RAM
Festplatten-Empfehlung: Solid State Disks (SSD); ansonsten Hardware-RAID und Festplatten mit mind. 10.000 U/min.
Netzwerkverbindung zum Datenbank Server: >= 10 GBit/s (LAN)
Netzwerkverbindung zu sämtlichen Rich Client - Arbeitsstationen: >= 1 GBit/s
Netzverbindung zu Web Client - Arbeitsstationen: Mind. 10 MBit/s für 100 User
>= 5 GB erforderlicher Plattenplatz für JBoss inkl. JDK, Applikationsdateien und Arbeitsverzeichnis,
zusätzlich ca. 150 GB erforderlicher Festplattenplatz für LOGs (bei mehrjährigem Betrieb ohne Archivierung)Windows Server 2019 (weitere unterstützte Betriebssysteme im Kapitel "Applikationsserver-Software")
JBoss EAP 7.4 (aktuell: 7.4.14)
Datenbank-Server
8 CPU-Cores mit mind. 2,7 GHz
>= 32 GB RAM
Solid State Disks (SSD)
Netzwerkverbindung zum Applikations-Server: >= 10 GBit/s (LAN)
Voraussichtliche Datenbankgröße (für Daten, Indizes, Transaktions-Logs und Temp-DB): >= 150 GB
Windows Server 2019 (weitere unterstützte Betriebssysteme im Kapitel "Datenbanksystem-Software")
Datenbanksystem Oracle oder MS SQL Server (weitere Informationen im Kapitel "Datenbanksystem-Software")
Wichtige Hinweise
Für Installationen mit mehr als 800 Anwendern ist die Hard- und Softwareausstattung individuell auszuarbeiten.
Im Falle eines getrennten Hardware-Caches für Lese- und Schreiboperationen ist der Lese-Cache zu aktivieren (Performance) sowie der Schreib-Cache auszuschalten (Datenkonsistenz). Bei nicht getrenntem Cache muss dieser immer aktiviert sein.
Die oben angegebenen Softwarekomponenten für Datenbanksystem und Applikationsserver haben sich als gängige Kombination bei unseren Kunden etabliert, weshalb Installations- und Wartungsaufwendungen für genau diese Kombination kalkulierbar sind und sich dementsprechend in Grenzen halten. Alternativ können andere Datenbanksysteme und Applikationsserver ggf. auch auf Basis oben nicht aufgelisteter Plattformen eingesetzt werden (siehe Kapitel "Datenbanksystem Software" und "Applikationsserver Software"). Hier ist jedoch insgesamt mit höheren Installations- und Wartungsaufwenden zu rechnen, was insbesondere für die Bereitstellung von Schnittstellenprogrammen zu anderen Applikationen zutrifft.
Obige Hardware-Voraussetzung gilt ausschließlich für den Betrieb von Anwendungen unserer Java-basierten Produktlinie. Falls weitere Produkte auf einem der Server installiert sind, muss die Hardwareausstattung entsprechend angepasst werden. Dies gilt insbesondere für eine Installation in virtualisierten Umgebungen, wo die oben angegebenen Ressourcen der entspr. VM dediziert zuzuweisen sind. Hierbei ist besonders die CPU-Komponente hervorzuheben, da in einer virtualisieren Umgebung der Hardware-Emulationsprozess die CPU-Performance um bis zu 25% reduzieren kann. In einer virtualisierten Umgebung ist es außerdem von Vorteil, wenn die VMs für Datenbank-System und Applikations-Server auf demselben Host laufen.
Im Falle der Installation in einer Cloud-Umgebung wie AWS ist eine Erhöhung vom „Idle-Timeout auf dem Loadbalancer“ auf mind. 900 sec. erforderlich (im Standard liegt dieser Wert bei 60 sec.).
Die Latenz einer Netzwerkleitung zwischen Datenbank-Server und JBoss-Applikationsserver sollte maximal 1 ms betragen, weshalb beide Server im selben Netzwerksegment liegen müssen.
Es kann vorkommen, dass die CPU des Servers nicht richtig hochtaktet, was sich negativ auf die Systemperformance auswirken würde. Abhilfe kann hier über die Windows-Energieoption "Höchstleistung" geschaffen werden. Das Ganze gilt aber nicht für virtualisierte Umgebungen, da dort die Taktrate bei 100% liegt. Weitere Details zu diesem Sachverhalt sind unter https://support.microsoft.com/en-us/kb/2207548 zu finden.
Nachfolgend soll am Beispiel der "Topologie 11 bis 75 Anwender" der Hauptspeicherbedarf von 16-24 GB auf dem Server beleuchtet werden:
Auf dem Applikationsserver werden für Rich Clients ca. 100 MB pro Anwender sowie für den Webclient ca. 130 MB pro User benötigt. Weil der JBoss intern zusätzlich 500 MB Heap belegt, ist bei 30 parallelen Rich Client - Usern ein Heap-Speicherbedarf von ca. 3,5 GB erforderlich.
Außerdem werden für Code-Cache, Metaspace und JVM intern nochmals ca. 700 MB benötigt, sodass in Summe hier 4,2 GB resultieren.
Für den Betrieb eines JBoss-Applikationsservers werden als Mindestwert generell 5 GB empfohlen.
Für den Datenbankserverprozess ist in dieser Topologie Hauptspeicher in Höhe von 4-5 GB zu reservieren.
Im Falle einer serverbasierten CTI-Integration benötigt der CTI-Applikationsserver mind. 2 GB Speicher (siehe Kapitel "CTI-Schnittstelle").
Im Zuge einer Mehrsystemlandschaft wird empfohlen, nicht nur das Produktiv-, sondern auch Entwicklungs- und Test-/Abnahmesystem gut auszustatten (z. B. „Topologie 11 bis 75 Anwender“), da auf Testsystemen bspw. Anwenderschulungen stattfinden oder die Abnahme neuer Software-Stände in Bezug auf Qualität und Performance erfolgt.
Massendatenserver
Für größere Massendaten- oder Reporting-Aktionen (z. B. CSV-Export, Serienbriefe, Serienmails, Excel- und Massendatenauswertungen, Massendatenprozesse) ist bei Zutreffen einer der folgenden Voraussetzungen ein weiterer JBoss-Applikationsserver als Massendatenserver für die Produktiv-Umgebung aufzusetzen:
Verwendung der Topologie-Stufe “151 bis 300 Anwender” (oder höher),
Bei größeren Datenmengen (ab ca. 500.000 Geschäftspartner) oder
Komplexeren Hintergrundprozessen, z. B. Schnittstellenanbindungen wie Portalintegration mit schreibendem Zugriff in die CRM-Datenbank
Ein solcher Massendatenserver ist je nach Datenvolumina mit einem Heap-Speicher von 6 bis 10 GB zu konfigurieren sowie aus Gründen der Systemlast zwingend auf einer separaten Maschine (oder VM) mit folgender Ausstattung zu installieren:
>= 4 CPU-Cores mit mind. 2,7 GHz
8-16 GB RAM
SAS Hardware-RAID 5/10
Netzwerkverbindung zum Hauptapplikations-Server: >= 1 GBit/s (LAN)
Windows Server 2016, 2019 oder 2022 (jeweils Standard Edition)
JBoss EAP 7.4 (aktuell: 7.4.14)
Wird ein Massendatenserver neben dem Produktiv-System auch für das Test-System gewünscht, können beide Massendaten-Applikationsserver auch auf einer Maschine installiert werden. Verglichen mit obiger Ausstattung wäre dann aber der RAM auf 24-32 GB zu erhöhen, damit beide Applikationsserver parallel agieren können.
Prinzipiell kann ein Massendatenserver aber auch zusätzlich auf der Maschine des Test-Applikationsservers eingerichtet werden, sofern dort nur der eine JBoss-Applikationsserver des Testsystems vorliegt und die darunter liegende Maschine über bis zu 10 GB freiem RAM verfügt.
Fileserver
Auf dem Fileserver werden Applikationsdokumente, deren Sicherungen sowie Miniaturansichten für die Dokumentenvorschau abgelegt. Für einen mehrjährigen Betrieb ohne Archivierung sind üblicherweise >= 200 GB freier Festplattenspeicher vorzusehen.
Zwar gilt hier ein ähnliches Lastverhalten wie für Applikations- und Datenbankserver, jedoch ist die Menge der Zugriffe nicht so sehr entscheidend wie die Größe der übertragenen Dokumente. Bei höheren Nutzerzahlen ist demnach insbesondere die Netzstruktur durch die Datenmenge belastet; einen besonders leistungsfähigen File-Server könnte man evtl. ab 500-600 Anwender benötigen.
Für oben beschriebene Topologien könnte der Applikationsserver auch als File-Server fungieren. In diesem Fall wäre o. g. freier Festplattenspeicher (>= 200 GB) entspr. auf dem Applikationsserver bereitzustellen.
Wird ein eigenständiger Server eingesetzt, sollte dieser über folgende Ausstattung verfügen:
4 CPU-Cores mit mind. 2 GHz
>= 4 GB RAM
SAS Hardware-RAID 5/10
Zur Ablage des Volltextsuch-Index empfiehlt sich eine Solid State Disk (SSD).
Volumen nach Datenmenge: >= 200 GB (für Applikationsdokumente, Dokument-Sicherungen, Thumbnails für Dokumentenvorschau sowie Volltext-Suchindex, bei mehrjährigem Betrieb ohne Archivierung)
Netzwerkverbindung zum Applikations-Server: >= 1 GBit/s (LAN)
Windows Server 2016, 2019 oder 2022 (jeweils Standard Edition)
Clients
Web Client
Der Internet-Browser erfordert je nach Version und System-Customizing zwischen 300 und 600 MB Hauptspeicher.
Netz-Anbindung (pro Client) zum Applikations-Server: Download >= 1,5 MBit/s, Upload >= 750 KBit/s
>= 500 MB Festplattenplatz für heruntergeladene Dokumente
Java Runtime ist nicht erforderlich
Bildschirmauflösung auf Desktop-PCs / Notebooks bei mind. 1280 x 1024, auf Tablets bei 1024 x 768
Folgende Browser-Versionen werden derzeit auf Desktop-PCs / Notebooks unterstützt:
Google Chrome: Der Einsatz einer aktuellen Version wird empfohlen (>= 127).
Mozilla Firefox ab Version 129, ESR-Variante ab Version 115.x.
MS Edge auf Chromium-Basis (>= 127).
Des Weiteren werden mit Einschränkungen folgende Browser unterstützt:
Mac-Rechner: Nutzung auf Basis aktueller Safari-Version, wobei das Unterdrücken der Pop-Ups im Safari zu deaktivieren ist. Dennoch unterliegt der Betrieb generellen Einschränkungen (z. B. kein Auto-Login, keine erweiterte Dokumentenbehandlung, keine externen Aufrufe, kein Drag and Drop von Outlook-Mails, keine verlinkten Dokumente, keine Tastatur-Shortcuts)
iPad: Nutzung auf Basis aktueller Safari-Version, wobei das Unterdrücken der Pop-Ups im Safari zu deaktivieren ist. Dennoch unterliegt der Betrieb auch hier denselben Einschränkungen wie bei Mac-Rechnern sowie zusätzlichen Restriktionen (z. B. kein Dokumenten-Upload, kein Drag and Drop von Dokumenten, keine Doppelklick-Funktion, kein individuelles Positionieren von Maskentrennern)
Android-Tablets: Tablets in Verbindung mit Chrome oder Firefox-Browser (Versionen: siehe oben), wobei im Falle Chrome der Dokumenten-Download nur mit einem offiziell signierten Zertifikat funktioniert. Außerdem gelten auch hier dieselben Restriktionen wie bei iPads.
Die Angaben über Kompatibilität mit den aufgelisteten Browser-Versionen beziehen sich auf die Standardkonfiguration der jeweiligen Browser. Explizite Abweichungen davon (zum Beispiel für Single Sign-on) werden im Handbuch dokumentiert. Wird die Browserkonfiguration darüber hinaus beispielsweise über Gruppenrichtlinien oder Schaltern in about:config angepasst, kann der reibungslose Betrieb mit CURSOR-CRM nicht mehr garantiert werden. Aus diesem Grund können wir für solche Konfigurationen nur eingeschränkten Support leisten.
Für alle eingesetzten Browser-Varianten ist "Skripting" / "JavaScript" zu aktivieren. Es ist sicherzustellen, dass dort das WebSocket-Protokoll aktiviert ist. Außerdem ist die Einrichtung eines Zertifikats für den HTTPS- und WSS-Betrieb erforderlich.
Bei der Verwendung von Browser-Erweiterungen, z. B. SpellChecker, kann es zu einem unerwarteten Verhalten im Web Client (insbesondere im HTML-Editor) kommen, auf welchen unsere Software keinen Einfluss hat. Daher wird von der Verwendung solcher Erweiterungen dringend abgeraten.
Zur komfortablen Nutzung des Webclients, insbesondere der erweiterten Dokumentenbehandlung sowie externer Aufrufe, ist auf der Windows-Plattform die Einrichtung der CURSOR Browser-Erweiterung sowie die Installation des CURSOR Communication Hosts erforderlich. Weitere Informationen sind dem Installations-Handbuch zu entnehmen.
Voraussetzungen zur Nutzung des User-Onboarding
Um im Web Client das Onboarding-Feature im Standard nutzen zu können, müssen folgende Bedingungen erfüllt sein:
Jeder Client benötigt einen Internetzugang, um mit den Onboarding-Diensten kommunizieren zu können.
Wenn eine Firewall aktiv ist, muss diese so eingestellt sein, dass sie die Kommunikation zu den benötigten Servern erlaubt. Dies betrifft:
https://onboarding-proxy.cursor-services.de/userlane.js für die Kommunikation über die CURSOR-Cloud sowie
*.userlane.com für die eigentliche Nutzung des Onboarding-Services (eine vollständige Auflistung kann auf Anfrage bereitgestellt werden)
Ist eine Content Security Policy vorhanden, muss sie *.userlane.com für alle Arten von Anfragen erlauben.
Um eine sichere und verschlüsselte Kommunikation zu gewährleisten, läuft die Anwendung mit einem verschlüsselten Protokoll (HTTPS).
Rich Client
>= Dual-Core mit mind. 2,5 GHz
>= 4 GB RAM (CRM-Applikation benötigt ca. 500 MB für normale Anwender sowie bis zu 800 MB für Administratoren und Power-User mit Verarbeitung großer Datenmengen)
Netzwerkverbindung (pro Client) zum Applikations-Server: >= 100 MBit/s
Die Latenz einer Netzwerkleitung zwischen Rich Client und JBoss-Applikationsserver darf maximal 8 ms betragen, ansonsten ist der Web Client zu nutzen.
>= 1,5 GB Festplattenplatz für die Client-Software inkl. Caches und Java-Laufzeitumgebung.
Die Client-Software ist lokal abzulegen. Der Start des Clients über ein Netzlaufwerk führt teilweise zu deutlichen Geschwindigkeitseinbußen.Java Runtime 17.0.11, kostenfrei
Windows 10 oder Windows 11
Bildschirmauflösung mind. 1280 x 1024
Aufgrund der fehlenden Unterstützung von Vektorgrafiken unterstützt der Rich Client keine Skalierung von Text, Apps und anderen Elementen. Deshalb ist eine sinnvolle Nutzung des Rich Clients auf MS Surface Tablet, ähnlichen Geräten sowie 4K-Monitoren nicht bzw. nur eingeschränkt möglich.
Aus Performancegründen sollte darauf geachtet werden, dass die Rechner nicht im Energiesparmodus laufen, d. h. hier muss der empfohlene Standard "Ausbalanciert" eingestellt sein.
Hinweise zum Speicherbedarf des Rich Clients
Verarbeitung größerer Datenmengen
Die Selektion von 40.000 Datensätzen im Falle einer Aktivitätenliste mit 15 Spalten führt dazu, dass der Speicherbedarf auf dem Client kurzzeitig um 50 MB ansteigt, um sich dann wieder deutlich zu reduzieren, so dass der tatsächliche Anstieg bei ca. 10-15 MB liegt. Um für eine solche Selektion die bestmögliche Performance zu gewährleisten, sollten die zwischenzeitlich benötigten 50 MB verfügbar sein.
Weitergehende Tests mit mehreren Ebenen und jeweils 40.000 Sätzen haben zu einem Java-Heap-Speicherbedarf von ca. 350 – 380 MB geführt, so dass zzgl. einer "MaxPermSize" (Speicher für permanente Objektgenerierung) von 128 MB ein Gesamtspeicherbedarf von 500 MB resultiert.
Nutzen der Browser View - Komponente
Die Möglichkeit der Integration einer Web-Applikation in Rich Client - Masken (oder auf dem Desktop) erfordert im Grundzustand 10-20 MB zusätzlichen Speicherbedarf auf dem Java-Client. Abhängig vom Anwenderverhalten sowie der Anzahl eingesetzter Browser Views werden die generierten Chromium-Instanzen mehrere Hundert MB Hauptspeicher auf dem Client-Rechner belegen, was in etwa dem Speicherbedarf zum Laden dieser Views im Internet Browser entspricht. Dies ist insbesondere bei der Hauptspeicherzuteilung in Terminalserver-/Citrix-Umgebungen zu beachten.
CURSOR App
iOS >=16
Android ab Version 9: Um die INFOBOARDS auf der CURSOR-App darzustellen, muss die Android System WebView installiert sein.
Auch hier gilt für die mobile Netzanbindung: Download >= 768 KBit/s, Upload >= 128 KBit/s.
Im Rahmen der System-Anmeldung wird geprüft, ob ein valides Zertifikat im JBoss-Applikationsserver hinterlegt ist, welches von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde. Das im Auslieferungszustand vorinstallierte (selbst signierte) Zertifikat ist hier nicht ausreichend und muss entspr. durch ein kundenspezifisches, valides Zertifikat ersetzt werden.
Hinweis: Dies trifft für alle eingesetzten Systeme zu (Entwicklungssystem, QS-/Abnahme-System und Produktiv-System).
Weitere Hinweise von Apple zu u. a. der Gültigkeitsdauer von Zertifikaten sind dem folgenden Link zu entnehmen: → https://support.apple.com/de-de/HT211025
Terminalserver
Betriebssystem des Terminalservers
Windows Server 2016, 2019 oder 2022, jeweils Standard Edition mit Terminaldiensten.
Weitere Daten zur Ausstattungsempfehlung
8 CPU-Cores mit mind. 2,5 GHz
>= 16 GB RAM
>= 150 MB Festplattenplatz pro Benutzerprofil für Caches sowie bearbeitete CRM-Dokumente
Hardware-RAID 1
Netzwerkverbindung zum Applikations-Server: >= 1 GBit/s (LAN)
Anmerkung zum Hauptspeicher
Der Terminalserver muss i. d. R. sehr gut ausgestattet sein. Zusätzlich zum Speicherbedarf des Betriebssystems sind pro Sitzung jeweils ca. 428 MB für die Applikation erforderlich (300 MB HeapSpace sowie 128 MB für PermSpace und JVM). Sollen weitere Applikationen ausgeführt werden (z.B. Outlook, Word, Excel), vergrößert sich der Speicherbedarf dementsprechend. Für den Fall, dass CRM-Masken mit Browser Views hinzukommen (siehe oben), ist weiterer Hauptspeicher erforderlich.
Unter Berücksichtigung aller genannten Faktoren resultiert in Summe pro Anwender ca. 800 MB Hauptspeicher, so dass mit 4 GB verfügbarem Speicher 5 Benutzer ohne Einschränkung gleichzeitig bedient werden können.
Zu beachten
Grundsätzlich sind die Anwendungen – mit entsprechenden Geschwindigkeitseinbußen – auch auf Systemen mit geringerer Leistung lauffähig.
Bei der Nutzung des Rich Clients ist das Client-Verzeichnis lokal auf der Terminalserver-Maschine abzulegen. Ein Start des Clients über ein Netzlaufwerk führt teilweise zu deutlichen Geschwindigkeitseinbußen.
Fernwartung
Für die Gewährleistung eines zeitnahen und reibungsarmen Supports sowie für Systemwartungsarbeiten setzen wir auf Fernwartungsmöglichkeiten. Hierfür hat sich unsererseits der Zugriff via Remotedesktop als Zugangsmöglichkeit etabliert. Beim Remotedesktop-Zugang wird auf einer VPN Verbindung aufgesetzt.
Auf dem für die Fernwartung bereitgestellten Desktop muss ein Zugang für alle zu wartenden Applikationen bereitstehen. Darüber hinaus müssen die dafür verwendeten Datenbanken und Applikationsserver zugänglich sein. Dies umfasst die Möglichkeit des Startens und Stoppens vom Applikationsserver, des Zugangs zur Datenbank über einen SQL-Editor sowie der Erstellung bzw. des Einspielens von Datenbanksicherungen. Auf Verzeichnisebene benötigen wir Schreibrechte in den programmrelevanten Bereichen, insbesondere auf dem Applikationsserver und den Log-Verzeichnissen.
Eine praktikable Möglichkeit der Dateiübertragung ist für die Fernwartung ebenfalls bereitzustellen. Sofern kein direkter Datentransfer möglich ist, kann dies auch durch Bereitstellung eines Email-Accounts erfolgen.
Ist eine arbeitsstationslokale Prüfung bspw. im Zusammenhang mit der Client-Konfiguration oder MS Office erforderlich, sollte der Einsatz vom Teamviewer (http://www.teamviewer.com ) oder Microsoft Teams in Erwägung gezogen werden. Teamviewer stellt direkt eine Verbindung zu dem Desktop eines entfernten Rechners über das Internet her und benötigt dazu keine weitere Einrichtung.
Datenbanksystem-Software
Die Hersteller der Datenbanken sowie die Newsgroups erteilen keine Auskunft über die Hardware-Voraussetzungen bei verschiedenen Datenbankgrößen und Benutzeranzahlen.
Für die Datenhaltung können wahlweise die Datenbanksysteme Oracle oder MS SQL-Server verwendet werden, wobei die Datenbank-Lizenzen nicht Bestandteil des Standard-Lieferumfangs von CURSOR-CRM sind.
Bei der Installation von CURSOR-CRM wird eine bereits installierte Datenbanksoftware vorausgesetzt. Die Datenbankstruktur (Tabellen, Indizes usw.) wird in Form eines Datenbank-Dumps eingespielt. Die Konfiguration der DB-Parameter erfolgt im Vorfeld in Absprache mit dem Kunden und bei der Installation vor Ort.
Folgende Releases sind bei den verschiedenen DB-Systemen zu verwenden:
Oracle: Version 19c, mit aktuellem Patch
MS SQL-Server: Version 2022 oder 2019, mit aktuellem Service Pack
Während Oracle sowohl auf der Windows-Plattform als auch Linux- (z. B. SuSE Linux, Red Hat Linux) und Unix-Derivaten (z. B. IBM AIX, Sun Solaris) genutzt werden kann, ist der MS SQL-Server im allgemeinen nur für die Windows- und Linux-Plattform verfügbar.
Abschließende Hinweise
Für die Nutzung der Anwendung ist die Standard Edition der Datenbank-Software ausreichend. Bei hohen Anwenderzahlen, sehr großen Datenmengen oder allgemeinem Interesse an Enterprise-Features kann über den Einsatz der Enterprise Edition nachgedacht werden. Hierbei spielen zwei Faktoren eine wichtige Rolle: Zum einen erfolgt ein automatisches Tuning der SQL-Ausführungspläne und zum anderen wird die vorhandene Hardware durch Parallelisierung für alle gängigen Datenbank-Operationen optimal ausgenutzt. Dadurch kommen die obigen Hardware-Empfehlungen komplett zur Geltung.
Bei Nutzung einer Oracle-Datenbank ist der Zeichensatz "WE8MSWIN1252" zu verwenden. Die Unicode-Fähigkeit ist durch die Verwendung von N-Datentypen sichergestellt.
Als Sortierung sollte beim MS SQL-Server die Standardsortierung der MS SQL Installation verwendet werden. Diese ist in Deutschland "Latin1_General_CI_AS" und in Amerika "SQL_Latin1_General_CP1_CI_AS". Aus Gründen der Performance sollte sichergestellt werden, dass die Sortierung der Datenbankinstallation (master und temp Tabellen) mit der Sortierung der CRM Tabellen identisch ist.
Zur Vermeidung von Exklusivsperren und Deadlocks ist im Falle des SQL-Servers das SNAPSHOT Transaktionslevel einzustellen. Im Rahmen der Konfiguration der Serverauthentifizierung ist der "SQL Server- und Windows-Authentifizierungsmodus" zu aktivieren.
Die Implementierung von Schnittstellen zu anderen Anwendungen ist nur dann möglich, wenn auf Datenbankseite eine prozedurale Ergänzung zur SQL-Sprache existiert, die im Funktionsumfang an PL/SQL für Oracle oder Transact SQL für MS SQL-Server heranreicht.
Es wird dringend empfohlen, auf die Nutzung von Datenbank-Sammlern zu verzichten. Ein Datenbank-Sammler ist ein Server, auf dem die Datenbanken unterschiedlichster Software-Produkte zentral abgelegt werden. Die Nutzung eines DB-Sammlers ist zwar prinzipiell möglich, kann jedoch zu globalen Auswirkungen auf alle involvierten Applikationen führen, sofern auf einer (oder mehreren) der Datenbanken länger laufende, performancelastige Aktionen stattfinden (z.B. Batch-Schnittstellen, Wartungs-Jobs für Re-Indizierung, Komprimierung oder DB-Statistiken).
Applikationsserver-Software
Unsere Applikationen sind so entwickelt, dass prinzipiell jeder Applikations-Server in Frage kommt, der der Java EE Spezifikation entspricht. Derzeit kann die volle Funktionsfähigkeit jedoch nur mit folgendem Produkt zugesichert werden:
JBoss EAP 7.4 (aktuell: 7.4.14)
JBoss EAP 7.4 wird mit aktivierter SSL Verschlüsselung ausgeliefert. In der Auslieferungsversion wird ein selbst signiertes Zertifikat verwendet, das bspw. vom Internet-Browser als unsicher eingestuft wird.
Achtung
Es ist daher zwingend erforderlich, ein kundenspezifisches, valides Zertifikat einzusetzen.
Hintergrund:
Um den aktuellen IT-Sicherheitsstandards zu entsprechen, verwenden unsere Systeme gesicherte Verbindungsstrecken bei technologieübergreifender Kommunikation. Dies erfordert u.a. die Verwendung von Zertifikaten, um die Authentizität, Integrität und Verschlüsselung in der Kommunikation sicherzustellen. Während es in der Vergangenheit möglich war, mit einem von CURSOR ausgestellten Zertifikat zu arbeiten, ist dies auf Grund aktueller Sicherheitsrichtlinien nicht länger zulässig. Drittsysteme erfordern bei sicherer Kommunikation zwingend die Verwendung einer individuellen Authentifizierung. Daher verlangen unsere Systeme ebenfalls die Verwendung eines eigenen Zertifikats.
Zudem wurde mit neueren Versionen das Login-Verfahren des Rich Clients überarbeitet, mit dem Ergebnis einzelner Sicherheitsverbesserungen sowie dem Ziel, Single Sign-On - Verfahren in Zukunft leichter zu implementieren. Durch die Umstellung des Login-Verfahrens ist es aus sicherheitstechnischen Gründen notwendig, eigene Zertifikate einzusetzen.
Folgende Zertifikatsdateien sind für die Server- und Client-Verschlüsselung notwendig:
Ein SSL-Zertifikat für Serverauthentifizierung, das auf den FQDN des Servers verweist, auf dem der Applikationsserver installiert ist
Bei der Erstellung des Zertifikats ist darauf zu achten, dass im Server-Zertifikat (Public-Key) sämtliche DNS-Aufrufnamen enthalten sind, die für die CURSOR-Clients (Web Client, Rich Client, CURSOR-App) eingesetzt werden.
Die Eigenschaft Subject Alternative Name (vgl. rfc5280) muss korrekt gesetzt bzw. vorhanden sein.
Der zum SSL-Zertifikat zugehörige Private-Key
Die Zertifikate (Public-Keys) der ausstellenden Zertifizierungsstelle sowie deren übergeordneter Zertifizierungsstellen (falls vorhanden) [Root und Intermedia CAs] (d.h. die Zertifikatskette muss vollständig sein)
Unser Applikationsserver unterstützt die TLS-Versionen 1.3 und 1.2. Beim Thema Cipher Suites halten wir uns im Falle TLS 1.3 an die Modern Compatibility sowie im Falle TLS 1.2 an die Intermediate Compatibility Vorgaben. Siehe hierzu auch https://wiki.mozilla.org/Security/Server_Side_TLS .
Als Betriebssystem-Plattform ist Windows Server (2022, 2019 oder 2016) oder eine der Linux-Varianten SuSE Linux (ab Enterprise Server 12.5 - 64 Bit), CentOS (ab 9.x - 64 Bit) oder Red Hat Linux (ab 8.x - 64 Bit) nutzbar. Andere Linux-Derivate bitte nur nach Rücksprache!
Hochverfügbarkeit
Für den Fall, dass der Host-Rechner, auf welchem die Applikationsserver-VM läuft, ausfällt, kann die Virtualisierungsplattform (z. B. VMware) die betreffende VM automatisch auf einen anderen, im Virtualisierungs-Cluster noch verfügbaren Host weiterschieben. Diesen Fall fängt also die Virtualisierungs-Software direkt ab. Sollte jedoch die Host-Maschine in Ordnung sein und der Ausfall ist innerhalb der Applikationsserver-VM selbst (z. B. Fehler im Windows-Filesystem), kann ein Failover-Mechanismus über entspr. Bordmittel der Hypervisor Cluster (z. B. Proactive High Availability bei VMware) oder über Betriebssystemkomponenten vorgesehen werden.
Auf Betriebssystemebene könnte die Applikationsserver-VM bspw. über einen Windows Cluster hochverfügbar gemacht werden. Hierbei wird im Falle eines Ausfalls des primären Applikationsservers die als Failover gedachte, zweite Applikationsserver-VM hochgefahren und dort der JBoss-Applikationsserver gestartet, welcher den CURSOR-CRM Clients per DNS-Eintrag bekannt gemacht wird. Im Rahmen dieses Verfahrens müsste die produktive Applikationsserver-VM regelmäßig in die Failover-VM gespiegelt werden. Log-Dateien können im SAN gespeichert werden, sofern eine nächtliche Sicherung nicht ausreichend sein sollte.
Abschließender Hinweis
Der Name des Servers, auf welchem der JBoss-Applikationsserver installiert wird, muss ein gültiger Internet-Domänenname sein, d. h. im Namen dürfen nur Buchstaben, Ziffern und Bindestriche, jedoch bspw. keine Zeichen wie Unterstriche enthalten sein.
Einsatz CRM-System hinter Reverse-Proxy / WAF
Beginnend mit der CRM-Version 24.3 wird HTTP/2 für einen reibungslosen Betrieb vorausgesetzt und im CRM-Applikationsserver standardmäßig aktiviert. Ohne HTTP/2 treten in bestimmten Situationen deutlich verzögerte Reaktionszeiten im Web Client auf.
Mit CRM-seitig aktiviertem HTTP/2 wird nur noch ein Reverse-Proxy oder eine Web-Application-Firewall (WAF) unterstützt, die TLS-Sessions terminiert (Layer 7) und HTTP/2 unterstützt. Damit ist weiterhin der Einsatz von "Single IP" (für Reverse-Proxy / Web-Application-Firewall) und Wildcard oder Multi-Domain (SAN) Zertifikaten möglich.
Der Hintergrund ist hier beschrieben: https://help.cursor.de/de/hub/current/ssl-kommunikationsstrecken-zertifikate#id-(de)SSL-Kommunikationsstrecken&Zertifikate-EinsatzvonReverse-Proxy/Loadbalancer/WAF(WebApplicationFirewall)
Muss übergangsweise ein bestehender Layer 4 Reverse-Proxy (keine TLS-Terminierung) weiterbetrieben werden, so kann kann HTTP/2 in der standalone.conf(.bat) temporär deaktiviert werden. Diese Möglichkeit wird mit der Version 25.1 entfallen.
Ist HTTP/2 aktiviert, reagiert der WebClient unter Mozilla Firefox gelegentlich verzögert. Dies ist eine bekannte Einschränkung, die mit einer zukünftigen CRM-Version behoben wird. Wird Mozilla Firefox nicht eingesetzt, tritt das Problem nicht auf. Folgende Maßnahmen können das Problem abmildern:
Deaktivieren von HTTP/2 und ausschließliche Verwendung von HTTP/1.1. Die Konfiguration kann ebenfalls zu verzögerten Reaktionszeiten im WebClient führen, wenn über Infoboards sehr viele Suchen parallel ausgeführt werden, da moderne Browser die Anzahl an gleichzeitigen Verbindungen zu einem Server beschränken. Bei Mozilla Firefox liegt dieses Limit bspw. bei 6.
Deaktivieren von HTTP/2 im Applikationsserver und Deployment eines Reverse-Proxys, der für die Client-Verbindung HTTP/2 und die Server-Verbindung (Applikationsserver) HTTP/1.1 nutzt. Der Reverse-Proxy kann unbeschränkt viele Verbindungen zum Applikationsserver aufbauen, wodurch das Limit des Browsers effektiv umgangen wird.
Für weitere Informationen wird auf (für 24.4) JBoss hinter einem Reverse-Proxy verwiesen.
Erforderliche Portfreigaben
Für den Betrieb des CRM-Clients werden im Falle des JBoss-Applikationsservers folgende Ports benötigt:
18443 (Web Port https)
19993 (JBoss Management https) => Dies ist optional und aus Sicherheitsgründen nur bei Bedarf zu aktivieren, bspw. bei Überwachung durch Monitoring-Server bzw. Interesse an Metriken.
Wird statt Portrange 1 bspw. Portrange 2 bevorzugt, lauten die Portnummern entspr. 28443 und 29993.
Auf Datenbankseite sind im Standardfall folgende Ports zu berücksichtigen:
Oracle: 1521
MS SQL-Server: 1433
Für die serverseitige Groupware-Anbindung sind auf dem Groupware-Server folgende Ports freizugeben:
Mail-Empfang: 143 (IMAP) oder 993 (IMAPS mit SSL)
Mail-Versand: 25 (SMTP)
Anbindung Exchange-Kalender: 443 (https)
Report-Engine
Das Erstellen von Auswertungen basiert auf dem OpenSource-Tool JasperReports.
JasperReports ist eine Java-Bibliothek, die in jedes Java-Projekt eingebunden werden kann. Die API ermöglicht die Erstellung, Manipulation und Ausführung der Report-Designs. Die Report-Engine ist auf dem Applikationsserver integriert, wodurch der Zugriff auf die Reportdaten vereinfacht und beschleunigt wird. Die Installation einer Runtime auf Clients ist nicht erforderlich. Auf dem Client sollte jedoch ein Acrobat Reader installiert sein, um vom Server angelieferte Reports auch im PDF-Format anzeigen zu können. Werden andere Formate benötigt, müssen die dazu passenden Anwendungen ebenfalls vorliegen.
Designer von neuen Auswertungen benötigen Zugriff auf das REPORT-Datenbankschema, welches entweder auf dem zentralen Datenbank-Server oder auf einem anderen, für die Report-Designer zugänglichen Rechner (ggf. auf Basis der kostenlosen Express Edition) einzurichten ist.
Auf den Rechnern der Report-Designer ist auch ein CURSOR-CRM Client sowie der genannte Zugriff (über JDBC) auf die REPORT-Datenbank/-Instanz bereitzustellen.
Groupware-Anbindung
Für die Integration eines Groupware-Systems besteht zum einen die Möglichkeit der clientseitigen Outlook-Anbindung, welche über die MAPI-Schnittstelle mit dem Outlook-Client kommuniziert, und zum anderen die Anbindung eines Groupware-Servers (MS Exchange).
Die clientseitige Outlook-Schnittstelle hat sich als Standard im Falle des Rich Client - Einsatzes etabliert. Um den Zugriff des Rich Clients auf Outlook zu gewährleisten, dürfen folgende Gruppenrichtlinien-Einstellungen nicht vom Default-Wert abweichen:
Benutzerkonfiguration -> Richtlinien -> Administrative Vorlagen -> Microsoft Outlook 2016 -> Sicherheit -> Sicherheitsformulareinstellungen -> Programmatische Sicherheit
Eingabeaufforderung für Outlook-Objektmodell beim Zugriff auf ein Adressbuch konfigurieren
Default-Wert: Benutzer basierend auf der Computersicherheit auffordern
Eingabeaufforderung für Outlook-Objektmodell beim Lesen von Adressinformationen konfigurieren
Default-Wert: Benutzer basierend auf der Computersicherheit auffordern
Im Falle des Web Clients sowie des Postfach-Managers wird auf die serverseitige Schnittstellentechnologie zurückgegriffen, d. h. die Daten werden nicht über den Groupware-Client, sondern direkt mit dem Server abgeglichen.
Die Mail-Schnittstelle erfordert im Falle MS Exchange die Exchange Web Service API (EWS API) oder MS Graph API. Alternativ können Mail-Versand und -Import auch über einen Mail-Server erfolgen, welcher die Protokolle SMTP und IMAP unterstützt und wo die entspr. Dienste auf dem Groupware-Server aktiviert sind (Hinweis: IMAPS mit SSL oder TLS möglich).
Der Termin-, Kontakt- und Aufgabenabgleich ist über die API des Groupware-Systems implementiert. So wird im Falle MS Exchange die Exchange Web Service API (EWS API) genutzt. Die EWS-Schnittstelle On-Premise wird ausschließlich mit der Authentifizierungsmethodik „Integrierte Windows-Authentifizierung“ (NTLM oder Kerberos) unterstützt. Bei Verwendung von Office 365 wird die Authentifizierung über die Modern-Authentication (OAuth) durchgeführt. Hierzu ist eine Registrierung der Anwendung in Azure notwendig.
Alternativ kann ein Termin- und Kontaktabgleich mit kleineren Einschränkungen (z. B. Vertraulich-Kennzeichen) auch über die MS Graph API erfolgen.
An dieser Stelle wird darauf hingewiesen, dass der Zugriff auf einen Exchange-Server in der Cloud (“Exchange Online”) ab 01.10.2026 über die EWS-Technologie nicht mehr möglich sein wird (siehe hierzu https://techcommunity.microsoft.com/t5/exchange-team-blog/retirement-of-exchange-web-services-in-exchange-online/ba-p/3924440).
Office-Suite
Für den Bereich der Office-Anbindung ist MS Office 2016 oder 2019 zu verwenden.
Die Integration zu Office 365 ist im Falle der lokalen Installation getestet und freigegeben. Für die Web-/Online-Versionen von MS Word und MS Excel existiert jedoch keine Anbindung.
Telefonie-Integration
Serverbasierte CTI-Integration
Für die Telefonie-Anbindung gibt es die Möglichkeit einer serverbasierten CTI-Integration (Computer Telephony Integration), welche im Web- und Rich Client verfügbar ist. Hierbei wird über einen Kommunikationsbaustein unseres Partners Clarity AG die Telefonanlage direkt angesprochen.
Wir empfehlen die Installation des CTI-Servers auf derselben Maschine wie der Applikationsserver. Sollte dennoch die Installation auf einer separaten Maschine gewünscht werden, sind folgende Voraussetzungen zu beachten:
2 CPU-Cores mit mind. 2,7 GHz
>= 4 GB RAM
>= 100 GB Festplattenplatz
Netzwerkverbindung zum Applikations-Server: >= 1 GBit/s (LAN)
>= Windows Server 2016
Vollständig implementierte RFC-konforme CSTA-, JTAPI- oder MS-TAPI-Schnittstelle zur Telefonanlage. Alternative Anbindungen bedürfen einer technischen Prüfung.
Bei der CTI-Integration wird die Schnellstartleiste im CRM-System genutzt, um bspw. verpasste Anrufe zu protokollieren und dort weiterzuverfolgen.
Clientseitige TAPI-Schnittstelle
Mit der Umstellung des Rich Clients auf 64 bit ist eine clientseitige TAPI-Anbindung nicht mehr möglich, weshalb die Nutzung der serverbasierten CTI-Integration empfohlen wird.
Beispiel für eine CURSOR-CRM Systemlandschaft
