Campusmanagement

Campusmanagement an der FAU

Inhalt

Update: Kurzfristige Wartung mein campus / www.docdaten

Update:

Die Online-Portale „mein campus“ und „www.docdaten“ stehen Ihnen nun wieder in vollem Umfang zur Verfügung.

Wir entschuldigen uns dafür, dass sich die Wartungsarbeiten doch etwas länger als angekündigt gedauert haben.

***

Aufgrund einer kurzfristig erforderlichen Wartung des Datenbankservers der Studierendenverwaltung stehen am  Freitag, 12. August 2011 zwischen 15.00 und 16.00 Uhr das Online-Portal mein campus (https://www.campus.uni-erlangen.de)  und das Online-Portal der Graduiertenschule (http://www.docdaten.uni-erlangen.de) nicht zur Verfügung. Ebenso kann mit den Verwaltungsprogrammen HIS SOS/POS/ZUL/ISY sowie Moveon nicht auf die Datenbank zugegriffen werden.

Das Ende der Wartungsarbeiten wird durch Entfernen der Hinweise auf den jeweiligen Portalen mitgeteilt. Die Verwaltungsmitarbeiter werden per Mail informiert.

Wir bitten um Ihr Verständnis.

Update erfolgreich

Die Wartungsarbeiten an den Datenbanken moveon und sospos, die am heutigen Donnerstag, 28. April 2011, durchgeführt wurden, konnten erfolgreich beendet werden.
Die Datenbank und die darauf basierenden Programme (moveon, SOS, POS, ZUL, HISISY, BZUL, BSOS, mein campus) stehen Ihnen wieder in vollem Umfang zur Verfügung.

Neben dem Update der in der Verwaltung eingesetzten Programme wurde auch die Basissoftware von „mein campus“ einem Update unterzogen. Auch dieses konnte erfolgreich durchgeführt werden. Das Portal steht Ihnen nun wieder zur Verfügung.

Was sich in den einzelnen Komponenten geändert hat, entnehmen Sie bitte den rollenspezifischen Startseiten nach dem Login bzw. den Versionsinformationen.

mein campus 6.0 – was ist neu?

Am 28. April 2011 wird das neue Release von mein campus – Version 6.0 – freigegeben.

Hauptgrund für den Wechsel auf die neue Version war ursprünglich die Einführung des Dialogorientierten Serviceverfahrens sowie dessen angekündigter Start im Mai 2011. Hierfür war ein Update der HIS-Software erforderlich, die die Basis von mein campus darstellt. Trotz der Verschiebung des Dialogorientierten Serviceverfahrens um voraussichtlich ein Jahr wurde die Basis von mein campus auf die neueste Version der HIS-Software aktualisiert.

Dieses Update auf Version 13 stellt zusammen mit dem Update der eingesetzten Datenbanksoftware PostgreSQL auf Version 8.4 die größte Änderung in der neuen Version mein campus 6.0 dar, die nach außen allerdings gar nicht weiter ersichtlich ist. Für den Nutzer von mein campus „bleibt alles beim Alten“.

Neben diesen Änderungen an der „Basis“ wurden auch in den Funktionen für Studierende, Lehrende und Verwaltungsangestellte einige Verbesserungen und Erweiterungen vorgenommen. Nachfolgend finden Sie einen Auszug aus den Versionsinformationen, der Ihnen Neuerungen aus den Bereichen Prüfungsverwaltung und Studierendenverwaltung auszugsweise aufzeigt. Die vollständigen Änderungen können Sie den Versionsinformationen auf mein campus nach dem Release entnehmen.

im Bereich der Prüfungsverwaltung:

  • für Studierende
    • Optimierung des Notenspiegels für Lehramtsstudierende (Fachwechsler)
    • Angleichen der Übersicht angemeldeter Prüfungen in HTML und PDF
    • Anzeige der Übersicht angemeldeter Prüfungen im PDF im Querformat
    • Hinzufügen des Adressblocks mit Adressinformationen des Studierenden
    • Anzeige der Prüfungsart im Notenspiegel für Diplomstudierende
    • Anzeige des gewählten Vertiefungstracks im Masterstudiengang Marketing auf dem Notenspiegel
  • für Prüfer
    • Anzeige der Prüfungsform in der Prüfungsorganisation
    • Verhindern der Erfassung eines Rücktrittsdatums für Wiederholungsprüfungen in der Prüfungsorganisation
    • Verwaltung der Schlüsselqualifikationsprüfungen für Prüfer der Wirtschaftswissenschaften (Erfassung von Teilnehmern)
    • Anzeige der ‚Individuellen Freigabe‘ auf den Teilnehmerlisten
    • Angleichung der Datenfelder in den Export-Dateien (Excel, CSV, PDF) an die Bildschirmdarstellung

im Bereich der Studierendenverwaltung (inkl. Zugriff für exmatrikulierte Studierende):

  • Anzeige des Kennzeichens für Voll- / Teilzeitstudium auf den Bescheinigungen
  • Anpassung der Immatrikulationsbescheinigungen – 4 Bescheinigungen pro DinA4-Seite
  • Anzeige der Studienbescheinigungen bis zum tatsächlichen Exmatrikulationsdatum
  • Anzeige des Geburtsnamens im Falle der Ungleichheit vom Nachnamen
  • Behebung der Fehlanzeige in Vorsemester-Bescheinigungen bei Studienunterbrechern

in den Mitarbeiterfunktionen für Prüfungsamt & Studentenkanzlei

  • Prüfungsamts-Mitarbeiter
    • Erfassung der englischsprachigen Texte für das englischsprachige Diploma Supplement
    • Hinzufügen des Adressblocks mit Adressinformationen des Studierenden
    • Vereinheitlichung der Funktion ‚Notenspiegel‘ für Prüfungsamts-Mitarbeiter
  • Studentenkanzlei-Mitarbeiter
    • Anzeige des Kennzeichens für Voll- / Teilzeitstudium auf den Bescheinigungen
    • Anpassung der Immatrikulationsbescheinigungen – 4 Bescheinigungen pro DinA4-Seite
    • Anzeige der Studienbescheinigungen bis zum tatsächlichen Exmatrikulationsdatum
    • Anzeige des Geburtsnamens im Falle der Ungleichheit vom Nachnamen
    • Behebung der Fehlanzeige in Vorsemester-Bescheinigungen bei Studienunterbrechern

Downtime mein campus am 28.04.2011

Am Donnerstag, 28.04.2011 finden von 08.00 bis 18.00 Uhr Wartungsarbeiten an der Datenbank sowie an den Servern von „mein campus“ statt.
Aufgrund dieser Arbeiten steht Ihnen das Portal „mein campus“ während dieses Zeitraums nicht zur Verfügung.

Neben dem Update der Datenbank-Software und dem Ausbau der Plattenkapazität wird die „mein campus“ zugrundeliegende Software der HIS GmbH auf die neueste Version 13 aktualisiert, um den Datenaustausch mit hochschulstart.de zu ermöglichen.

Das Ende der Wartungsarbeiten wird Ihnen über einen Hinweis auf der Startseite sowie im Blog von Campus IT angezeigt.

Log4j Runtime Reloading

Einleitung
In diesem Blogeintrag werde ich zeigen, wie man die in einer J2EE Umgebung die Log4j Konfiguration von Servlet Container und deplolyten Webapps zur Laufzeit — also ohne Neustart oder Redeploy — neu einlesen kann.

Log4j bietet zu diesem Zweck bereits zwei Methoden an, die jeweils in den Klassen PropertyConfigurator bzw. DOMConfigurator zu finden sind. Diese sind für unsere Zwecke allerdings nicht geeignet (von der Benutzung wird vielerorts abgeraten), da sie einen eigenen Thread starten, welcher die log4j.properties bzw. log4j.xml auf Änderungen hin überwacht.
Das starten von Threads ist in J2EE Umgebungen jedoch verboten, da diese in der Regel nicht ordnungsgemäß beendet werden und zu Speicherlöchern führen.

JBoss und Tomcat7 erkennen Änderungen an ihrer eigenen Log4j Konfiguration bereits von Haus aus. Die Live Konfiguration von Webapps wird aber nicht unterstützt.
Aus diesem Grund und für Tomcat Versionen kleiner 7.0 bleibt die diese Lösung deshalb totzdem sinnvoll.

Weiterlesen

Loghosts mit log4j

Einleitung
Um Logmeldungen auf einem zentralen Loghost zu bündeln werden von Log4j grundsätzlich zwei Lösungsvarianten bereitgestellt.

Ohne die Log4j Welt verlassen zu müssen lassen sich mittes eines Gespanns aus org.apache.log4j.net.SocketAppender auf der Client-Seite und org.apache.log4j.net.SimpleSocketServer auf der Server-Seite LogEvent Objekte übertragen und auf dem Loghost in Dateien schreiben.

Die zweite Möglichkeit nutzt den org.apache.log4j.net.SyslogAppender, um die Logmeldung an einen lokalen oder auch entfernten Syslog Dienst weiterzugeben. Alles weitere wird dann je nach Konfiguration des laufenden Syslog Dienstes erledigt.

Weiterlesen

Fehlermeldung „Fehler in Modul {unknown}“ nach dem Release von mein campus 5.0

Nach dem Release der Version 5.0 von mein campus traten bei zahlreichen Benutzern des Internet Explorers „Fehler im Module {unknown}“ auf. Dieser Blogeintrag wird die Ursachen dieses Fehlers beleuchten.
Die Online-Serviceplattform mein campus integriert unter einer einheitlichen Oberfläche mehrere, eigenständige Anwendungen. Damit diese unterschiedlichen Anwendungen miteinander funktionieren, müssen im Hintergrund verschieden Daten ausgetauscht werden. So müssen beispielsweise alle Anwendungen prüfen können, ob der Benutzer angemeldet ist und die jeweiligen Session-Timeouts müssen synchronisiert werden. Geschieht letzteres nicht, würde ein Benutzer, der die Veranstaltungsverwaltung nutzt, automatisch aus der Prüfungsverwaltung ausgeloggt, da aus Sicht dieser Anwendung zu lange keine Interaktion erfolgte.

Bis zur Version 4.4 von mein campus wurden die Informationen über authentifizierte Benutzer über eine kleines, gemeinsam genutzes Datenbankbackend ausgetauscht. Für die Synchronisation der Sessions wurden im Hintergrund immer auch Aufrufe aller anderen Anwendungen durchgeführt. Dies war für den Benutzer zwar transparent, machte für jede neue Anwendung die integriert werden sollte, aber Anpassungen an allen bisherigen Anwendungen notwendig (und beinhaltet damit auch das Risiko Fehler in den Code einzubauen).

Mit Version 5.0 wurde die notwendige Funktionalität in den Applikationsserver selbst verlagert. Dieser platziert nun ein gesondertes Session-Cookie, das alle Anwendungen lesen können. Damit wird sichergestellt, dass der User authentifiziert ist. Zudem lassen sich über die ID dieser Session alle Anwendungssessions identifizieren und deren Session-Timeouts aktualisieren. Damit entfällt die fehleranfällige Modifikation der bestehenden Anwendungen und neue Anwendungen müssen lediglich noch in die Konfiguration des Applikationsservers eingetragen werden.

Damit das globale Session-Cookie von allen Anwendungen gelesen werden kann, wird dieses mit dem Root-Verzeichnis von mein campus gesetzt. Der Internet Explorer erlaubt das Setzen eines solchen Session-Cookies in der Standardkonfiguration aus Sicherheitsgründen allerdings nicht. Für diesen Fall werden die benötigten Informationen über die aufgerufene URL übergeben. Diese werden, beginnend mit einem Semikolon, an die URL gehängt und können so vom Applikationsserver verwendet werden. Dieses Verhalten funktioniert in den meisten Browsern und mit einer Außnahme auch im Internet Explorer. Wird eine so codierte URL im Meta-Refresh-Tag einer Seite verwendet, betrachtet der Internet Explorer das Semikolon nicht als Bestandteil der URL, sondern als Parametertrenner ( siehe MSDN Library). Daher wurde in solchen Fällen nur eine verstümmelte URL für den Seitenaufruf übergeben, so dass in diesen Fällen kein korrekter Aufruf mehr vorlag. Dies führte zu der oben genannten Fehlermeldung.

Zur Lösung dieses Problems wurden sowohl die Methode zur Encodierung solcher Refresh-URLs, als auch die Methode zu deren Weiterverabeitung so erweitert, dass diese nun auch das globale Cookie unterstützen.

Sollte trotzdem noch jemand auf diesen Fehler stoßen, liegt das mit großer Wahrscheinlichkeit am Aufruf einer falschen Methode zur Codierung solcher URLs. Diese bitte dann einfach an meincampus-support@uni-erlangen.de melden… oder einfach nicht mehr den IE verwenden Wink.

mein campus 5.0 ist online

Am heutigen Mittwoch, 25. August 2010 wurde die neue Version 5.0 der Online-Serviceplattform „mein campus“ freigegeben.
Nachfolgend werden die wesentlichen Änderungen aufgelistet:

  • Ein Tutorial-Video zur Zusammenschaltung der Systeme Univis, „mein campus“ und StudON (nur Prüfer, Dozenten) ist ab sofort verfügbar
  • Benachrichtigungsfunktion über abgeschlossene Prüfungen (nur Studierende): ab sofort kann man sich als Student(in) per E-Mail benachrichtigen lassen, wenn eine Prüfung fertig korrigiert wurde. Die Einstellung findet sich unter dem Menüpunkt „Persönliche Optionen“.
  • Umstrukturierung des Navigationsmenüs: durch die neuen Rollen „Promovierende(r)“ und „Graduiertenschule-Administrator“ wurden neue Menüpunkte notwendig. Die neuen Reiter „Prüfungen“, „Veranstaltungen“, etc haben alle sprechende (und hoffentlich selbsterklärende) Namen bekommen. Eine Übersicht, welche Funktion sich mit „mein campus“ 5.0 unter welchem Menüpunkt versteckt, findet sich in den Versionsinformationen auf „mein campus“
  • Zusammenführung der Menüpunkte „Notenverbuchung“ und „Leistungsverbuchung“ für Prüfer: die Funktionen aus beiden Menüpunkten (die sowieso größtenteils identisch waren) wurden als „Notenverbuchung“ zusammengeführt und stehen unter dem HAuptmenüpunkt „Prüfungen“ zur Verfügung.
  • Einsatz des Webanalyse-Programmes „Piwik“, das uns eine technische Analyse des Clients erlaubt, mit dem auf „mein campus“ zugegriffen wird. Die IP-Adresse des ZUgreifenden wird dabei anonymisiert. Durch den Einsatz von Piwik ist ein weiterer Cookie auf „mein campus“ dazugekommen.
  • Umzug des Webservers auf neue Hardware

Eine komplette Kurzübersicht der neuen Funktionen sowie Fehlerbehebungen finden Sie in den Versionsinformationen auf „mein campus“. Eine erweiterte Dokumentation wird in Kürze auf dieser Webseite zur Verfügung stehen.

Windows-Executables mit Java

Heute hatte ich den seltsamen Fehler, dass das automatische Kopieren unseres Jar-Files cit2-ejb-yaaff-service-1.1.0.jar nach
10_cit2-ejb-yaaff-service-1.1.0.jar per Maven nicht mehr funktionierte. Ich bin mir nicht bewusst, was ich geändert habe, allerdings ist dieser Fehler auch schon bei Ute vor ca. einer Woche aufgetreten.
Die Interpretation der Fehlermeldung war etwa in dem Sinn, dass der Maven-Task gern ein executable hätte, derweil ist copy aber ein in der Shell eingebautes Kommando.
Nach einigem Suchen im Internet nach anderen Maven-Plugins beschloss ich die Sache selbst in die Hand zu nehmen und ein Windows-Executable zu erstellen, aus einem Java-Programm heraus natürlich.
Das Java-Programm war mit Hilfe der Klasse Runtime schnell geschrieben:

import java.io.IOException;

public class Javacopy {

	public static void main(String[] args) {
		if (args.length < 2) {
			System.out.println("Two arguments expected!");
		} else {
			try {
				Runtime.getRuntime().exec(
					new String[] {
					"cmd.exe",
					"/c",
					"copy",
					args[0],
					args[1]
					}
				);
			} catch (IOException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			}
		}
	}

}

Es macht nichts anderes, als die Kommandozeilenargumente an copy weiterzuleiten, welches selbst per cmd /c gestartet wird.
Danach wurde Javacopy.java zu Javacopy.class kompiliert.

Der letzte Schritt zu einem unter Windows lauffähigem exe bestand darin, die Java-Klasse mittels eines Wrappers zu verpacken. Mit JSmoothGen hatte ich schonmal exe für Windows erstellt, dazu war aber eine Konfiguration nötig. Da nur ein .class-File zu verpacken war, suchte ich nach einem Kommandozeilentool und wurde bei Jexepack fündig.
Damit also schnell das exe erzeugt und im Windows-System32-Verzeichnis abgelegt. Nun musste nur noch das neue exe von Maven aus angesprochen werden. Der betreffende Ausschnitt der pom.xml ist dieser:

<plugin>
	<groupId>org.codehaus.mojo</groupId>
	<artifactId>exec-maven-plugin</artifactId>
	<executions>
		<execution>
			<id>copy-jar</id>
			<phase>package</phase>
			<goals>
				<goal>exec</goal>
			</goals>
			<configuration>
				<!--  executable>copy</executable -->
				<executable>Javacopy</executable>
				<arguments>
					<argument>${project.build.finalName}.jar</argument>
					<argument>${deployment.filename}</argument>
				</arguments>
				<workingDirectory>${project.build.directory}</workingDirectory>
			</configuration>
		</execution>
	</executions>
</plugin>

Es wurde lediglich copy durch Javacopy ersetzt (natürlich nur im Windows-Profil 🙂 ).

Tomcat XCS – Cross context sessions

Einleitung
Das mein campus Projekt fasst mehrere eigenständige Webapplikationen unter einer Plattform zusammen. Oft werden die einzelnen Anwendungen sogar von unterschiedlichen Personen eigenständig entwickelt oder kommen von externen Entwicklern. Daher ist es wichtig, die Verschränkung der Anwendungen so gering wie möglich zu halten und so den Grad der nötigen Koordination unter den Entwicklern zu minimieren.
Das fördert die schnelle Entwicklung und erleichtert später die Wartbarkeit des Gesamtsystems.

Weiterlesen