Zuletzt bearbeitet vor 7 Monaten
von Daniel Quathamer

Modul COSTAGE Administrationshandbuch

Installation

Erstinstallation

Wenn Sie die Installationsdatei heruntergeladen und entpackt haben, gehen Sie wie folgt vor:

  • Ergänzen Sie den Inhalt der Datei $SUPERX_DIR/db/bin/SQL_ENV und den Inhalt der Datei SQL_ENV_costage.sam im gleichen Verzeichnis:
cat $SUPERX_DIR/db/bin/SQL_ENV_costage.sam >>$SUPERX_DIR/db/bin/SQL_ENV

Danach laden Sie die SQL_ENV neu und starten die Installation:

. $SUPERX_DIR/db/bin/SQL_ENV
cd $COSTAGE_PFAD
module_install.x costage .

Upgrade

Wenn Sie die Installationsdatei heruntergeladen und entpackt haben, gehen Sie wie folgt vor:

. $SUPERX_DIR/db/bin/SQL_ENV
cd $COSTAGE_PFAD/upgrade
costage_upgrade.x

Rohdaten aus CAMPUSonline

Zum Bereitstellen der Rohdaten aus CAMPUSonline gibt es zwei Wege:

  • Export in CSV-Dateien
  • Direktes Entladen über ein SuperX Entladescript (JDBC)

Beide Wege werden im folgenden beschrieben. Vorab eine Bemerkung zu Schemata.

Schemata

Unter Oracle ist der Name des Schema auch die Zugangskennung, es hängt also von der Zugangskennung ab, welche Views Sie sehen.

In der CAMPUSonline Datenbank unter Oracle gibt es verschiedene Schemata, die teilweise noch aus der Vergangenheit stammen. Hier eine Übersicht:

  1. Die allgemeinen DWH-Views werden im Schema "CO_INTERFACE_PUBLIC_EXTERNAL" vorgehalten, und haben jeweils das Präfix "px_" (steht für "public external").
  2. Speziell für SuperX gibt es das Schema CO_INTERFACE_PX_SUPERX, das eine Kopie vom obigen Schema darstellt, mit ein paar Ergänzungen speziell für SuperX (z.B. enthält der View sx_leistungen_v eine wichtige Spalte mehr als der View CO_INTERFACE_PUBLIC_EXTERNAL.px_leistungen_v (Prüfungsstatus))
  3. Für ältere Installationen gibt es zwei weitere Schemata, die (unseres Wissens) nur von den Unis Köln und Aachen genutzt werden:
    • Das Schema CO_SUPERX liefert Views der alten SOS-Schnittstelle
    • Das Schema CO_LOC_SUPERX liefert Views aus AMTSTAT und den in NRW genutzten ECTS-Rohdatenview.

Kurz gesagt: Hochschulen mit SuperX sollten das Schema unter 2. nutzen.

Export in CSV Dateien

Wenn Sie aus CAMPUSonline entladen, müssen die Views der DWH-Schnittstelle nach CSV exportiert werden. Auf der Seite http://www.superx-projekt.de/doku/costage_modul/costage_unload.html finden Sie die aktuellen Views in der Spalte "Kurztitel". Beachten Sie, dass alle Spalten in der von CAMPUSonline vorgesehenen Reihenfolge vorliegen.

Der CSV "Dialekt" muss wahrscheinlich an SuperX angepaßt werden. Dazu wird ein Script mitgeliefert, das

  • Ggf. vorhandene HEADER-Zeilen entfernt
  • Spalten-Trennzeichen nach dem in SuperX üblichen "Dach" ändert
  • Zeilenumbrüche in langen Textfeldern maskiert mit Backslash
  • Ggf. vorhandene ISO Codierung nach UTF-8 ändert
  • Wenn eine Datei gar nicht existiert wird eine leere UNL-Datei engelegt, damit der eigentliche SuperX-Konnektor nicht abbricht.
  • Mit dem Script können Sie relativ schnell prüfen ob die Unload Dateien zur Schnittstellenbeschreibung passen.

Das Script liegt im Verzeichnis $COSTAGE_LOAD_PFAD. Es geht davor aus dass die CSV-Dateien im Unterverzeichnis unl liegen. Der Aufruf lautet

costage_prepare_unlfiles.x <Delimiter> HEADER<optional>"

Beispiel:

costage_prepare_unlfiles.x , HEADER

Damit werden CSV Daten mit "," getrennt und Spaltenüberschriften eingelesen. Danach werden sie im UNL-Format mit den richtigen Dateinamen für SuperX gespeichert.

Wenn Sie neben der Umformatierung auch Transformationen benötigen, wird auch ein Script mitgeliefert

rohdaten/csv_unloads2unl.sql

Sie können das Script anpassen an Ihre CSVs und dann mit DOSQL ausführen.

Entladen aus CAMPUSonline

Beim Entladen aus CAMPUSonline (CO) wird ist der Entladeparameter DATABASE ohne Belang, denn das DMBS in CO ist in der Regel Oracle. Daher müssen Sie dem Tomcat-Server in .../webapps/superx/WEB-INF/lib den JDBC-Treiber von Oracle (Dateiname z.B. ojdbc6.jar) mitgeben.

Die Konfiguration wird in den Dateien

rohdaten/COSTAGE_ENV
rohdaten/db-co.properties

vorgenommen, für beide Dateien gibt es Musterdateien mit der Endung ".sam".

Mit der Variablen

connectionName=CO_INTERFACE_PX_SUPERX

definieren Sie das gewählte Schema.

Details zur Konfiguration finden Sie im Kernmodul-Handbuch. Das Entladen starten Sie mit

costage_unload.x

Logmeldungen finden Sie in der Datei

costage_unload.err

Konfiguration

Entladeparameter

Entladeparameter COSTAGE

Nur für den Unload aus CO per JDBC: In der Datei $COSTAGE_LOAD_PFAD/COSTAGE_ENV können Sie folgende Variablen nutzen:


Entladeparameter
Parametername Beschreibung Defaultwert Wertebereich ab Version Parametergruppe Priorität Vorsystem Komponente
VERSION Version des Vorsystems. Wird derzeit nicht ausgewertet. 2 2 Systemparameter 1 0 CO-Basisdaten
COSTAGE_start_st_sem Startsemester Studierende Ab welchem Semester sollen Studierende entladen werden? z.B. 20011 für SS 2001 19911 SEMESTER 0.3 Systemparameter 1 0 CO-Basisdaten
COSTAGE_start_leistungen_sem Startsemester Prüfungen Ab welchem Semester sollen Prüfungen entladen werden? z.B. 20021 für SS 2002 19911 SEMESTER 0.3 Systemparameter 1 0 CO-Basisdaten
COSTAGE_start_bw_sem Startsemester Bewerbungen Ab welchem Semester sollen Bewerbungen entladen werden? z.B. 20021 für SS 2002 19911 SEMESTER 0.3 Systemparameter 1 0 CO-Basisdaten

Entladeparameter Studierende

Für das Entladen der CO-Basisdaten für die Studierenden Komponente können Sie über den neuen Entladeparameter EXTERNAL_SUBJECTS steuern, ob externe Fächer ins Studierenden Modul zu übergeben sind oder nicht. Externe Fächer sind Teilstudiengänge, die nicht an der eigenen Hochschule studiert werden. Standardmäßig sollten diese nicht in der Statistik der jew. Hochschule auftauchen, es gibt aber Anwendungsfälle wo dies von Interesse sein könnte.

Wertebereich
Default ist "false", mit dem Wert "true" werden die Daten entladen.

Konstanten

Teilstudiengänge generieren

Mit der Konstante "COSTAGE_TSG_GENERATE" können Sie geschlossene Teilstudiengänge für einzelne Semester generieren und den Status aus dem MSG übernehmen. Dies betrifft wahrscheinlich nur Hochschulen in Deutschland, die in CO sog. "Mehrfachstudiengänge" (MSG) nutzen, z.B. im Lehramt. Wir wollen das an einem Beispiel illustrieren. Wenn ein/e Studierende/r z.B. Lehramt Sonderpädagogik mit 5 Fächern studiert:

  • Sprachliche Grundbildung
  • Kath. Religion (bis SoSe 2021)
  • Emotionale / soziale Entwicklung
  • Lernen FSP
  • Bildungswissenschaften
  • Ästhetische Erziehung (ab WiSe 2021/2022)

Dabei werden die einzelnen Teilstudiengänge (TSG) ggf. zu unterschiedlichen Semestern beendet. Am längsten läuft der TSG, in dem dann auch die Abschlussarbeit geschrieben wird. Hier ein Screenshot:

costage tsg generate1.png

Die rot umrandeten Zellen sind Semester, in denen in CO kein Datensatz mehr vorhanden ist. Nehmen wir das WiSe 2022/2023: Nur im rechten Fach "Bildungswissenschaft" sowie "Ästhetische Erziehung" (jeweils grün umrandet) zählt das Semester bzw. Fachsemester noch hoch. Wenn wir die Datensätze für eine Fallstatistik zählen würden, dann wären die Studierenden in den rot umrandeten Semester gar nicht mehr vorhanden, obwohl die Studierenden im MSG noch eingeschrieben sind. Für Statistiken auf Fallebene wäre es aber korrekter, wenn die Studierenden im rot umrandeten Semester mit dem jeweiligen Status des MSG und dem letzten Fachsemester des TSG gezählt würden. Um dies zu erreichen, kann SuperX die rot umrandeten Datensätze künstlich generieren. Im Datenblatt wären solche Datensätze auch als "Automatisch generiert" erkennbar. Hier ein Screenshot aus SuperX, wenn die Konstante "COSTAGE_TSG_GENERATE"=1 gesetzt ist:

costage tsg generate2.png

Es gibt neben dem Rückmeldestatus (amtlich)=3 (-> Rückgemeldet) auch einen Studienstatus im TSG, der separat betrachtet werden kann.

attention.svg Nach einer Änderung der Konstante COSTAGE_TSG_GENERATE müssen Sie die Hauptladeroutine neu ausführen.


Hochschul-Repository

Es werden folgende Repository-Variablen vorgegeben:

Repository Variable COSTAGE_STUDENT_FILTER
Welche Studierenden sollen ausgewertet werden

Im folgenden eine Erläuterung. Am Anfang der Inbetriebnahme ist es nützlich, auf einzelne Studierenden/Gruppen einzuschränken. Sie müssen dabei Matrikelnummern oder andere Personmerkmale mit dem Alias "S." für die Tabelle Studierendenstammdaten verwenden. Beispiele für COSTAGE_STUDENT_FILTER:

  • Einzelne Studierende:
S.matrikelnummer in ('1234567','7654321')
  • Ohne Personentyp "Test":
S.personentyp_kb != "TEST'

Die Voreinstellung ist "1=1", d.h. kein Filter.


attention.svg Nach einer Änderung müssen Sie die Hauptladeroutine neu ausführen.

Start der Laderoutine

Wenn die Rohdaten im Ordner

$SUPERX_DIR/db/module/costage/rohdaten/unl/

vorhanden sind, können Sie den Konnektor starten mit

cd $SUPERX_DIR/db/module/costage/
module_etl.x costage .

Die Logausgabe ist Superx-typisch in mehrere Abschnitte eingeteilt, Details siehe Kernmodul-Handbuch.

Weiterverarbeitung im Studierenden Modul SuperX

Wenn die Daten in COSTAGE geladen sind, können sie als Datenquelle für das Studierenden Modul in SuperX genutzt werden. Dazu gehen Sie wie folgt vor:

Setzen Sie in Ihrer SQL_ENV den Wert von SOS_LOAD_PFAD auf COSTAGE:

SOS_LOAD_PFAD=$COSTAGE_PFAD/rohdaten_sos
export SOS_LOAD_PFAD

Im Unterverzeichnis "costage/rohdaten_sos" führen Sie dann das Entladescript

sos_costage_unload.x

aus. Es werden Rohdaten im Unterordner "unl" erzeugt. Diese dienen als Datenquelle für das Studierenden Modul:

cd $SOS_PFAD
sos_update.x
attention.svg Damit das funktioniert müssen die Versionen zueinander passen. Derzeit ist das COSTAGE-Modul 0.3 passgenau mit dem Studierenden Modul 1.3. Ältere Versionen vom Studierenden Modul lassen sich nicht anbinden.