Update auf 2025.2.x

Die Update-Dokumentation beschreibt die Schritte, die aus technischer Sicht zum Update einer Major-Version notwendig sind und gibt Hinweise, worauf aus technischer Sicht geachtet werden muss.

Voraussetzungen

Vorgehensweise

1. Bei dem Update ist unbedingt darauf zu achten, die einzelnen Schritte in der angegebenen Reihenfolge komplett abzuarbeiten und sich dabei exakt an die Anleitung zu halten. Im Fehlerfall ist die im Update Verzeichnis liegende Update und Update_Debug Textdatei zu sichern und mit dem Support Rücksprache zu halten.

2. Wenn Sie die Update-Prozedur erfolgreich abgeschlossen haben, teilen Sie uns bitte mit (support@cursor.de), welche Systeme (z.B. Test- oder Produktiv-System) Sie auf welche Version aktualisiert haben. Nur so können wir im Falle einer Support-Frage Ihr Problem möglichst schnell in unserem Haus prüfen.

Versionen

Ein Update ist immer von der letzten LTS Version und den letzten zwei Releases möglich.

Versionsvoraussetzungen für das CRM:

Aus der Tabelle wird ersichtlich, dass Update auf die Version 2025.2 zwingend die Version 2025.1.LTS voraussetzt.

Sollten Sie eine Version <2025.1 auf 2025.2 updaten, müssen Sie es in 2 Schritten tun:

• <2025.1 auf 2025.1 (Hierzu ist die Dokumentation Update auf 2025.1.x LTS relevant)

• 2025.1 auf 2025.2 (diese Dokumentation)

Tipp

Generell sollte immer der aktuelle Patch für die alte Version eingespielt werden, um Probleme beim Update zu vermeiden.
Wird der Customizing Transport verwendet, empfehlen wir den Transport aller Pakete vor dem Update und auch eine Spiegelung der Datenbank (Prod in Test und QS). Auch sollte das Update über ein Wartungsfenster durchgeführt werden.

Prüfung der Metadaten

Beim Update auf Version werden die Metadaten der Installation geprüft. In kritischen Fällen kann es sein, dass diese Prüfung das Fortführen des Update verhindert und den Update-Vorgang abbricht. In diesen Fällen muss zuerst der Metadatenfehler bereinigt und das Update anschließend erneut durchgeführt werden.

Mit der LTS-Version 2025.1 gibt es bei diesem Ablauf eine wesentliche Änderung für Entwicklungs- und QS-Systeme. Dort wird der Updatevorgang nun trotz Metadatenfehler zu Ende geführt, um im Nachgang diesen untersuchen und beheben zu können. In diesem Fall endet der Update-Vorgang nicht mit einem "Pokal", sondern mit einem Hinweis auf die notwendigen Nacharbeiten.

Gleichzeitig wird im System ein globales Flag gesetzt, damit am System nicht mehr weiterentwickelt werden kann, solange der Metadatenfehler noch nicht behoben wurde. Man kann sich jedoch noch in den Systemen anmelden, Daten lesen und ändern, aber es ist kein Customizing (mit entsprechendem Transport) möglich.

Zusätzlich wird im System eine dauerhaft sichtbare Benachrichtigung visualisiert, um auf diesen Missstand hinzuweisen, welche erst nach erfolgter Berichtigung nicht wieder angezeigt wird.

Sobald der Metadatenfehler bereinigt worden ist, würde die stündlich im Hintergrund im Zuge der System-Metriken laufende Metadatenüberprüfung dies erkennen und den globalen System-Zustand wieder korrigieren.

In Produktiv-Systemen wird das Update weiterhin abgebrochen, wenn die Metadatenprüfung Fehler feststellt, damit nicht auf Basis von fehlerhaften Metadaten falsche Daten aufgebaut werden oder ggf. sogar Daten verloren gehen.

Systemvoraussetzungen für Update

System-Voraussetzungen

Die Systemvoraussetzungen können unter Systemvoraussetzungen  eingesehen werden. Erforderliche Portfreigaben zwischen Rich Client und Applikationsserver finden Sie ebenfalls in dem Dokument.

Update-Vorbereitungen

Download der Version

Um die für Update-Zwecke benötigte Programm-Version zu erhalten, melden Sie sich bitte im Kundenbereich von www.cursor.de an. Dort können Sie im Downloadbereich das entsprechende Paket beziehen. Bei Rückfragen wenden Sie sich bitte an den Support der CURSOR Software AG (support@cursor.de). Nachdem Sie die gezippte Datei heruntergeladen haben, entpacken Sie diese auf dem Applikationsserver.

Verzeichnisstruktur des Update- bzw. Installationspakets

Nachdem Sie die gezippte Datei für beispielsweise CURSOR-CRM 2025.2 (25.2.x) entpackt haben, ergibt sich (unter anderem) folgende ähnliche Verzeichnisstruktur:

Hauptverzeichnis: CURSOR-CRM_25.2.X (Im Folgenden <INSTALL-DIR> genannt).

Unterverzeichnis:

• client (CURSOR-CRM-Client)

• clientlog (Verzeichnis/Freigabe für Clientlogs)

• cti (Dateien für einen CTI Server)

• db (Datenbankskripte)

• installer (Die Dateien des Update- bzw. Installationstools)

• jdk (Open JDK für Windows und Linux)

• server (Applikationsserver JBoss)

• tools (Tools für die Installation)
  

  

Wartungsfenster einrichten, um alle Benutzer abmelden

Bevor Sie mit dem Update beginnen, stellen Sie sicher, dass keine User im System angemeldet sind. Angemeldete User können im Windows Client über das Menü Extras / Aktive Benutzer oder im Web Client über Benutzermenü / Aktive Benutzer angezeigt werden. Aktive Benutzer können per "Mail senden" Aktion eine E-Mail erhalten.

Eine deutlich einfachere Variante ist die Anlage eines Wartungsfensters. Hierbei können die Benutzer informiert werden, dass eine Wartung ansteht und sie werden zum definierten Zeitpunkt vom System abgemeldet.

Unter Administration / Datenfluss einen neuen Wartungsfenster-Datensatz anlegen und dort die Informationen pflegen. Der Benutzer, der dort hinterlegt wird, muss auch das Update ausführen, da nur dieser Benutzer sich im Zeitraum des Wartungsfensters am System anmelden kann.
Es werden alle Timer für diese Zeit ausgesetzt, laufende Prozesse werden aber nicht unterbrochen. Es ist daher sinnvoll, wenn etwas Zeit vor dem eigentlichen Update für den Wartungszeitraum reserviert wird.

Externe Datenbankschnittstellen sollten ebenfalls während eines Updates deaktiviert werden.

Massendatenserver prüfen

Unter Optionen / Systemeinstellungen / Allgemein / Adresse des Anwendungsservers prüfen Sie, ob ein Massendatenserver eingerichtet wurde. Dieser darf zum Zeitpunkt des Updates nicht aktiv sein. Falls Sie das Update am Massendatenserver ausführen, erhalten Sie im Verlauf der Aktualisierung einen Hinweis.

Datenbank sichern

• Microsoft SQL Server: Über Microsoft SQL Server Management Studio.

• ORACLE: Auf dem Datenbankserver über EXPDP das aktuelle Schema exportieren.

Für beide Datenbanksysteme werden hierfür in der Regel Skripte bei der Installation bereitgestellt. Den genauen Pfad entnehmen Sie der bei der Installation mitgelieferten Installationsübersicht im Feld Skriptverzeichnis. Dies befindet sich im Abschnitt Datenbanken (DB).

Tipp

Bei Produktivsystemen kann es sinnvoll sein, die Sicherung vor dem Update manuell durchzuführen. Die Updateroutine kann die Sicherung allerdings auch durchführen. Wird die Sicherung vorher manuell erstellt, empfiehlt es sich, die Sicherung im Rahmen des Updates zu deaktivieren.

Alternativ ist es möglich unseren Spiegelungsassistenten zu nutzen:

Voraussetzungen des Spiegelungsassistenten:

• Verfügbar ab Version CRM Version 21.2

• Der ausführende Anwender muss Admin-Berechtigungen haben.

• Es muss mindestens eine 2-System-Landschaft mit gleicher CRM Version geben.

• Es dürfen keine offenen Customizing-Pakete in den Zielsystemen existieren (dies wird vom Assistenten geprüft).

Datenbank-Skripte sichern

Bei einigen Kunden wurden Änderungen an den Datenbank-Scripten in db\scripts oder im Verzeichnis db\scripts\stmts vorgenommen. Häufig ist die Datei propertymapper.sql angepasst oder auch die Datei RenewIndexes.sql um kundenspezifische Indizes erweitert.

Geplante Tasks deaktivieren

Bei einigen Kunden werden z.B. stündlich automatisch Tasks gestartet, die z.B. einen Import in die Datenbank ausführen. Diese Tasks müssen vor dem Update beendet werden, da es sonst Konflikte während der Aktualisierung der Datenbankstrukturen gibt.

Update-Vorgehensweise

Im folgenden Kapitel wird das Update einer CURSOR-CRM-Installation beschrieben. Hierbei müssen die folgenden drei Komponenten aktualisiert werden:

1. Datenbank

2. Applikationsserver

3. Windows Client

Automatisierter Updatevorgang

Voraussetzungen:

• Das Update muss auf dem Applikationsserver ausgeführt werden.

• Auf dem Applikationsserver muss auch der Rich Client installiert sein.

• Der Applikationsserver ist als Dienst gestartet und der aktuelle Benutzer der Maschine hat die Berechtigung, den Dienst zu beenden/starten, Dienste zu löschen und Dienste zu installieren

• Der Benutzer muss auch Powershell-Skripte ausführen dürfen, da diese genutzt werden, um die Datenbankverbindung im JBoss bekannt zu machen.
  (Lesen der aktuellen ExecutionPolicy: Get-ExecutionPolicy
  Setzen der ExecutionPolicy: Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Unrestricted

  Die ExecutionPolicy kann vom Administrator per Richtlinie auch fest auf einen Wert gesetzt werden, so dass nur er diese ändern kann.

Im Folgenden wird der Updatevorgang unter diesen Voraussetzungen beschrieben.

Bei einem Update müssen sowohl der Applikations-Server als auch der Rich Client aktualisiert werden. Der Web Client ist im Applikationsserver enthalten. Zunächst müssen sich alle Anwender vom System abmelden.

1. Erstellen Sie innerhalb des Installationsverzeichnisses der Anwendung ein Unterverzeichnis namens "update", z.B. D:\CURSOR\EVI\update

2. Entpacken Sie das Installationspaket in dieses Verzeichnis.

3. Die folgende Datei ausführen: "update.bat". Es ist auch möglich, das Installationsverzeichnis als Parameter zu übergeben, z.B. update.bat "D:\CURSOR\EVI\update"
   Unter Linux starten Sie das Update mit ./update.sh

D:\InstallDir\update>.\update.bat

Wenn Sie die Datei update.bat ausgeführt haben, erscheint (nach Auswahl der Installationssprache) ein Willkommensbildschirm:

Die Installation Klicken Sie auf "Weiter". Sie werden folgenden Dialog sehen:

Wechseln Sie zum folgenden Dialog. Sie werden aufgefordert, die Verzeichnisse ...server/JBoss und ...client/JBoss auszuwählen - im Standard wird dies automatisch erkannt, wenn Sie den Update-Ordner in ihr JBoss-Verzeichnis gelegt haben.

Im nächsten Schritt müssen Sie die Daten eines administrativen Kontos angeben, mit dem das Update durchgeführt werden wird, sowie das Sicherungsverzeichnis auswählen.

Wenn Sie jetzt auf Weiter klicken, wird automatisch mit dem nächsten Schritt fortgefahren (zunächst Datenbank-Backup) und danach der Server- bzw. Client-Backup-Vorgang entsprechend Ihrer Angaben ausgeführt.

Nun erfolgt die SSL Konfiguration (SSL-Kommunikationsstrecken & Zertifikate ):

Nach dem Klick auf Starte SSLUpdateTool erscheint folgender Dialog:

Danach kann der Installationsassistent mit weiter fortgeführt werden:

SSL Konfiguration (Sicherheitszertifikate)

• Die Konfiguration erfolgt mit dem Updater und der integrierten Anwendung "CURSOR Key- und Trustore Tool":

Weiterführende Informationen zur Thematik Sicherheitszertifikate finden Sie im Installationshandbuch unter dem Abschnitt Installation des Applikationsservers im Kapitel SSL-Installation und -Konfiguration (Das Installationshandbuch erhalten Sie auf Anfrage).

Danach erfolgt eine Zusammenfassung des Updates.

Sie müssen nun abwarten, bis der gesamte Updatevorgang automatisch zu Ende geführt wird.

Wenn Sie in den nächsten Schritt wechseln, werden Sie noch einmal aufgefordert, die Konfiguration entsprechend vorzubereiten, wie es hier zuvor beschrieben wurde. Prüfen Sie dies noch einmal und fahren Sie dann fort. Der Vorgang wird einige Zeit in Anspruch nehmen. Anschließend erhalten Sie einen ähnlichen Bestätigungsbildschirm wie folgt:

Mit einem Klick auf Beenden kann der Installationsassistent nun geschlossen werden.

Masterclient aktualisieren

Um nicht bei jedem Update oder Patch den Client neu verteilen zu müssen, bietet CURSOR-CRM die Möglichkeit, einen Master-Client zu verwenden. Das Installationsverzeichnis des Master-Clients entnehmen Sie der Installationsübersicht (Feld Auto-Update-Verzeichnis). Änderungen müssen somit nur an diesem einen Client durchgeführt werden. Bei der Anmeldung an CURSOR-CRM wird zunächst geprüft, ob Änderungen vorliegen. Sind Änderungen vorhanden, wird das Update des Clients voll automatisch durchgeführt. Somit ist mit minimalem Aufwand sichergestellt, dass alle Benutzer von CURSOR-CRM mit dem aktuellsten Client arbeiten.

Die zuvor konfigurierte Datei ..\client\jboss\custom\configuration.bat aus der neuen Version muss ebenfalls in den Master-Client übernommen werden. In der Datei ...\Client\jboss\custom\update.properties werden die Einstellungen zum automatischen Aktualisieren der einzelnen Verzeichnisse vorgenommen.

In dem Verzeichnis custom öffnen Sie die Datei update.properties mit einem Texteditor. Ändern Sie die folgenden Schlüssel auf das aktuelle Tagesdatum und die aktuelle Uhrzeit.

LAST-UPDATE=26.10.25 14\:00

BIN-DIR=26.10.25 14\:00
CONF-DIR=26.10.25 14\:00
EXT-DIR=26.10.25 14\:00
LIB-DIR=26.10.25 14\:00
CUSTOM-DIR=26.10.25 14\:00
UPDATE-TOOL-DIR=26.10.25 14\:00
JRE-DIR=26.10.25 14\:00

Der Eintrag LAST-UPDATE gibt die letzte Änderung an dem Master-Client an. Für jedes Verzeichnis gibt es einen Eintrag in der Datei update.properties (EXT-DIR, BIN-DIR, CONF-DIR, LIB-DIR, CUST-EXT-DIR usw.). Zum Aktualisieren muss das Datum und die Uhrzeit für jedes Verzeichnis und bei dem Eintrag LAST-UPDATE aktualisiert werden.

Aktivierung des automatischen Client-Updatetools

Der Master-Client muss in der Datei Client\jboss\custom\configuration.bat aktiviert sein. Hierzu gibt es in der Datei-Zeile 64 den Eintrag SET USE_UPDATE_TOOL=true. Dieser muss zum Aktivieren auf 'true' gesetzt sein.

Starten des Client-Updatetools

Beim Starten eines noch nicht aktualisierten Clients wird die folgende Fortschrittsanzeige angezeigt, die das Kopieren diverser Dateien visualisiert.

Datenbank-Statistiken aktualisieren

• Bei ORACLE-Datenbanken: Ausführen der Datei db\scripts\analyzeTables.bat (bei Linux db\scripts\linux\analyzeTables.sh). Hierdurch wird auch die SQL-Datei RenewIndexes.sql, die bei einigen Kunden erweitert wurde, ausgeführt.

• Bei MS-SQL eine Datenbankoptimierung durchführen.

Weitere Hinweise

Turnus zum Neustart des Applikationsservers

Tipp

Es wird empfohlen, den Applikationsserver in einem monatlichen Turnus neu zu starten. Häufigere Neustarts würden dazu führen, dass aus Performance-Sicht wertvolle Cache-Informationen temporär verloren gehen und damit neu aufzubauen wären.

Falls das Zusatzmodul CTI Schnittstelle im Einsatz ist, sollte der zusätzliche Dienst des CTI-Applikationsservers mindestens 1 Mal wöchentlich oder noch besser nächtlich neu gestartet werden, damit die CTI-Schnittstellen neu initialisiert werden können.

Dokumentenbearbeitung und externe Aufrufe im Web Client

Zur Nutzung der erweiterten Dateibehandlung und der externen Aufrufe im Web Client ist die Nutzung der "CURSOR Browser-Erweiterung" und des zugehörigen "Communication Host für die CURSOR Browser-Erweiterung" zwingend erforderlich.

Besonderheiten beim Einsatz eines CTI Servers.

Wenn die CTI-Schnittstelle im Einsatz ist, muss der dafür vorhandene JBoss ebenfalls aktualisiert werden.

Schriftarten

Die ausgelieferten Reports verwenden als Standardschriftart Tahoma, welche im TrueType Format auf dem Applikationsserver installiert sein muss. Läuft der Applikationsserver unter Linux, bietet es sich an, zunächst die MS TrueType CoreFonts zu installieren und anschließend noch den Tahoma-Font hinzuzufügen. 

Sofern Sie eine gültige Windows-Lizenz haben, kopieren Sie die Datei tahoma.ttf aus dem Verzeichnis C:\Windows\Fonts

Bei SuSE Linux

# als Benutzer root:
# Kopieren Sie die Datei tahoma.ttf in das fonts Verzeichnis
cp tahoma.ttf /usr/share/fonts/truetype
 
# Font-Cache neu laden
fc-cache

Alternative Schriftart-Bibliothek

Ist eine Installation der Schriftarten auf dem Server nicht möglich, können auch im Applikationsserver alle benötigten Schriftarten als Bibliothek installiert werden. Wie auch die Datenbank-Treiber wird die Datei cursor-font.jar im Verzeichnis ./custExt abgelegt

Eine vorkonfigurierte Bibliothek mit den Windows-Schriftarten Calibri und Tahoma können Sie von der CURSOR-Website herunterladen.

Link: https://www.cursor.de/software_mgmt/install/cursor-font.jar

Behobene Bugs

Informationen finden Sie in der Patch-Dokumentation im Kundenportal.

2025.2

Systemrelevante Informationen für Administratoren

-

Hinweise auf neue Funktionalitäten

Umbenenung des Feldes "2. Kd-Nr." im Geschäftspartner

Mit der Zusammenführung der Standardversion mit EVI und TINA wurde der bisherige Name des Geschäftspartner-Feldes "2. Kd-Nr." übernommen. Hießen die Felder in den EVI-Modulumgebungen bislang "ERP-GP-Nr.", so wurden sie überall auf "2. Kd-Nr." angepasst, sofern das Feld im Zielsystem nicht übersteuert und mit einem eigenen Namen ausgestattet ist.

Da das Feld überwiegend im EVU-Umfeld im Zusammenhang mit den ERP-Systemen Verwendung findet und weniger in CURSOR-CRM, wurde das Feld CustomerNo2.Customer im Standard auf "ERP-GP-Nr." angepasst. Im Englischen wird "ERP BP No." verwendet.

Aktualisierung der JavaScript-Bibliotheken im Bereich des Infoboards

Mit der Version 25.2 werden die veralteten Bibliotheken entfernt. Eine Umstellung muss zwingend vor dem Update auf 25.2 oder später erfolgen, um den Weiterbetrieb von Kacheln zu gewährleisten.

Für den Bereich der Kacheln besteht die Möglichkeit, innerhalb der Kachelkonfiguration im Bereich "Imports" auf eine neuere Bibliotheksversion zu wechseln. Dazu muss die Kachel in ihrer überschriebenen Variante geöffnet werden und durch An- und Abwahl des Bibliothekseintrages migriert werden, sodass die Prüfung der Kachel vorgenommen werden kann. Dies kann in der Regel durch den Test im System erfolgen. Hierbei empfiehlt es sich den Web Client zum Test zu nutzen. Ein Browser bietet die Möglichkeit Details und Fehlermeldungen durch die eingebaute Entwicklerkonsole einzusehen.

Die Dokumentation der einzelnen Bibliotheken ist auf den verlinkten Ressourcen einsehbar. Hierbei ist es hilfreich sich innerhalb der dort bereitgestellten Dokumentationen an Einträgen wie "Deprecated" oder "Removed" zu orientieren.

Am Beispiel jQuery:

• https://api.jquery.com/category/deprecated

• https://api.jquery.com/category/removed

Hinweise auf veraltete Funktionalitäten

Rückbau des Windows Clients für CURSOR-CRM

Mit der Abkündigung des Windows Clients im CURSOR CRM werden Bibliotheken und Funktionalitäten und der Aufruf des Windows Client selbst nach und nach entfernt. Einige Features, benannt im Readiness-Report, entfallen nach der Version 25.1 direkt. Der Readiness-Report verhindert auch das Update auf die Version 25.2, wenn die entsprechenden Umstellungen im Kundensystem nicht vorgenommen wurden:

• Workflow-Engine (Client und Server)

• Beanshell-Skripte

• Pixel-Layout Masken

Der Rückbau umfasst darauffolgende Punkte.

Client-Start und Admin-Konsole

• Der Client startet im Standard die Admin-Konsole

• Aus der Admin-Konsole werden Admin-Bereiche, die im Web Client sind entfernt

Workflow-Engine

• Kunden-Workflows werden gelöscht

• die Workflow-Laufzeitumgebung im Server wird entfernt

• Tests werden entfernt

Maskenskript

• Beanshell Maskenskripte und Historie wird entfernt

• Beanshell-Utility Bibliothek wird entfernt

• Beanshell Script-Engine wird entfernt

$GLOBAL in Skripten

• Die Ersetzung von $GLOBAL findet nicht mehr statt

• Der Groovy-Cache greift nun immer

BPM-Prozesse "Immer Ausführen"

• Die Laufzeit-Umgebung wird entfernt

• Das Ereignis ist im Start-Event nicht mehr auswählbar

• Alte Prozesse können importiert werden, aber nicht mehr veröffentlicht werden

Alter GUI-Builder

• Der Aufruf des alten Maskeneditor wird entfernt

• Pixel-Masken werden gelöscht

Desktop-Link

• Desktop-Link im Link-Dialog wird entfernt

• im Link-Dialog "Web Link" wird zum "Link" umbenannt

• Wenn Datensätze als Link versendet werden (in Listenansichten (einzelner Datensatz + Mehrfachauswahl), im Unterbereich, jeweils über das Dropdownmenü) wurde die Bezeichnung "Desktop Link" durch"iOS Link" ersetzt

Entfernung von Kacheln

Folgende Kacheln wurden entfernt:

• Kontaktbuttons

• Supportaktivitätenvorschau