Modulverwaltung

Allgemeines

In der Administrationskonsole werden die einzelnen Module verwaltet und der aktuelle Status der Module überwacht. Alle Module des Systems werden in der Liste angezeigt. Ist ein Modul deaktiviert oder abgelaufen, so wird das durch die entsprechenden Icons und 🔒 kenntlich gemacht.

Abbildung: Modulverwaltung in der Administrationskonsole

Jedes Modul besitzt ein Gültigkeitsdatum und eine Anzahl an Benutzerlizenzen. Liegt das Gültigkeitsdatum am 01.01.1970, dann ist das Modul unbeschränkt einsetzbar. Ist bei den Benutzerlizenzen eine 0 eingetragen, dann ist dieses Modul mit einer Firmenlizenz ausgestattet.

Der Administrator kann eine geänderte Modulkonfiguration von CURSOR Software AG importieren, z.B. wenn 10 weitere Benutzerlizenzen bestellt wurden. Für den Support kann es nötig sein, die Modulkonfiguration zu exportieren. Die gesamte Konfiguration wird dann als XML-Datei gespeichert und kann per Mail verschickt werden.

Symbol	Aktion
	Importiert die Lizenzdatei
	Exportiert die Lizenzdatei
	Zuweisung von Benutzerlizenzen, wenn keine Firmenlizenz vorhanden ist
	Kundenlizenzen bearbeiten. Nur für Software-Hersteller und Partner relevant.
	Kundennummer ändern. (kein SQL-Statement mehr notwendig)

Lizenzen verwalten

Die CURSOR Software AG bietet zwei Lizenzierungsmodelle an:

Benutzerlizenzen
Die Anzahl der Benutzer wird festgelegt. Jeder Benutzer muss als Mitarbeiter angelegt werden und eine Lizenz zugewiesen bekommen.
Firmenlizenzen
Die Anzahl der Benutzer wird nicht eingeschränkt. Jeder angelegte Mitarbeiter kann ohne explizite Lizenz-Zuweisung sofort im System arbeiten.

Ist ein Modul auf Basis von Benutzerlizenzen (> 0) freigeschaltet, dann können Mitarbeiter diesem Modul hinzugefügt werden. Es können maximal so viele Mitarbeiter einem Modul zugeordnet werden, wie Lizenzen verfügbar sind. Hat das Modul eine Firmenlizenz (Benutzerlizenzen = 0), dann ist dieser Punkt deaktiviert.

Kundenlizenzen bearbeiten

Über den Schalter Kunden-Lizenzen bearbeiten > Module hinzufügen können Module zu Lizenzdateien hinzugefügt werden. Um eine bessere Übersichtlichkeit zu erreichen, sind die Listen filterbar.

Texte aus C0- und C1-Modulen übersteuern

Zu einem C0- oder C1-Modul können spezifische I18n-Texte angelegt werden (siehe Bild). Das I18n-Resource-Bundle wird beim Modulexport/Import mit allen Schlüsseln übertragen. Die I18n-Einträge können in der C2-Schicht angepasst und als Paket übertragen werden

Ein Update auf dem C1-Modul überschreibt nur die C1-I18n-Werte und nicht die C2-I18n-Werte.

Abbildung: Übersteuerung von C0-Texten in Modulen

Prüfungen von Modulen

Prüfungen beim Veröffentlichen

Beim Veröffentlichen von Modulen finden nun folgende Prüfungen statt:

ob alle modulabhängigen Prozesse veröffentlicht sind
ob alle modulabhängigen Skripte veröffentlicht sind/unveröffentlichte Skriptentwürfe existieren
ob alle enthaltenen Reports fehlerfrei kompilierbar sind

Prüfungen beim Export

Beim Export des Moduls passieren dieselben Prüfungen sicherheitshalber noch einmal (analog zum Customizing-Transport).

Patch-Level-Prüfung

Bei der Veröffentlichung eines Moduls können Patch-Level hinterlegt werden, die mindestens nötig sind, um ein Modul zu veröffentlichen. Somit wird vermieden, dass nicht lauffähige Modul-Versionen eingespielt werden. Die Patch-Level werden im Modul gespeichert und können bei der nächsten Veröffentlichung des Moduls verändert werden. Beim Import des Moduls im Zielsystem wird geprüft, ob für die aktuelle Version ein Patch-Level hinterlegt wurde und wenn ja, ob dieses vorhanden ist. Andernfalls lässt sich das Modul nicht einspielen und man erhält eine Fehlermeldung.

Abbildung: Konfiguration eines Patch-Levels für ein Modul

I18n-Import von Modulen nur in einem Wartungsfenster erlauben

Der Start des I18n-Imports von Modulen prüft zu Beginn, ob noch weitere Benutzer im System sind.

wenn ja, wird ein Hinweis ausgegeben, dass der Import nur im Rahmen einer Wartung erfolgen darf
wenn nein, wird geprüft, ob bereits ein Wartungsfenster vorhanden ist
- wenn ja, wird der Anwender gefragt, ob er den Import starten möchte
  - wenn ja, wird der Import gestartet
  - wenn nein, wird der Import abgebrochen
- wenn nein, wird der Anwender gefragt, ob er den Import im Rahmen einer Wartung durchführen möchte
  - wenn ja, wird direkt ein Wartungsfenster erstellt und der Import gestartet
  - wenn nein, wird der Import abgebrochen

Aufsplitten eines Hauptpartner-Moduls in ein Standard-Modul und ein Hauptpartner-Modul

Es gibt einen Schalter in der Modulverwaltung, der alle Konfigurationen, für die ein Hauptpartner-Modul notwendig ist, aus dem bestehenden Hauptpartner-Modul extrahiert und in ein neues Modul schreibt. Danach wird auf dem bestehenden Hauptpartner-Modul das Flag entfernt und in das neu erstellte, extrahierte Modul geschrieben, das dann als Hauptpartner-Modul gekennzeichnet wird.
Das extrahierte Hauptpartner-Modul ist dann von dem ehemaligen Hauptpartner-Modul abhängig.
Die Moduldaten werden bei der Aufteilung angegeben werden, da nur ein Hauptpartner-Modul in einem System vorhanden sein kann.

Beim Import eines Hauptpartnermoduls wird geprüft, ob das Hauptpartnermodul Abhängigkeiten zu einem bestehenden Modul desselben Partners hat und ob dieses Modul eine aktive Lizenz hat. Wenn ja, dann wird das Hauptpartnermodul auch direkt aktiviert, wenn nein, so muss wie bisher separat eine Lizenz eingespielt werden.

Abbildung: Modul-Aufsplittung

Schlüssel in nicht lizenzierten Modulen (Web Client)

Schlüssel, die einem Modul zugewiesen sind, für welches keine gültige Lizenz vorliegt, werden in der Schlüsselbearbeitung durchgestrichen angezeigt. Die Schlüssel sind nicht bearbeitbar und können in der Anwendung nicht ausgewählt werden.

Abbildung: Schlüssel in nicht lizenzierten Modulen