Kernmodul Konfiguration

Die administrativen Masken erscheinen bei der Anmeldung von Benutzern, die Administratorrechte haben (z.B. voreingestellte User superx und admin).

aufruft. Nach der Anmeldung und Wechsel unter "Standardberichte" erscheinen die Masken im Themenbaum unter "Administration".

Nach Anklicken eines Unterpunkts (wie Institution suchen) erscheint auf der rechten Seite ein Dialog zur Suche des jeweiligen Eintrags.

Tabelle hochschulinfo

Die Tabelle hochschulinfo enthält die Nummer und den Namen der eigenen Hochschule.

Der Schlüssel der Hochschule wird in der Tabelle cif bzw. cifx benutzt, um hochschuleigene Schlüssel von allgmeinen Schlüsseln abzugrenzen.

Sie können die Hochschulinfo in einem DBFORM pflegen; gehen Sie dazu im XML-Frontend auf "Tabelle suchen"-> hochschulinfo. Sie erhalten ein Bearbeitungsformular mit einem Datensatz:

Wählen Sie Ihre Hochschule aus. Wenn Ihre Hochschule in dem Klappmenü nicht enthalten ist, ermitteln Sie diese aus dem Schllüsselverzeichnis des STBA oder Ihres Landesamtes (Bereich Personal) und tragen sie sie manuell mit einem SQL-Tool in die Tabelle ein.

Das Organigramm bearbeiten

Das Organigramm ist eine hierarchisch aufgebaute Tabelle von Organisationseinheiten und wird in SuperX für Berechtigungskonzepte genutzt. Es enthält auch die Fakultäten und Lehreinheiten. Teilweise wird in der Anwendung oder Dokumentation auch der Begriff "Institution" genutzt, dies ist synonym.

Meist wird das Organigramm aus anderen Vorsystemen gefüllt, z.B. HISCOB. Wenn die Hochschule das Organigramm allerdings selbst pflegt, gibt es die Möglichkeit, die Einsträge in einem einfachen Browser-Formular zu bearbeiten. Zunächst muss also die Organigrammquelle bearbeitet werden.

Organigrammquelle bearbeiten

Die Organigrammquelle kann unter Administration konfiguriert werden:

Neben der manuellen Pflege ist auch die automatische Übernahme aus HISinOne oder COB-GX möglich. In diesem Falle übernimmt das Laden die Hauptladeroutine Adminstration / Kernmodul.

Organisationseinheiten bearbeiten

Wenn man den Punkt Organisationseinheit suchen anklickt und das Formular abschickt, erscheint z.B. folgendes Bild:

Ohne Einschränkung werden alle Institutionen im Organigramm angezeigt. Mit dem rechten Button "Bearbeiten" gelangen Sie in eine Bearbeitungsmaske.

Wenn die Organigrammquelle nicht manuell ist, können Sie im Bearbeitungsformular nur Inhalte lesen, nicht ändern:

Wenn die Organigrammquelle "manuell" ist, können SIe auch Inhalte ändern:

Die Bearbeitungsmaske ermöglicht die Änderung der Bezeichnung (Feld "name", das Feld "drucktext" ist ein Kurztext und wird normalerweise nicht angezeigt), der übergeordneten Institution ("Parent") sowie der Gültigkeit. Außerdem kann man die Ebene, das Lehrekennzeichen, ggfs. Kennzeichen Orgstruktur und den Gültigkeitszeitraum bearbeiten.

Wenn man den Button Neu anklickt, erscheint der gleiche Dialog, bei dem man den Namen,Schlüssel ( key-apnr) etc. der neuen Organisationseinheit eingeben kann.

Anklicken des Löschen-Buttons entfernt eine Organisationseinheit aus dem Organigramm.

Wenn eine Organisationseinheit verschoben werden soll, z.B. Philosophie von Fachbereich 1 nach Fachbereich 6, geht dies über die Zuweisung des "Eltern"-Elements. Da die übergordnete Institition in einem Klappmenü bei großen Hochschulen unübersichtlich ist, wurde die Zuweisung in ein separates Fenster mit Suchfunktion ausgelagert:

Wenn Sie alle Änderungen gemacht haben, können Sie diese durch Anklicken des Speichern-Buttons in die Datenbank übernehmen.

Den Themenbaum bearbeiten

Wenn man den Punkt Themenbaum-Eintrag suchen anklickt und das Formular abschickt, erscheint z.B. folgendes Bild:

Die Bezeichnungen von Maksen werden hier nicht vorgenommen, sondern nur in der Tabelle maskeninfo.

Ein Eintrag kann in der jeweiligen Zeile durch Anklicken von löschen entfernt werden.

Wenn Sie eine neue Kategorie wie Administration, Studierende oder Haushalt oder neue Masken einhängen wollen, wählen Sie unten Neu.

Neu seit Kernmodul3.5rc2 ist die Spalte sort. Diese ermöglicht eine andere als die alphabetische Sortierung, die der Standard ist. Sie können Sie mittels Formular oder auch direkt in der Datenbank bearbeiten.

Ein  Beispiel  für  eine  nicht-alphabetische  Sortierung

Innerhalb einzelner Knoten wird wieder alphabetisch sortiert. Wenn Sie aber z.B. Abfragen unter Kostenrechnung anders sortieren möchten, könnten Sie Sortiernummern von 4001 bis 4999 nutzen.

(Intern wird zuerst nach sortnummer und dann nach der Bezeichnung sortiert, wobei die Hierarchie im Baum aber bewahrt bleibt.)

Tipp: Um Einträge im Themenbaum unsichtbar zu machen, besteht der einfachste Weg darin, ihr Gültigkeitsdatum (gültig bis) auf einen Wert kleiner als heute zu setzen.

Ab Kernmodul 4.7 lassen sich Themenbaum-Knoten auch mit Icons versehen. In der CSS-Klasse können Sie Iconf-fonts zuweisen.

Bei „HTML CSS class“ dazu einfach „icon“ + Leerzeiche + gewünschtes Icon-font eintragen. Beispiel: „icon icon-magic“.

Welche Icons zur Verfügung stehen und welcher Code dafür eingegeben werden muss erfahren Sie auf Ihrem SuperX Server unter <>/superx/xml/fonts.html bzw. online.

Hochschul-Repository

Filter und Variablen liegen im Hochschul-Repository und ermöglichen der Hochschule, Laderoutinen oder Oberflächen an hochschuleigene Gegebenheiten anzupassen, z. B. um häufig genutzte Filter in Masken zu konfigurieren, oder um Laderoutinen zu steuern. Bei letzteren ist die ID des Filters vorgegeben, bei ersteren ist nur die Art des Filters vorgegeben. In jedem Fall ist es sinnvoll, einen vorhandenen Filter zu kopieren.

Hochschul-Repository anzeigen

1. Gesamtes Repository anzeigen
   1. Klicken Sie auf Standardberichte -> Administration ->Hochschul-Repository
   2. Schränken Sie die Selektionsparameter nach Belieben ein
      • Stichwort
      • : z. B. SOS_STUD_FILTER
      • Sachgebiet
   3. Klicken Sie auf Abschicken, Ihnen werden alle Repository-Variablen angezeigt

Hochschulspezifische Filter anlegen

In fast jedem SuperX-Modul gibt es die Möglichkeit, hochschuleigene Filter anzulegen. Die Maskenfelder dazu lauten "Filter Studierende", "Filter Personal" etc.

Hier ein Beispiel:

Hinter dem Namen des Filters verbirgt sich eine SQL-where-Bedingung. Die Bedingung wird vor dem Hintergrund der jeweiligen Hilfstabelle formuliert, hier z.B. die Hilfstabelle "Studierende" im SOS-Modul. Die zugehörige Tabelle finden Sie auf der Seite der Datenbankbeschreibung des Moduls, hier z.B.

http://www.superx_projekt.de/doku/sos_modul/sos.html

Dort schauen Sie rechts in der Spalte "Hilfstabellen", welche Tabellen es gibt. Die gesuchte Tabelle lautet sos_stg_aggr

https://super-ics.de/superx/doku/sos_modul/sos.html#tab_sos_stg_aggr

Wenn Sie z.B. einen Filter "nur weibliche Studierende"erzeugen wollen, wählen Sie zunächst im Maskenfeld "Geschlecht den gewünschten Wert:

Klicken Sie auf den Button "Schlüssel anzeigen"

Danach  sehen  Sie  den  Wert  des  Schlüssels:

Der Wert für weiblich ist "2". Dann wäre die Bedingung:

Den Inhalt des Filters können Sie in der Tabelle "Hochschul-Repository" einpflegen: Gehen Sie im Browser in das Menü Klicken Sie in der gewünschten Komponente auf Standardberichte -> Komponente -> Administration Komponente -> Prüfprotokoll Komponente -> Filter und Variablen. Sie erhalten verschiedene Beispielfilter, allen ist gemeinsam, daß sie im Feld "Art der Variable" den Wert "SOS_STUD_FILTER" haben. Wenn Sie einen neuen Filter eingeben wollen, gehen Sie unten auf den Button "Neu". Dann geben Sie die Werte ein:

Danach gehen Sie im Manager auf Cache leeren, und öffnen eine Studierenden Maske erneut:

Sie können auch komplexere Filter einbauen, z.B. "nur Haupthörer, ohne 1. Hochschulsem., ausl. Staatsangehörigkeit", indem Sie die where-Bedingungen mit "and" verknüpfen. Achten Sie bei der Syntax darauf, dass die SQL-Syntax nicht zerstört wird. Bei alphanumerischen Feldern müssen Sie z.B. immer ein einfaches Hochkomma um die Werte setzen.

Konstanten

Hier eine Auflistung der Konstanten im Kernmodul:

Einstellungen zur Passwortsicherheit

Bei der Installation des SuperX-Kernmoduls werden in die Tabelle konstanten vier Einträge zur Einstellung der Passwortsicherheit gemacht. Um die Konstanten zu ändern, gehen Sie als Administrator in die Anwendung, gehen Sie in das Menü "Administration"->"Tabelle suchen" und suchen Sie die Tabelle "konstanten". In der Zeile klicken Sie auf den "Bearbeiten"-Button, und suchen dort die Konstante Passwortgültigkeit (Tage) etc.

Um kurzfristig die Gültigkeit aller User auf unendlich zu setzen (z.B. bei Testbetrieb), müssen sie in der Datenbank folgenden Update ausführen:

update  user_pw  set  pw_gueltig_bis=date_val('01.01.3000');

Erweiterte Nutzungsstatistiken

Sofern das mit dem Datenschutz konform geregelt wird, gibt es ab Kern5.1 die Möglichkeit, erweiterte Nutzungsstatistiken zu sammeln.

Dazu setzen Sie die Konstante "Nutzungsstatistiken" auf den Wert 2 und Aktualisieren den Manager-Cache.

Ergebnisse der Nutzungsstatistiken landen in der Tabelle masken_protokoll.

Diese kann über die Funktion Administration | Tabelle ausgeben, ausgewertet werden.

Durch eine weitere Konstante "Nutzungsstatistiken loeschen nach Tagen" kann eingestellt werden, dass die Nutzungsstatistiken, die älter als X Tage sind, gelöscht werden. Dies geschieht, wenn der Webanwendungsmanager Cache aktualisiert wird (manuell oder automatisch morgens gegen 7 Uhr).

Downloads einrichten und verteilen

SuperX bietet die Möglichkeit, beliebige Dateien über die Webapplikation an Anwender auszuliefern, z.B. um einen Downloadbereich einzurichten. Die Downloads können einzelnen Usern oder Gruppen sowie Institutionen und Themen zugeordnet werden.

Konfiguration Downloads

Die Download-Dateien werden in dem geschützten Verzeichnis der Webapplikation gespeichert. Um die Dateien gezielt in einem Verzeichnis zu speichern, muss man ggf. das Attribut "directory" des Feldes "datei" in der Tabelle sx_downloads in der Datei dbforms-config.xml setzen, standardmäßig ist dies (relativ zu dem Startpfad von Tomcat) "../webapps/superx/WEB-INF/downloads".

Mit dem Attribut "encoding" (default "false") wird festgelegt, ob der Dateiname vom Original übernommen werden soll ("false") oder ob eine eindeutige Zufalls-Zeichenkette ("true") erzeugt werden soll. Die Endung der Datei wird bei letzterem beibehalten.

Gleichzeitig werden der Dateiname und diverse andere Metadaten in der Tabelle sx_downloads gespeichert. Wenn ein Anwender einen Download abruft, dann wird die Datei im SuperX-Servlet geladen und über http(s) ausgeliefert.

Die Auslieferung von Dateien wird defaultmäßig protokolliert und kann über die Maske "Downloadstatistik" abgerufen werden. Sie können diese Funktionalität (z.B. aus Datenschutzgründen) sperren, indem Sie die Konstante "DOWNLOAD_PROTOKOLL" statt auf "1" auf "0" setzen - damit werden keine Download-Aktivitäten in SuperX protokolliert (was aber nicht bedeutet, dass dies auch im Webserver-Log nicht mehr passiert, die dortige Protokollierung sowie die Tomcat-eigene Protokollierung ist davon unabhängig).

Außerdem können Sie die maximale Größe von Dateien festlegen. Dafür gibt es in der web.xml einen Parameter "maxUploadSize", der die maximal Größe (in Bytes) beschreibt:

control

org.dbforms.servlets.Controller

maxUploadSize

800000

Tabellenstruktur

Es gibt eine Tabelle sx_downloads mit folgenden Feldern:

Desweiteren gibt es eine Tabelle sx_keywords zur Erhebung der Stichworte:

Die Zuordnung zwischen Download und Stichwort findet in der Tabelle download_keyw_bez statt:

Berechtigung für Downloads

Die Berechtigungen für die Downloads werden über die SuperX-Gruppen- bzw. Userrechte verwaltet. Dazu werden eigene Tabellen user_download_bez und group_download_bez erzeugt, für die auch Pflegeformulareexistieren. Die Institutions-Berechtigung wird auch Bordmitteln von SuperX realisiert, d.h. die Anwender erhalten über ihre Zuordnung zur jeweiligen Kostenstelle in der Tabelle user_institution das Recht für die Kostenstelle und alle jeweils untergeordneten Kostenstellen.

Einzelne vorgefertigte Masken sind bereits eingerichtet und werden im Folgenden beschrieben.

Masken zur Erzeugung und Verteilung von Downloads

Im XML-Frontend finden Sie die Download-Masken im Themenbaum-Ast "Administration".

Download suchen

Mit der Maske "Download suchen" können sie einzelne Downloads einrichten, bearbeiten oder löschen.

Das Freitext-Feld Suchwort bezieht sich auf den Namen des Downloads.

Download bearbeiten: Metadaten und Dateien

In der Bearbeitungsmaske erscheinen die oben beschriebenen Felder nebst Erläuterungen.

Sie können, müssen aber nicht, einem Download einer einzelnen Kostenstelle zuordnen. Hierarchische Anordnungen werden dabei suchbar, d.h. wenn ein Anwender in der Insitutions-Sicht des Organigramms eine Kostenstelle auswählt, dann werden alle Downloads mit untergeordneten Kostenstellen ebenfalls gefunden.

Sie können Dateien Hochladen, inden Sie in der Zeile Datei eine neue Daten festlegen. Ansonsten wird darüber der aktuelle Dateiname festgelegt. Wichtig ist, dass der Dateiname in dem Verzeichnis $SUPERX_DIR/webserver/tomcat/webapps/superx/WEB-INF/downloads eindeutig ist. Außerdem funktioniert der Browser-basierte Upload nur mit kleinen Dateien, größere Dateien sollten Sie manuell in das Verzeichnis $SUPERX_DIR/webserver/tomcat/webapps/superx/WEB-INF/downloads kopieren.

Sie können auch Datensätze kopieren, allerdings werden nur die Metadaten werden kopiert, Sie müssen dann eine neue Datei hochladen.

User- und Gruppenrechte auf Downloads

Mit der Schaltfläche unter "User- und Gruppenrechte" sehen Sie das Bearbeitungsformular.

Stichworte für Downloads

Mit der Schaltfläche unter "Stichworte zuordnen" sehen Sie das Bearbeitungsformular.

Überwachung und Performance

SuperX besteht aus verschiedenen Komponenten, die jeweils eigene Überwachungsmerkmale und Performance-Mechanismen besitzen.

Monitoring und Performance der Webanwendung

Die Webanwendung baiert auf Tomcat, und die Logdateien des Tomcat liegen standardmäßig im Verzeichnis $SUPERX_DIR/webserver/tomcat/logs. Die Logdateien im Einzelnen:

• Logging von Tomcat: catalina.out bzw. localhost.xxx.out
• Logging der SuperX-Webanwendung jeweils in superx_default.log (statt "default" ggf. die Mandantenid) für allgemeines SQL-Logging, und superx_default_xml.log für das Logging der XML-Ausgabe des XML-Frontends.
• dbforms.log für Logging der DBForms-Komponente

Alle Logging-Ausgaben lassen sich flexibel an verschiedenen Stellen steuern:

• Das Tomcat-Logging lässt sich in der Datei $SUPERX_DIR/webserver/tomcat/common/classes/log4j.properties steuern
• Das Ausmaß des Loggings der SuperX-Webanwendung: In der db.properties wird der Logging-Level für die SQL-Ausgabe sowie für die XML-Ausgabe festgelegt.
• Das Logging für DBFORMS und Mondrian / Saiku wird in der Datei $SUPERX_DIR/webserver/tomcat/webapps/superx/WEB-INF/log4j.properties festgelegt.
• Das Logging der java-bezogenen SuperX-DB-Anwendung wird in der Datei $SUPERX_DIR/db/conf/logging.properties gesteuert.

Die SQL-Scripte der SuperX-Abfragen können in der o.g. superx_default.log eingesehen werden. Bitte beachten Sie dabei, dass bei SQL-Fehlern nur im Entwicklungsmodus die genaue Stelle des Auftretens ermittelt werden kann.

Webanwendung Manager

Allgemeines zum Webanwendung Manager

Wenn Sie als Administrator_in angemeldet sind können Sie den Webanwendung Manager aufrufen, der

• Auf der Startseite zentrale Umgebungsvariablen anzeigt, z.B. Server-Runtime-Parameter und Servlet Parameter
• Zugriff auf die Logs bzw. Inhalte der jeweils zuletzt ausgeführten Masken bietet
• Details zur Datenbank-Verbindung anzeigt
• Browserbasierten Zugriff auf einzelne Logdateien der Applikation bietet.

Der Aufruf im Themenbaum:

Die Startseite zeigt die Server- und Servlet-Einrichtung:

Server Cache im Webanwendung Manager

Sie können die jeweils zuletzt aufgerufenen Masken kontrollieren, und den Server Cache leeren:

Im Server Cache befinden sich

• Menüobjekte pro Benutzer_in, d.h. auch Gruppenrechte
• Themenbaum-Strukturen
• Sichten
• Maskenrechte
• Translets bei der XSL-Verarbeitung
• Makros und Makro-Masken-Feldwert Beziehungen

Masken im Webanwendung Manager

Detailinformation zu Masken finden Sie in unserem Tutorial. Die jeweils zuletzt aufgerufenen Masken lassen sich protokollieren bzgl.

• Aufruf:

• SQL-Logs vor Freemarker Transformation:

• SQL-Logs nach Freemarker Transformation:

• XML-Ergebnis:

DB-Verbindung im Webanwendung Manager

Die Datenbank Verbindung läßt sich im Reiter "Datenbank" einsehen, dies ist nur eine Browseransicht auf die db.properties Datei.

Logdateien im Webanwendung Manager

Wenn die Administrator_en keinen dateibasierten Zugriff auf den Applikationsserver haben, lassen sich wichtige Logdateien auch im Browser aufrufen und die Anzahl der Zeilen (vom Ende gesehen) variieren:

Die Server-Logdatei ist gemeinhin die Datei

$TOMCAT_BASE/logs/catalina.out

Sie können auch die SQL- und XML-Logdatei aufrufen:

$TOMCAT_BASE/logs/superx_Mandantid.log
$TOMCAT_BASE/logs/superx_Mandantid_xml.log

Java-Monitoring mit JConsole

Ab Java 1.6 und Tomcat 5.5 gibt es eine komfortable Möglichkeit, den Server zu überwachen. Vor dem Start von Tomcat setzen Sie die Option CATALINA_OPTS wie folgt:

Sie starten den Tomcat dann mit einer Überwachungsschnittstelle auf Port 8020, die Sie dann von einem (entfernten) Client auswerten können:

Diese Anwendung liefert detailliert Aufschluss über den Server:

Wir empfehlen, im Produktivbetrieb dies abzuschalten (Sicherheitslücke und Performance-Kosten).

Eine detailliertere Anleitung finden Sie hier:

http://blog.linkwerk.com/entry/cl/2007-05-08T12.00.00

Generell empfehlen wir, den Tomcat im Produktivbetrieb jede Nacht einmal neu hochzufahren, im SuperX-Kernmodul wird dazu ein Beispielscript ausgeliefert (db/bin/restart_tomcat.x). Ein weiteres nützliches Script prüft z.B. alle 5 Minuten, ob der Server noch läuft; wenn nicht dann wird er automatisch hochgefahren (db/bin/check_restart_tomcat.x).

Konfiguration der Datenblatt-Berichte: max. Zeilenanzahl

Datenblätter, die auf zentrale Funktionen des Kernmoduls zurückgreifen, lassen sich mit einer maximalen Zeilenanzahl konfigurieren. So kann verhindert werden, daß Anwender/innen ein zu umfangreiches Datenblatt abrufen, das den Datenbankserver über Gebühr belastet bzw., wie uns bei Informix berichtet wurde, sogar zum Absturz bringen kann.

Setzen Sie dazu die Konstante "Datenblatt max.Zeilenzahl" auf den Wert, der zu Ihrem Server paßt. Defaultwert ist 20.000 Zeilen.

Menüpunkt "Administration → Tabelle suchen → Stichwort "Konstanten" → Listenformular aufrufen und zur Konstante "Datenblatt max.Zeilenzahl" navigieren, und diese dann auf den entsprechenden Wert setzen.

Im Ergebnis erhalten Benutzer, die ein Datenblatt mit zu vielen Zeilen abrufen, folgende Meldung (z.B. bei max. 40 Zeilen):

Wenn das Datenblatt gar nicht angezeigt wird und direkt ein JasperReport aufgerufen wird, kommt folgende Meldung:

SQL Benchmark Script

Da die Laufzeiten der Updates und Berichte immer wieder ein Thema an den Hochschulen ist, möchten wir versuchen Vergleichswerte zu schaffen und auch den Hochschulen die Möglichkeit bieten, zu prüfen, wie die Leistung der SuperX Datenbank zu bewerten ist. Mit dem Benchmark Script kann zu jeder Zeiten mit den gleichen Werten die Datenbank geprüft werden. Dadurch sind die Laufzeiten gut für Vergleiche geschaffen. Der Update der Module kann durch die angestiegene Anzahl der Datensätze/Studierenden im laufe der Zeit ansteigen. Ziel dieses Scripts ist somit einmal der Vergleich mit anderen Hochschulen und auch testen zu können, ob im laufe der Zeit der Server mit anderen Aufgaben zu sehr ausgelastet wird.

SQLBenchmark Script downloaden

Das Script erhalten Sie im SuperX Download-Bereich:

http://download.superx-projekt.de/

Geben Sie als Stichwort Benchmark ein.

SQLBenchmark Script ausführen

Wenn Sie das Script heruntergeladen haben, speichern Sie es am besten auf dem Server, von dem Sie die Updates starten. Dort laden Sie dann Ihre SQL_ENV und starten das entpackte Script mit DOSQL. Wenn Sie möchten können Sie die Ausgabe noch in eine Logdatei mit Datum umleiten um das Ergebnis zu sichern und in Zukunft weitere Logdateien für Vergleiche erstellen.

SQLBenchmark Script Vergleichswerte

Hier noch ein paar Vergleichswerte.

Datenschutz

Sperrung von Berichten für HTTP GET-Anfragen

Vorbemerkung: GET Anfragen werden für Masken in folgenden Szenarien erstellt:

• Deeplinks oder Lesezeichen
• Umsortieren der Spalten / Zeilen einer Ergebnistabelle
• Kommandozeilengesteuerte Ausführung von Masken
• Portlets

Dabei wird in der URL der jew. Parameter mit übergeben, z.B.

Dies ist kein Problem, solange die Maske zur reinen Anzeige von Daten dient; unter anderem das "Masken-SQL" kann allerdings auch Statements zur Datenmanipulation enthalten (z. B. INSERT/UPDATE) - das wurde in einigen Fällen genutzt, um über Masken administrative Funktionen zur Verfügung zu stellen (z. B. Maske kopieren).

Aus diesem Grund wurde im SuperX-Kernmodul 5.0 bzw. HISinOnbe-BI 2023.06 umgesetzt:

• Alle Masken sind defaultmäßig in der "Blacklist", d.h. sie lassen sich nicht über GET aufrufen.
• Es gibt aber die Möglichkeit, HTTP GET-Aufrufe für bestimmte Berichte zu unterbinden. Zu diesem Zweck werden Dateien mit den Namen
  • http_get_masken_blacklist.txt
  • http_get_masken_blacklist_custom.txt
  • http_get_masken_whitelist.txt"

im Verzeichnis

...webapps/superx/WEB-INF

beim Tomcat Start ausgewertet:

Die "http_get_masken_blacklist.txt" enthält die tids aller Masken, welche in der Standardauslieferung nicht über HTTP GET aufrufbar sind - an dieser Datei dürfen auch keine Änderungen vorgenommen werden, da diese durch ein neue Releases und Hotfixes überschrieben würden. Will man diese Liste erweitern, so muss man eine (utf-8) Datei "http_get_masken_blacklist_custom.txt" mit gleichem Format im selben Verzeichnis anlegen. Wenn man (wieder im selben Verzeichnis) eine (utf-8)-Datei "http_get_masken_whitelist.txt" mit gleichem Format anlegt, dann überbrückt diese die beiden anderen Dateien:

Statt einer "blacklist" mit Masken-tids, für die der Aufruf über HTTP GET unterbunden wird, gibt es dann eine "whitelist" mit Masken-tids, für die der Aufruf per HTTP GET erlaubt ist - für alle anderen wird er unterbunden.

Änderungen an den Dateien werden nur bei einem Neustart des Tomcat-Servers wirksam.

Im Clusterbetrieb ist natürlich darauf zu achten, dass Dateien mit eigener Konfiguration auf alle Knoten verteilt werden. Unterbundene HTTP GET-Aufrufe werden im Log vermerkt.

Auf eine Ausnahme sei an dieser Stelle noch hingewiesen:

HTTP GET-Aufrufe mit dem Parameter getKidRows werden immer zugelassen, da sie für Berichte mit Drilldown-Funktion notwendig sind - das ist aber in Ordnung, da sie keine Datenmanipulation auslösen.

Nach einer Änderung von Black- oder Whitelist muss der Tomcat neu gestartet werden.