Administrationshandbuch Modul Bewerber, Zulassungen (ZUL)

Transkript

1 Administrationshandbuch Modul Bewerber, Zulassungen (ZUL) Daniel Quathamer Supportadresse Version 0.2 Stand

2 Sun, Sun Microsystems, Solaris, Java, JavaServer Web Development Kit, JDBC und JavaServer Pages sind eingetragene Warenzeichen von Sun Microsystems, Inc. UNIX ist ein eingetragenes Warenzeichen von X/Open Company, Ltd. Windows, WindowsNT, Win32, VBScript und Office 2000 sind eingetragene Warenzeichen von Microsoft Corp. Linux ist eingetragenes Warenzeichen von Linus Torvalds. Alle weiteren Produktnamen sind Warenzeichen der jeweiligen Hersteller. Dieses Produkt beinhaltet Software, die von der Apache Software Foundation ( entwickelt wurde. SuperX wird unter der deutschen Variante der GPL-Lizenz von dem Land Nordrhein-Westfalen, vertreten durch die FernUniversität Hagen, diese wiederum vertreten durch die Geschäftsstelle der Initiative CampusSource bei der FernUniversität Hagen, Feithstraße 142, D Hagen vertrieben ( Details zu den Lizenzbedingungen finden Sie im Modul-Archiv (/lizenz.txt) oder unter Ergänzende Hinweise finden Sie auf der Projekthomepage unter

3 Inhaltsverzeichnis 1Einführung...4 2Installation des ZUL-Moduls Kurzanleitung Ordnerstruktur und Umgebung des ZUL-Moduls Neuinstallation: Erzeugung der Prozeduren, Schlüssel und Datentabellen Entladen der ZUL-Daten Allgemeines Einrichtung der Entladescripte Entladen unter Postgres oder Informix / UNIX Entladeparameter Entladen unter Windows Entladen aus SOSPOS mit eingeschränkten Datenbankrechten Einladen der Bewerberdaten Historisierung Repository-Variable für ZUL "gültige Bewerbungen" anpassen Validierung HISinOne-APP Konfiguration nach der Installation Konstanten Button Filter Zulassung Prüfprotokoll Bewerbung und Zulassungen Entfernen des ZUL-Moduls Versionshistorie...22

4 4 1 Einführung Das ZUL-Modul wurde von der Firma Memtext entwickelt und basiert auf Postgres / Informix als Datenbanksystem für SuperX. Voraussetzung ist ein SuperX-Kernmodul 4.0 oder höher. 2 Installation des ZUL-Moduls Um das ZUL-Modul zu installieren, muss man zunächst das Kernmodul Version 4.0 oder höher von SuperX oder höher installieren 1. Zunächst entpacken Sie das Archiv zul<<versionsnr>>.tar.gz an der Stelle $SUPERX_DIR. Bei der Installation des ZUL-Moduls werden zentrale Schlüsseltabellen erzeugt und Installationsscripte gestartet. Zunächst müssen die notwendigen Tabellen erzeugt werden. Im Anschluß daran wird eine Hilfstabelle erzeugt, und die Abfragen werden eingespielt. Die Abfragen sind im Benutzerhandbuch dokumentiert. Die Scripte des ZUL-Moduls laufen unter UNIX (AIX, LINUX) und unter Windows mit Cygwin. 2.1 Kurzanleitung Folgende Arbeitsschritte sind notwendig: 1) Entpacken des ZUL-Moduls nach $SUPERX_DIR und Einrichten der Umgebung ($SUPERX_DIR/db/bin/SQL_ENV; ein Muster für ZUL ist im ZUL-Modul enthalten: SQL_ENV_zul.sam). Übertragen Sie die dortigen Angaben nach SQL_ENV, und aktivieren Sie die Umgebung mit. $SUPERX_DIR/db/bin/SQL_ENV 2) Erzeugen des ZUL-Moduls in der SuperX-Datenbank: $SUPERX_DIR/db/module/zul/zul_modul_erzeugen.x Es werden Tabellen, Views etc. erzeugt, und die Masken werden eingespielt. Nach der Installation haben die User der Gruppen Administration oder superx Leserecht auf die Abfragen. 3) Starten Sie Tomcat neu. Wenn Tomcat auf einem separaten Server installiert ist, müssen Sie vorher die Datei $SUPERX_DIR/webserver/tomcat/webapps/superx/WEB-INF/dbforms-config.xml dorthin übertragen. 4) Übernahme der entladenen ZUL-Modul-Daten in spezielle Hilfstabellen: $SUPERX_DIR/db/module/zul/zul_update.x Die Logdatei heisst zul_update.err. 5) Bei Fehlern oder Warnungen im Update wird eine Meldung in der Logdatei ausgegeben. Ansonsten melden Sie sich XML-Frontend neu an, und testen Sie nun die 1 Kernmodul+ Handbücher beziehen Sie über

5 5 Abfragen. 6) Schritt 4 wird bei jedem SuperX-Update wiederholt, sinnvollerweise nach dem Update des SOS-Moduls. Nun muss der Entladerhythmus geplant werden, und die Cronjobs werden eingerichtet. Es gibt eine Musterdatei $SUPERX_DIR/db/module/zul/zul_update_cron.x.sam, benennen sie diese um nach zul_update_cron.x und fügen Sie das Script in die crontab ein. 2.2 Ordnerstruktur und Umgebung des ZUL-Moduls Die jeweiligen Pfade zum ZUL-Modul werden in der Datei $SUPERX_DIR/db/bin/SQL_ENV festgelegt. Übertragen Sie ggf. die Angaben von db/bin/sql_env_zul.sam nach $SUPERX_DIR/db/bin/SQL_ENV, und rufen sie das Script einmal auf mit. $SUPERX_DIR/db/bin/SQL_ENV Die folgende Tabelle zeigt einen Auszug aus der SQL_ENV SUPERX_MODULE=$SUPERX_DIR/db/module; export SUPERX_MODULE SUPERX_ROHDATEN=rohdaten; export SUPERX_ROHDATEN ZUL_PFAD=$SUPERX_MODULE/cob; export ZUL_PFAD ZUL_ERRORDAT=$ZUL_PFAD/ZUL_update.err; export ZUL_ERRORDAT ZUL_ERRORMAIL=$ERRORMAIL #Standard-Mailadr. export ZUL_ERRORMAIL ZUL_LOGMAIL=$LOGMAIL #Standard-Mailadr. export ZUL_LOGMAIL ZUL_BACKUP="false" export ZUL_BACKUP Sie müssen diese Pfade ergänzen, damit die Scripte und cron-jobs laufen. Hinweis für Datenbankserver unter AIX oder anderen Linux / Unix-Derivaten: Beachten Sie, daß die Scripte nur dann lauffähig sind, wenn auf dem Datenbankserver unter /bin die Datei (oder ein Link) bash liegt. Die Scripte von SuperX erwarten die bash-shell Linux-konform im Verzeichnis /bin; wenn dies nicht der Fall ist, sollte die Datei bash z.b. von /usr/bin nach /bin kopiert oder gelinkt werden. 2.3 Neuinstallation: Erzeugung der Prozeduren, Schlüssel und Datentabellen Wir gehen davon aus, daß Sie das Archiv zul<<versionsnr>>.tar.gz in $SUPERX_DIR entpackt haben und die Umgebungsvariablen geladen sind. Die folgenden Schritte brauchen nur einmal ausgeführt zu werden. Unter UNIX: 7) Melden Sie sich als Benutzer superx an und wechseln Sie ins Verzeichnis $SUPERX_DIR/db/module/zul. 8) Geben Sie ggf. dem Skript zul_modul_erzeugen.x (sowie allen anderen Scripten in diesem Verzeichnis) Ausführungsrechte mit: chmod +x *.x. 9) Starten Sie das Skript durch Eingabe von zul_modul_erzeugen.x. Wenn ein Fehler aufgetreten ist, wird dies in der Datei L_zul_installieren.log. protokolliert.

6 6 Neben dem Erstellen der Tabellen und Hinzufügen der Prozeduren und Abfragemasken, werden auch Einträge in den Themenbaum gemacht. Die Masken des Moduls werden dem Sachgebiet "Bewerbung, Zulassung" zugerechnet. Der Themenbaum sollte um das Thema "Bewerbung, Zulassung" erweitert sein. Außerdem erhalten die Administratoren Zugriffsrechte für die neuen Abfragen. Die weiteren Zugriffsrechte für andere User müssen mit Hilfe der Administrations-Masken von SuperX vorgenommen werden: Zugriffsrechte für normale Benutzer Normale Benutzer erhalten einen Zugriff auf die Masken des Moduls, indem Sie dem Benutzer oder einer seiner Gruppen ein Leserecht auf das Sachgebiet 130 "Bewerbung, Zulassung" geben. Hinweise zur Verwaltung der Berechtigung erhalten Sie im SuperX-Administrationshandbuch Kernmodul Entladen der ZUL-Daten Allgemeines Beim Entladen der ZUL-Daten werden Datentabellen und Schlüsseltabellen entladen, um sie nach SuperX zu übernehmen. Für das Entladen gibt es ferner zwei Modi: Das "Pull"-Verfahren und das "Push"-Verfahren. Beim "Pull"-Verfahren wird einer Benutzerkennung auf dem SuperX-Rechner Zugriffsrecht auf die SOSPOS-Datenbank gegeben, und die Daten werden via TCP/IP aus dem Basissystem entladen. Bei APP / HISinOne als Quellsystem ist "Pull" das Standardvorgehen. Beim "Push"-Verfahren werden die Entladescripte auf den SOSPOS-Rechner kopiert und dort von einer Benutzerkennung auf dem SOSPOS-Rechner ausgeführt. Die Rohdaten müssen dann auf den SuperX-Rechner kopiert werden. Dieses Verfahren klappt bei Informix unter Unix problemlos, bei Entladen aus Postgres müsste das komplette SuperX-Kernmodul installiert werden. Am einfachsten ist immer das "Pull"-Verfahren, das mit fast allen Quellsystemen funktioniert und wenig Konfiguration auf dem Quellsystem erfordert. Aufgrund von Sicherheitsvorkehrungen oder Netz-Infrastrukturen wählen aber viele Hochschulen das "Push"-Verfahren. Da derzeit Informix /Unix die gängigste Plattform an Hochschulen ist, ist dies auch kein Problem Entladeparameter Allgemeine Parameter Das Entladen aus dem Vorsystem kann wie folgt parametrisiert werden:

7 Parameter SOURCESYSTEM DATABASE VERSION TRANSACTION_OFF 7 Wert / Erläuterung Quellsystem zum Entladen: derzeit sind die Ausprägungen "sospos" und "hisinone" möglich. Entladedatenbank des Vorsystems: INFORMIX oder POSTGRES Version von HISSOS (Ganzzahlig) Nur für Informix: Wenn Transaktionen eingeschaltet sind und die Protokoll-Tabellen groß sind, dann sollte dieses wie folgt belegt sein. TRANSACTION_OFF="SET ISOLATION TO DIRTY READ;" Entladeparameter für HISinOne Parameter APP_Application_status Wert / Erläuterung Filter für "gültige Bewerbungen", kann konfiguriert werden: Standardvorgabe ist der Wert O.hiskey_id in (2,7) Dies bedeutet daß nur Bewerbungen mit den Antragsstati (Tabelle application_status) Bewerbung vollständig Bearbeitung abgeschlossen entladen werden. Sie können den Filter aber auch ändern, z.b. wenn Sie alle Bewerbungen mit dem Antragsfach- Status (Tabelle requestsubject, Feld k_request_status_id) ungleich "in Vorbereitung" und "zurückgezogen" ändern wollen: (RS.k_request_status_id not in (14,15,16,17) or RS.k_request_status_id is null) Auch weitere Filter sind möglich, es muss eine gültige SQL-where-Klausel sein für den Select, der hier fürs Quellsystem HISinOne dokumentiert ist: Einrichtung der Entladescripte Im Push-Verfahren btw. Unter SuperX könenn Sie mitgelieferte Shellscripte nutzen. Die Entladescripte für die ZUL-Tabellen liegen im Verzeichnis $SUPERX_DIR/db/module/zul/rohdaten und lauten je nach HIS-Systemversion: Am einfachsten ist es, wenn Sie als User superx vom SuperX-Server direkt auf den SOS- Datenbankserver zugreifen und entladen können ("Pull"-Verfahren). Dann ist es sogar egal ob Sie SOS unter Informix f. Win., Informix f. Unix oder Postgres einsetzen; außerdem brauchen Sie die Dateien dann nicht vom SOS-Rechner nach SuperX kopieren.

8 8 Für Postgres ist dies auch deshalb die einfachste Lösung, weil zum Entladen aus Postgres die Bibliotheken des SuperX-Kernmoduls vorhanden sein müssen. Für Informix ist auch das Entladen im "Push"-Verfahren möglich: kopieren Sie den gesamten Verzeichnisinhalt ab $ZUL_PFAD/rohdaten auf den SOS-Rechner, geben Sie dem Script Ausführungsrechte. Die Scripte laufen nur, wenn die entsprechenden Umgebungsvariablen in der Datei ZUL_ENV (im gleichen Verzeichnis, ein Muster liegt vor in ZUL_ENV.sam) korrekt gesetzt sind, benennen Sie die Musterdatei um nach ZUL_ENV und tragen die richtigen Umgebungsvariablen ein, z.b. den Pfad für $INFORMIXDIR. ZUL_ENV Die Umgebung für Entladescripte aus SOS (Auszug) ##Pfad für Entladedaten: ZUL_PFAD=. ; export ZUL_PFAD ##hier muss Unterverzeichnis unl existieren! #Transaktionen abschalten? TRANSACTION_OFF="" export TRANSACTION_OFF In der ZUL_ENV müssen folgende Umgebungsvariablen gesetzt werden (defaults sind bereits vorbelegt, aber hier und da müssen Sie sicher ran): INFORMIXDIR INFORMIXSERVER ONCONFIG CLIENT_LOCALE SERVER_LOCALE Nur für Informix gelten: Home-Verzeichnis von Informix Name des Informixservers Name der onconfig, wenn auf dem SOS-Rechner mehrere Informix-Instanzen laufen Sprachumgebung (wichtig fürs Entladen von Datumsformaten) dito

9 9 Nur für Postgres gelten: PGDATESTYLE Datumsformat "German" PGPORT Port vom Postgres-Server, standardmäßig 5432 PGHOST Hostname oder IP-Adresse vom Postgres-Server PGUSER Benutzerkennung für Postgres-Server (nur Datenbank, nicht Betriebssystem) PGPATH Installationsverzeichnis von Postgres, z.b. /usr/local/pgsql DB_PROPERTIES Pfad zur db-zul.properties-datei mit den Zugangsparametern für SOSPOS unter Postgres LOGGING_PROPERTIES Pfad zur Steuerungsdatei mit den Parametern für das Logging beim Entladen, voreingestellt auf./logging.properties. Normalerweise brauchen Sie hier nichts ändern, wenn beim Entladen Probleme auftauchen, kann man den Level von SEVERE auf INFO oder FINEST ändern, dann werden die konkreten SQLs geloggt. Aber Achtung: wenn keine Fehler mehr auftreten, müssen Sie den Level wieder auf SERVERE ändern, sonst kommen Schlüsselworte in die Logdatei zul_unload.err, die dann bei der Übernahme nach SuperX fälschlicherweise zu Fehlermeldungen führen. Unter Postgres muss für das "Pull"-Verfahren beim Entladen die Datenbankverbindung in der Datei db-zul.properties eingetragen werden (Muster für Postgres liegt bei in dbzul_pg.properties). Dazu laden Sie einmal die Datei ZUL_ENV mit den obigen Parameter, starten den SuperX-Propadmin (siehe Administrationshandbuch Kernmodul) und richten die Verbindung zum SOSPOS-Server ein. Das Kennwort wird verschlüsselt gespeichert. Danach sind die Entladescripte für Postgres ausführbar. Hinweis: Anders als Informix hat Postgres hat eine eigene, vom Basissystem unabhängige Benutzerverwaltung. Daher brauchen Sie den User, den Sie zum Entladen aus Postgres nutzen, nicht auf dem SuperX- oder SOSPOS-Rechner auf Betriebssystem-Ebene einrichten. Sie können also z.b. auf dem SuperX-Rechner zum Entladen aus SOSPOS die Kennung sospos des Postgres- Rechners verwenden. Oder Sie richten in der SOSPOS -Datenbank den Benutzer SuperX ein und geben ihm Leserecht auf die Tabellen sowie das Recht, Tabellen und Stored Procedures anzulegen.

10 ERRORMAIL LOGMAIL MAILPROG 10 Für alle Platformen gelten folgende Variablen: An wen solle eine Logmail verschickt werden, wenn das Entladen nicht geklappt hat? (nur Unix). An wen soll immer eine Logmail verschickt werden Pfad zum ausführbaren Mailprogramm unter Unix, Vorbelegung ist "mail", manche Unixe haben aber auch "mutt". Wenn die Rohdaten nach dem Entladen vom SOS-Rechner auf den SuperX-Rechner kopiert werden sollen, dann werden für das Script zul_copy.x folgende Umgebungsvariablen benötigt: COPY_METHOD Programm, das die Dateien kopiert; rsync und scp sind wählbar. REMOTE_DIR Verzeichnis, in das die Rohdaten auf dem SuperX-Rechner kopiert warden sollen, in der Regel ist dies "/home/superx/db/module/zul/rohdaten" REMOTE_USER Der Unix-Username auf dem SuperX-Rechner, in der Regel "superx". REMOTE_HOST Der Rechnername bzw. die IP-Nr. des SuperX-Rechners. Dann starten Sie das Script zul_unload.x. Wenn es gelaufen ist, müssten die Dateien im unl- Verzeichnis stehen. Prüfen Sie dann bitte, ob dort Dateien mit 0 bytes stehen. Die Logdatei heisst zul_unload.err. Wenn Sie das Verzeichnis nicht gemounted haben, müssen das Verzeichnis unl, die zul_unload.err und die superx.datum dann in das Verzeichnis $ZUL_LOAD_PFAD auf dem SuperX-Rechner kopiert werden, ein Script dafür liegt ebenfalls bei (zul_copy.x) 2. Das Entladedatum wird danach in der Textdatei $ZUL_LOAD_PFAD/superx.datum gespeichert; wenn das Script einen Fehler findet, dann wird das vorherige Datum (in der Datei superx.datum.alt) gesetzt Entladen aus SOSPOS mit eingeschränkten Datenbankrechten Wenn Sie die Datenbank-Rechte beim Entladen aus dem Vorsystem sospos so ändern wollen, dass der Datenbank-User nur auf ausgewählte Tabellen Leserechte besitzt, dann müssen Sie folgende Tabellen mit Leserecht versehen: admission_to_study antr applicant application application_status bew country course_of_study db_version 2 Eine Anleitung zur generellen Planung des Datenaustauschs finden Sie im Administrationshandbuch des Kernmoduls.

11 degree eignbew eignstg eigntxt entrance_qualification entrance_qualification_type examimport examplan examrelation examresult hskonst k_abext k_abint k_admissionstatus k_akfz k_astfr k_astgrp k_bland k_elementtype k_fb k_gender k_hrst k_hzbart k_ikfz k_kzfa k_le k_modulart k_nc k_ncbuch k_ncplaz k_orgunittype k_period_usage k_place_of_studies k_ppruef k_pstatus k_s_var k_schwp k_sperre k_status k_stg k_stort k_stuart k_stufrm k_stutyp k_subject_indicator k_topf 11

12 12 k_verarbkz k_vert k_zulart major_field_of_study mtknr_ldsg nc_rang orgunit period period_usage person quote reactionstatus request requestgroup requestsubject requestsubject_examplan requestsubjectgroup sos sossys subject term_type unit Darüber hinaus benötigt die Entladekennung Schreibrecht auf die Pseudonymisierungstabelle mtknr_ldsg. Bei Postgres wird auch das Schreibrecht auf die zugehörige Sequence benötigt: grant update on mtknr_ldsg_mtknr_ldsg_seq to <<Kennung>> Datenschutz-Parameter Aus Datenschutzgründen werden im Normalfall Daten die auf eine Person schließen lassen nicht übernommen. Falls aber genau dies benötigt wird können Vor- und Nachname und weitere Daten aus dem Vorsystem übernommen werden. In dem folgendem Code Beispiel ist die Übernahme der Personendaten auskommentiert. Je nachdem welche Daten benötigt werden muss das Raute-Zeichen an Anfang der Zeile gelöscht werden und in der Zeile davor, in der der NULL Wert fest zugeordnet wird das Raute-Zeichen am Anfang der Zeile eingesetzt.

13 ZUL_ENV Die Umgebung für Entladescripte aus SOS (Auszug) 13 #Datenschutz-Parameter # "null::char(1)" steht für nicht laden. # Falls das entsprechende Feld geladen werden soll, bitte bei 2ter Zuweisung # das # entfernen. #Nachname: bew_nachname="null::char(1)" #bew_nachname="bew.nachname" export bew_nachname #sortname: bew_sortname="null::char(1)" #bew_sortname="bew.sortname" export bew_sortname #Vorname: bew_vorname="null::char(1)" #bew_vorname="bew.vorname" export bew_vorname #Geburtsname: bew_gebname="null::char(1)" #bew_gebname="bew.gebname" export bew_gebname #Geburtsort: bew_gebort="null::char(1)" #bew_gebort="bew.gebort" export bew_gebort #Geburtsdatum: bew_gebdat="null::char(1)" #bew_gebdat="bew.gebdat" export bew_gebdat 2.4 Einladen der Bewerberdaten Historisierung In ZUL-GX ist es gängige Praxis, Bewerberdaten semesterweise zu löschen. In SuperX können diese Daten weiterhin vorgehalten werden. Dazu werden die Bewerbernummern in Kombination mit dem Semester einer künstlichen Bewerber-ID zugeordnet (Tab. zul_bewnr_bewid), Sie können die Daten also semesterweise in SuperX speichern. Sobald ein jew. Semester aus ZUL entladen wird (d.h. mindestens ein Datensatz für das Semester ist im Unload enthalten), werden die Daten dieses Semesters in SuperX ausgetauscht Repository-Variable für ZUL "gültige Bewerbungen" anpassen Damit auch die gültigen Bewerber richtig angezeigt werden, müssen diese richtig selektiert werden. Die Selektion selbst ist von Hochschule zu Hochschule unterschiedlich. Daher wurde

14 14 ein hochschulspezifischer Filter angelegt, der im ZUL-Modul verwaltet wird. In der Repositoryvariable ZUL_FILTER_AGGR steht eine SQL Bedingung, die wahr sein muss um einen Datensatz als gültigen Bewerber einzustufen. Gehen Sie dazu in das Menü Administration -> Tabelle suchen -> Stichwort "repo" -> dort auf die Tabelle Hochschul-Repository (Liste). Dort suchen Sie den Filter ZUL_FILTER_AGGR Es erscheint ein Bearbeitungsformular:

15 15 Im Auslieferungszustand steht dort: and (B.fehlerkz!= 'F' or B.fehlerkz is null) Möchten Sie anstatt von einer Auswahl lieber eine bestimmte Selektion ausschließen, ändern Sie den Anfang wie folgt: and (B.fehlerkz not in ( Dies könnte dann z.b. so aussehen: and (B.fehlerkz not in ('F','-') or B.fehlerkz is null) An manchen Hochschulen wird auch eine ganz andere Spalte benutzt. Dies ist natürlich auch möglich. Beispiel: and (B.verarbkz in (select apnr from zul_k_verarbkz where uniquename in ('BA','IM','EX','BB')) or B.verarbkz is null) Wichtig ist hierbei nur ('BA','IM','EX','BB'). Diese Kette können Sie beliebig erweitern, kürzen und ändern, je nachdem welche Verarbeitungskennzeichen Sie nutzen. Es muss lediglich der Text zwischen zwei Hochkommata stehen und diese mit Kommas getrennt sein. Nach einer Änderung müssen Sie den ZUL-Update neu starten bzw. eine Nacht warten. Kontrollieren Sie dann die Werte anhand der Abfrage Bewerbungsprozess nach Studiengang.

16 2.4.3 Validierung HISinOne-APP Bei der Datenquelle APP gibt es folgende Formeln für den Status von Bewerbungen: HISinOne 3.x: Ausprägung Einschränkung Formel Bewerbung Status der Bewerbung=Bewerbung vollständig, Bearbeitung abgeschlossen application_status.hiskey_id in (2,7) Zugelassen Zulassungsstatus=zugelassen k_admissionstatus.hiskey_id= 2 Angenommen Reaktionsstatus=Platz angenommen reactionstatus.hiskey_id=4 Eingeschrieben Reaktionsstatus=Immatrikuliert reactionstatus.hiskey_id=10 HISinOne 4.x: Ausprägung Einschränkung Formel Bewerbung Zugelassen Angenommen Eingeschrieben Default: Status der Bewerbung=Bewerbung vollständig, Bearbeitung abgeschlossen. Dies ist konfigurierbar über Entladeparameter APP_Application_status Status des Antragsfachs: Zulassungsangebot liegt vor zugelassen Platz zurückgegeben zurückgestellt ausgeschieden Frist überschritten Immatrikulation beantragt Immatrikulationsantrag in Bearbeitung Immatrikulationsantrag abgelehnt Immatrikuliert Status des Antragsfachs: zugelassen Immatrikulation beantragt Immatrikulationsantrag in Bearbeitung Immatrikulationsantrag abgelehnt Immatrikuliert Status des Antragsfachs: Immatrikuliert Default: application_status.hiskey_id in (2,7) hiskey_id hiskey_id hiskey_id 104

17 Konfiguration nach der Installation Konstanten Nach der Installation können ein paar Schlüssel kontrolliert bzw. angepasst werden. Vorgegeben sind die Schlüssel in der Tabelle konstanten. Damit werden Parameter beim Ladeprozeß gesetzt. Die Konstanten aus dem ZUL-Modul sind: apnr beschreibung Kommentar Von HS im DB- FORM änderbar? ZUL_start_antr_aggr Soll die Berechnung der Hilfstabelle ja Bewerbungen nicht komplett erfolgen, sondern ab einem definierten Semester? Wenn ja, dann geben Sie hier das Semester an (Jahr+1 Stelle "1" / "2" für SS/WS) ZUL_start_antr_cube Soll die Berechnung der FLEDA Tabelle ja Bewerbungen nicht komplett erfolgen, sondern ab einem definierten Semester? Wenn ja, dann geben Sie hier das Semester an (Jahr+1 Stelle "1" / "2" für SS/WS). 6 ZUL_Quellsystem Quellsystem für die Komponente, nein entweder ZUL-GX (5) oder HISinOne (6) (wird im Entladescript gesetzt) 5 ZUL-Version Version vom Vorsystem (wird im Entladescript gesetzt) nein Sie sehen in der ersten Spalte der Tabelle die Vorbelegungen. Vor dem Laden sollten diese Parameter jeweils gesetzt werden. Sie müssen dazu die Tabelle konstanten bearbeiten. Eine Bearbeitungsmaske bekommen Sie, wenn Sie im Browser die Maske Prüfprotokoll Bewerbung, Zulassung aufrufen und von dort den Link "Konstanten" aufrufen. Alternativ können Sie die Konstanten in der Datenbank direkt bearbeiten, z.b. mit isql, psql, dem Access-Frontend oder einem beliebigen anderen Datenbank-Client Button Filter Zulassung Die ZUL-Abfrage hat in der Abfragemaske einen Button namens "Filter Zulassungen". Dieser Button ist vorbelegt mit Beispieleinträgen, bei denen z.b. nach "nur Antragsnummer = 1" gefiltert wird.

18 18 Der Feldinhalt des Buttons kann vom Administrator leicht mit eigenen Werten gefüllt werden. In der Repositoryvariable ZUL_BEW_FILTER steht eine SQL Bedingung, die Wahr sein muss um einen Datensatz als gültigen Bewerber einzustufen. Gehen Sie dazu in das Menü Administration -> Tabelle suchen -> Stichwort "repo" -> dort auf die Tabelle Hochschul-Repository (Liste). Gehen Sie hier zu den Filtern der Art " ZUL" (Vorgehen wie oben). In der Auslieferung gibt es zwei Filter: Filter-ID SQL-Klausel Anzeigename Erläuterung Art des Filters ZUL_FIL- TER_ANT R_1 ZUL_FIL- TER_ANT R_GR_1 antrnr=1 antrnr>1 nur Antragsnummer = 1 nur Antragsnummer > 1 Hauptantrag Hilfsantrag ZUL_BEW_FILTER ZUL_BEW_FILTER Die Hochschule kann diesen Filter jeweils ändern oder sogar ganz eigene Filter erzeugen. Der Feldinhalt kann z.b. in Form einer SQL-Where-Bedingung auf die Tabellen "zul_antr_aggr Z, zul_k_abint A, zul_k_stg S" formuliert. werden. Wenn ein Filter eingebaut wird, muss er in die Tabelle sx_repository eingetragen werden (Neue ID vergeben, Feld art ="ZUL_BEW_FILTER" ), systeminfo_id=130. Nach einer Änderung ist der Filter direkt in der Maske nutzbar (also nicht erst einen Tag später) Prüfprotokoll Bewerbung und Zulassungen Die Maske "Prüfprotokoll Bewerbung und Zulassungen" gibt Warnungen und Informationen zum Ladeprozeß aus. Informationen zu Warnungen gibt der FAQ. Bei der Datenbereinigung sollten Sie immer zunächst die Probleme in Stammdaten bereinigen. Hier die Auswahlmaske:

19 19 Und hier ein Beispielergebnis: 2.6 Entfernen des ZUL-Moduls Wenn Sie das ZUL-Modul nicht mehr benötigen, starten Sie das Script $SUPERX_DIR/db/module/zul/zul_modul_entfernen.x. Dieses Script löscht alle Tabellen, Prozeduren und Abfragen aus der Datenbank, und löscht auch die Einträge im Themenbaum. Danach können Sie den Pfad $SUPERX_DIR/db/module/zul löschen. Wenn Sie nur die Inhalte der Daten- und Hilfstabellen des Moduls löschen wollen (z.b. aus Datenschutzgründen), ohne das ganze Modul zu deinstallieren, können Sie dies mit folgendem Befehl tun:

20 20 DOSQL $SUPERX_DIR/db/module/zul/zul_purge_pg.sql (für Postgres) bzw. DOSQL $SUPERX_DIR/db/module/zul/zul_purge_ids.sql (für Informix) 3 Versionshistorie 0.2(12/2012) Entwickler Daniel Quathamer Verbesserte Datenbankdokumentation für Verfahrensverzeichnisse und Datenschutz-Dokumentation Korrekte Befüllung des Merkmals "Status des Bewerbers" bei Datenquelle ZUL-GX Maske Bewerbungsprozeß nach Studiengang neue Grafik Diagramm über Bewerbungsprozess" Neuer Datenblattbericht "Bewerbungen und Zulassungen Datenblatt" inkl. Beispiel-Jasper- Report Neue Maske "Prüfprotokoll Bewerbung, Zulassung" inkl. Bearbeitungsformular für Konstanten und Filter 0.1rc2 (02/2011) Entwickler Daniel Quathamer Performance des zul_updates deutlich verbessert. Auslieferungszustand des Filters ZUL_ANTR_AGGR geändert. Möglichkeit der Historisierung von Bewerberdaten geschaffen