RRZE – Projekte & Prozesse (P&P)

Das Blog der RRZE Stabsstelle "Projekte & Prozesse"

Content

Properties einer Grails-Domänenklasse auslesen

Bei der Deklaration einer Domänen-Klasse in Groovy wird auf die Bean-Notation für Variablen (Variable deklariert als private, zusätzlich Getter und Setter) verzichtet. Stattdessen werden sogenannte Properties definiert, die durch Groovy intern in Java-Beans umgewandelt werden.
[groovy]
class MyTest {
Long id
String val1, val2
}
[/groovy]
Oftmals ist es nötig, die Liste der Properties auszulesen, etwa um ein Objekt in ein anderes zu mappen. Hierfür bietet Groovy die Methode getProperties():
[groovy]
def x = new MyTest()
x.properties.each { key, value ->
println “Property ${key}. ${value}”
}
[/groovy]

Hier tauchen aber plötzlich Properties auf, die in MyType gar nicht definiert wurden, wie version, class, metaClass, constraints! Grails Magic, hier wurden durch das Grails-Framework weitere Properties hinzugefügt!

Wie kommt man nun an die Liste nur der selbst definierten Properties? Die Antwort liegt bei den persistentProperties, die in der Klasse liegen. Diese erreicht man über die DefaultGrailsDomainClass.
[groovy]
def persistentProps = new DefaultGrailsDomainClass(MyTest.class).persistentProperties
persistentProps.each {
println “${it.name}”
}
[/groovy]
Et Voila: Die Liste der persistenten Properties, in aller Regel der selbstdefinierten.

 

Read Properties of a Grails Domain Class

With the declaration of a domain class in  Groovy it is done without a Bean-Notation for variables (variable declared as  private, furthermore Getter and Setter). Instead so called properties are defined which are changed internally into Java-Beans by Groovy
[groovy]
class MyTest {
Long id
String val1, val2
}
[/groovy]
It is often necessary to read out the list, for example to map an object into another. Therefore Groovy offers the methode getProperties():
[groovy]
def x = new MyTest()
x.properties.each { key, value ->
println “Property ${key}. ${value}”
}
[/groovy]

At this points properties suddenly appear which haven’t been defined like version, class, metaClass, constraints! Grails Magic, further properties have been added by the Grails-Framework!

So how do you get the list of the self defined properties only? The answer lies within the persistentProperties, which are within the class. You can reach it via DefaultGrailsDomainClass.
[groovy]
def persistentProps = new DefaultGrailsDomainClass(MyTest.class).persistentProperties
persistentProps.each {
println “${it.name}”
}
[/groovy]
Et Voila: The list of persistent properties, usually the self defined.

Release 2.0.1 der Promovierendenverwaltung online

Seit Donnerstag, 28.07.2011 um 16:00 Uhr ist die Version 2.0.1 der Promovierendenverwaltung online geschaltet. Die wesentlichen Neuerungen zur Version 2.0 sind:

  • Betreuersuche auch per Nachname
    Einzutragende Betreuer konnten bisher nur über ihren Lehrstuhl bzw. Professur ausfindig gemacht werden. Dies führte bei Promotionsbetreuungsberechtigten, die direkt an einer Fakultät oder einem Department aufgehängt waren, dazu dass sie nicht über die GUI gefunden wurden und manuell einzutragen waren. Da die Promotionsbetreuungsberechtigten jetzt auch per Nachnamensuche gefunden werden, verringert sich die manuelle Nacharbeit.
  • Vorhandene Betreuungsbestätigung bei aktiven Promovenden
    Die in Version 2.0 bereitgestellte Dokumentenprüfung hatte noch nicht realisiert, dass bei aktiven Promovenden das Dokument “Betreuungsbestätigung” immer vorhanden ist. Diese Voreinstellung ist jetzt implementiert. Durch den Freischalteprozess ist sichergestellt, dass die vom Betreuer unterschriebene Betreuungsbestätigung eingegangen ist.
  • Möglichkeit, englische Dokumenten- und Schrittnamen zu verwenden
    Nun werden in der Oberfläche und den automatischen E-Mails bei englischen Texten auch englische Dokumenten- und Schrittbezeichnungen verwendet, sofern sie in der Datenbank hinterlegt sind.
  • Verbesserte Telefonnummern der Betreuer
    Die vom Funktionenmanagement (FM) gelieferten Telefonnummern von Promotionsbetreuungsberechtigten waren teilweise durch Hash-Zeichen voneinander getrennt als eine lange Zeichenkette hinterlegt. Man einigte sich darauf, nur die erste erscheinende Telefonnummer zu übernehmen. Alte Telefonnummern in docDaten wurden dementsprechend per SQL-Skript verbessert und neu hinzukommende werden nur bis zum ersten Hash berücksichtigt.
  • Verbesserte E-Mail-Texte
    Die automatisch versendeten E-Mails enthalten nun einen Hinweis auf die automatische Generierung.
  • Gendergerechte Formulierungen
    Wo nötig wurde in der Oberfläche “Promotionsbetreuer/in” geschrieben.
  • Promovenden-Daten-Exporte für Fachanwendungen
    Einige Fakultäten verwalten noch selbst Promovenden mittels Excel-Sheets. Es wurde die Möglichkeit geschaffen, einzelne Promovenden per Knopfdruck in die jeweiligen Excel-Formate zu extrahieren, damit sie nicht manuell in die Fachanwendung eingepflegt werden müssen.
  • Lockerungen von Problemfällen
    Speziell der Problemfall “Studienfach ist ungleich Promotionsfach” führte zu sehr vielen vermeintlichen Problemfällen. Die Problemfälle der technischen Fakultät und der Wirtschaftswissenschaften wurden reduziert, indem Listen von erlaubten Fächerkombinationen vereinbart wurden. Aktuell (Stand 01.08.2011) sind nur noch 348 Problemfälle im System.

Release 2.0.1 of PhD-student management online

 

Since Thursday, 28.07.2011 at 4 pm the version 2.0.1 of the PhD-Student Management is online. The essential improvements ,compared to version 2.0, are:

 

  • Search for advisers also per surname
    so far registered advisers could only be searched via their chair or their professorship. This caused that authorized PhD-advisers, who are directly connected to a faculty or a department, that they couldn’t be found via GUI and had to be added manually. As the authorized PhD-advisers can now be found via surname search, the manual rework can be reduced.
  • Existing adviser affirmations at active PhD-students
    The in version 2.0 provided document test had not yet realized that the document “Adviser Affirmation”is always available for active PhD-students. These pre-adjustments is now implemented. With the activation process it is secured that the from the adviser signed advising affirmation has been handed in.
  • Possibility to use English document- and step-descriptions
    Now in the surface and the automatically generated e-mails  with English texts, English document- and step-descriptions are used, insofar as they are saved in the database.
  • Improved phone numbers of advisers
    The from the function management (FM) delivered phone numbers of PhD-student advisers have, partially separated with hash-signs, been deposited as a long chain of signs. It has been decided, that only the first appearing phone numbers are adopted. Old phone number in docDaten were therefore improved via SQL-script and new added numbers are now incorporated until the first hash appears.
  • Improved e-mail
    The automatically sent e-mails now have a hint for the automatic generation.
  • Gender conform formulations
    Where necessary it is now written “PhD-student adviser (female/male)”.
  • PhD-students’ data export for application
    Some faculties still manage the PhD-students via Excel-sheets by themselves. There is now the possibility to extract PhD-students by pushing the button into the according Excel form, so that they don’t have to be inserted manually into the application.
  • Loosening of problem cases
    Especially the problem case “Subject of studies is not the PhD subject” caused a lot of problem cases. The problem cases of the technical faculty and economic science have been reduced by creating lists with allowed subject combinations. At the moment (date 01.08.2011) there are only 348 problem cases in the system.

Release 2.0 der Promovierendenverwaltung (PV) online

Seit Donnerstag, 30.06.2011 um 14:00 Uhr ist die Version 2.0 der Promovierendenverwaltung online geschaltet. Nun sind alle drei Oberflächen in Grails realisiert, wodurch ein einheitliches Look & Feel zu den anderen Anwendungen der Stabsstelle erreicht wird. Die wesentlichen Neuerungen zur vorherigen Version sind:

  • Auditing
    Es wird detailliert aufgezeichnet, welcher Benutzer welche Aktion anstößt. Das Audit lässt sich über die Admin-Oberfläche ansehen.
  • Editierbare Liste der strukturierten Programme und Löschbarkeit von strukturierten Programmen
    Strukturierte Programme können neu aufgenommen und umgetauft werden. Ein strukturiertes Programm kann gelöscht werden, wenn es noch nicht bei Promovenden belegt ist, ansonsten wird ein Endedatum gesetzt und nicht mehr in der Registrierung angezeigt.
  • Automatische E-Mail bei Aktivierung von Promovenden
    Der von der PV aktivierte Promovend erhält eine automatische E-Mail, die ihn über den IdM-Loginbrief und Aktivierungsprozess informiert. Außerdem ist ein Link zur Client-Anwendung angegeben, über die der Promovend seine Daten einsehen kann.
  • Dokumentenprüfung
    Für jede Promotion sind Schritte (wie Zulassung, oder Eröffnung des Verfahrens) zu erfüllen, die verschiedene Dokumente oder Bescheinigungen benötigen. Die Dokumentenprüfung ist eine generische Lösung, um die benötigten Dokumente anzufordern bzw. abzuhaken.
  • Sichtbarkeit der Berichte
    Berichte können Admin-Gruppen zugeordnet werden und nur für diese Gruppe oder global sichtbar geschaltet werden.
  • Weitere Zustände
    Promotionen können abgebrochen oder erfolgreich abgeschlossen werden. Die abgebrochenen bzw. abgeschlossenen Promovenden sind über die Admin-Oberfläche auflistbar.
  • Automatische Verlängerung der Promovenden im IdM
    Im IdM ablaufende Promovenden werden durch einen Job automatisch verlängert. Ist eine Promotion beendet, wird dieser Mechanismus abgebrochen.
  • Einblick eines Promovenden in seinen Status
    Promovenden können über die Client-Anwendung ihren Status einsehen und den Verlauf der Dokumentenprüfung.
  • Problemfallerkennung
    Es gibt vier Arten von Problemfällen, die bei der Aktivierung eines Promovenden automatisch erkannt werden. Die Admin-Oberfläche erlaubt es, alle Promovenden eines bestimmten Problemfalles aufzulisten und die Problemart eines Promovenden zu ändern oder zu entfernen.

Daneben gab es noch weitere Änderungen an Oberfläche, Businesslogik und Datenhaltung, auch um die Performanz und Usability weiter zu erhöhen.

 

Release 2.0 of the PhD-student management (PV) online

Since Thursday, 30.06.2011 at 2 pm the version 2.0 of the PhD-student management  (Promovierendenverwaltung) is online. Now all of the three surfaces are realized in Grails, which creates a an homogenous Look & Feel with the other applications of the administrative department. The important improvements are:

  • Auditing
    It is more detailed which user triggers which actions. The audit is visible via the admin surface.
  • Editable lists of structured programs and erasability
    Structured programs can now be new gathered and renamed. A structured program can be deleted if it isn’t yet occupied by a PhD-student, otherwise an end date will be set and no longer shown in the registration.
  • Automatic activation e-mail for PhD-students
    The at the PV activated PhD-student receives an automatic e-mail, which informs her/him about the IdM-Loginletter and the activation process. Further there is a link to the client application where the PhD-student can see her/his data.
  • Proof of documents
    Every PhD-students has to take steps (such as admission or opening of the procedure), which need several documents or certification. The proof of documents is a generic solution to request the necessary documents or to check them.
  • Visibility of reports
    Reports can be assigend to admin groups and can only be made visible for these groups or globally visible.
  • Further status
    Graduations can be canceled or successfully finished. The canceled or graduated PhD-students can be listed via the admin surface.
  • Automatic extension of PhD-students in IdM
    The expired PhD-students are automatically extended in the IdM because of a job. If the graduation is fulfilled this mechanism will be aborted.
  • Insight of a PhD-student in status
    PhD-students can see their status and the course of the document proof via the client application.
  • Problem detection
    There are four kinds of problems which are detected automatically during the activation of a PhD-student. The admin surface allows to list every PhD-student with a certain problem and to change or delete the kind of problem or the PhD-student.

Besides there are further changes in the surface, business logic and data management, also to increase performance and usability.

Projektverlauf des Projektes YaCy an Proxy

English Version

Entwicklung des Paketes YaCy

Ziel des Projektes war es eine lokale Suchmaschine zu installieren, welche mit dem Proxy der Universität kommunizieren sollte. Durch die unabhängigkeit der Suchmaschine von anderer Dienste wie Google und Yahoo, eignete sich diese perfekt für den Einsatz an der Universität, da man sich hier unabhängig machen würde. Durch die Peer-to-Peer Technologie, die verwendet werden kann, um den Suchindex mit anderen Teilnehmern zu tauschen, ist diese Suchmaschine ausfallsicherer als große Suchdienste wie Google und Co.. So erfüllen nicht ein paar große Server den Dienst, sondern viele kleine Rechner, eben die der Teilnehmer, mit installierer YaCy Instanz. Der Zweck dieser Suchmaschine war, sich einen, auf die Universität personalisierten, Suchindex mittels des Surfverhalten der User zu erstellen. Um dies zu realisieren, sollte die Suchmaschine mit dem Proxy der Universität kommunizieren. Die Suchmaschine schneidet hierbei, keine benutzerbezogenen Daten mit, sondern wertet die angefragten Seiten, bei denen keine benutzerbezogenen Daten verwendet werden, aus.

Wieso überhaupt ein Paket?

Von der Suchmaschine YaCy war aktuell, zum Zeitpunkt des Projektes kein .rpm Paket für SuSe Betriebssysteme verfügbar, dass den Systemadministratoren genügte (https://build.opensuse.org/package/show?package=yacy&project=home%3Acoprophiliac – enthält keine “SuSe”-spezifischen Anpassungen). Da am RRZE Vorbedingung für die Installation neuer Software ein RPM Paket ist, war es nötig ein eigenes Paket zu bauen.

Die Grundlage für das Bauen des Paketes, entnahm ich einem Spec File aus dem SVN Repository der YaCy Entwickler. Leider war dieses Spec File aus dem Jahre 2006 und wurde bis heute kaum angepasst, da die Entwickler nur noch Pakete für Debian erstellen, aber keine .rpm SuSe Pakete mehr bereitstellen. Somit musste das Spec File, an die Bedürfnisse des Projektes, angepasst werden. Nach der Einarbeitung in das Spec File, wurden in diesem Anpassungenvorgenommen, so dass es schlieslich für die Bedürfnisse des Projektes angepasst war. Hierbei wurden Pfade korrigiert und Befehle angepasst oder nicht mehr benöigtes zu erst auskommentiert und zum Schluss gelöscht. Auch neue Befehle und Definitionen kamen hinzu. Das Init Skript wurde hierfür angepasst. Im Spec File aus dem SVN war auch ein Init Skript für SuSe Betriebssysteme enthalten, dies musste aber korrigiert und angepasst werden. Hier wurden Befehle und Pfade angepasst und nicht mehr Benötigtes entfernt sowie neues hinzugefügt. Zum Schluss wurde das Init Skript aus dem Spec File ausgeschnitten und in eine eigene Datei verschoben die dann nur noch kopiert wurde. Danach war das Paket fertig zum Einsatz auf dem Test Server

Leider kam das Paket nie richtig zum Einsatz, da der für das Projekt sehr wichtige ICAP Support in der aktuellen YaCy Version fehlte bzw. nicht mehr implementiert war. Das ICAP Protokoll hätte die Weiterleitung der HTTP Anfragen der User, an den Proxy-Server weiter an die YaCy Suchmaschine übernehmen sollen. Da aber der Proxy-Server nach langer Arbeit ICAP fähig war, die Suchmaschine YaCy aber das Protokoll nicht mehr an Board hatte und es keinen Patch o.ä. gegeben hat, wurde das Projekt schließlich eingestellt. Durch das Fehlen des ICAP Supports ist eigentlich die wichtigste und zugleich die komfortabelste Funktion der “YaCy an Proxy” Anbindung weggefallen. Dies machte das Projekt, dann leider sehr uninterresant für uns, da wir genau dies gebraucht hätten. Von Seiten der Entwickler der Suchmaschine, kam auf meine Anfrage leider bisher keine Rückmeldung.

Zu guter letzt und damit die Open Source Gemeinde dennoch etwas von meiner Arbeit hat, veröffentliche ich nun das von mir gebaute YaCy Paket, im offiziellen OpenSuse Repository.

Project course of the project YaCy to Proxy

Development of the package YaCy

Aim of this project was to install a local search engine which communicates with the university’s Proxy. Through the independency of search engines of other services like Google and Yahoo, this one is perfect for the use at the university, because you can make yourself independent there. Through the Peer-to-Peer technology, which can be used to switcht the search index of other participant, this search engine is more fail-proof as big search engines like Google and Co.. So not only some big servers fulfill their duty but many smaller computers, said of the participants, with insatlled YaCy instance. The function of this search engine was to create one search index pesonalized for the university through the user’s surf behavior. To realise this project the search engine should communicate with the university’s Proxy. The search engine is here not recording any user related data but evaluates the inquired sites where no user related data is used.

Why a package at all?

There wasn’t a .rpm package for SuSe software of the search engine available at the time of the project which satisfyed the system admins (https://build.opensuse.org/package/show?package=yacy&project=home%3Acoprophiliac – does not contain a “SuSe”-specific adjustment). Because the precondition at the RRZE for the installation of new software is a RPM package, it was neccessary to build an own package.

I extracted the base for the building of the package from a Spec File of the   SVN Repository of the YaCy developers. Unfortunately this Spec File was from 2006 and hasn’t been adjusted until today, because the developers are only developing packages for Debian but don’t provide any .rpm SuSe packages anymore. Therefore the Spec File has to be modified for the needs of the project. After the adaption into the Spec File, adjustments have been made to fulfill the project’s needs.  Therefore first paths have been correted, commands adjusted or not longer neccessarys have been deleted. Also new comands and definitions have been added.   Therefore the Init Skript has been modified. In the Spec File from the SVN, a Init Skript was already included for SuSe software, but it needed modification. Therefore comands and paths again have been adjusted and not longer used ones have been deleted aswell as new ones added. In the end the Init Skript has been cut out from the Spec File and was placed in an own data file, which then has only been copied. After that the package was ready for use on the test server.

Unfortunately the package has never really been used because the for this project very important ICAP Support in the current YaCy version was missing, respectively hasn’t been implemented anymore. The ICAP protocol should have forwarded the user HTTP requests on the Proxy Server to the YaCy search engine.  But because the Proxy Server was, after a long time of work, working with ICAP, but the search engine YaCy did no longer contain the protocol and there hasn’t been a patch or similar, the project has finally been abondend. Because of the missing ICAP Support the rather important and most comfortable function of the “YaCy to Proxy” connection was gone.  This makes the project very uninteressting for us, because we needed exactly this one. There was no reaction from the search engine developers and my requests haven’t been answered yet.

Finally the Open Source community should have some benefits out of my work, therefore I published my work: YaCy Paket, im offiziellen OpenSuse Repository.

 

VV – was ist das?

English Version

Die Veranstaltungsverwaltung (VV) ist ein Modul der Online-Serviceplattform mein campus. Die Plattform dient Studenten und Prüfern der FAU zur Verwaltung von Prüfungen (An- und Abmeldung, Noteneingabe, Noteneinsicht, Transcript of Records) und bildet Bologna-konform die Studiengänge der Universität ab.
Bald nach der Einführung von mein campus wurde deutlich, dass analog zur Prüfungsverwaltung ein ähnliches Modul zur Verwaltung von Veranstaltungen nötig ist. Da ein solches nicht im Lieferumfang der Software existierte, wurde nach ausführlicher Analyse der Anforderungen und der bestehenden Anmeldungs-Insellösungen eine Eigenentwicklung in Angriff genommen.
Ziel war es, Dozenten einen Überblick über die Teilnehmer der Lehrveranstaltungen zu geben. Mit der VV werden Lehrangebote administriert sowie An- und Abmeldungen durchgeführt. Zudem ist eine einfache Kommunikation zwischen Lehrenden und Teilnehmern der Veranstaltung möglich.
Die Entscheidung, UnivIS als etabliertes zentrales Datensystem beizubehalten und Veranstaltungen von dort zu importieren wurde getroffen, um Dozenten die Mühe und fehlerträchtige Arbeit der mehrfachen Eingabe von Veranstaltungsdaten zu ersparen.
Die rege Nutzung des Moduls zeigt, dass in der Tat großer Bedarf an der durch die VV bereitgestellten Funktionalität bestand – ca. 10% aller Veranstaltungen nutzen die neuen Möglichkeiten.

VV – What is it?

The event management (VV) is a module of the online service platform mein campus. The platform is used by students and examiner of the FAU to manage exams (sign on and sign off, entry of grades, transript of records) and displays, conform to Bologna, the study courses of the university.

Soon after its intruduction of mein campus it became clear that analogue to the exam management a similar model for the management of events is needed.
Because software of this kind wasn’t included in the package, a self developed solution was tackled, after extensive analysis of the requirements and the existing isolated sign on application.

The aim was to give the professors an overview of the participants of their lectures. With VV the scope of lectures offered are administrated and sign on and sign off actions are made. Furthermore, an easy communication between lecturers and participants of the lecture is possible.

The decision to keep UnivIS as an established central data system and to import events from there was made to spare the professors further work and a source of errors whilst multiple entry of lecture data.

The active use of this module shows that there is indeed a big demand of the through VV supplied functionality after all – ca. 10% of all events use the new possibilities.

Promovierendenverwaltung – was ist das?

Bis Mai 2010 wurden Promovierende der FAU Erlangen-Nürnberg hauptsächlich mittels Papier und Excel-Listen verwaltet. Die Verwaltung von über 1.000 Promovenden stieß mit diesem Verfahren an ihre Grenzen. Deshalb starteten im November 2009 die Entwicklungen zur Promovierendenverwaltung (PV). Die Software-Entwicklung wurde von der Graduiertenschule der FAU, vertreten durch deren Leiterin Frau Dr. Monica Mayer, in Auftrag gegeben.

Die PV ist eine moderne Webanwendung, mit der die Promotionsregistrierungen und anfallende Daten elektronisch verwaltet werden. Damit wird ein universitätsweiter zentraler Überblick über laufende wie abgeschlossene Promotionen erreicht.

Genaugenommen besteht die PV aus drei Webanwendungen:

  • Die Registrierung, zugänglich für Promovenden, zur Eingabe ihrer Daten und Herunterladen ihrer Betreuungsbestätigung als PDF. Mit Hilfe der Betreuungsbestätigung kann der Betreuer des Promovenden schnell sicherstellen und durch Unterschrift bestätigen, dass die Daten zum Promotionsvorhaben richtig sind.

 

  • Die Administrationsoberfläche zur Einsicht und Änderung der Daten und zum endgültigen Freischalten von Promovenden. Freischalten meint den Promovenden auf Seite der PV zu aktivieren und Personen- und Kontaktdaten an IdM zu liefern. Freigeschaltet wird ein Promovend, wenn er seine vom Betreuer unterschriebene Betreuungsbestätigung bei der Graduiertenschule einreicht.

 

  • Die Client-Anwendung, zugänglich für Promovenden, zur Einsicht in ihre Daten.

Die PV ist an weitere Systeme der FAU angeschlossen:

 

  • Organisationsstrukturmanagement FAU.ORG: Aus FAU.ORG werden Organisationsdaten für Professuren, Lehrstühle, Institute, Departments und Fakultäten bezogen. Diese werden bei der Auswahl der Betreuer in der Registrierung benötigt.

 

  • Identity Management (IdM): Nachdem ein Promovend freigeschaltet wurde, gelangen seine Personen- und Kontaktdaten nach IdM. Wenn der Promovend noch keinen Eintrag im IdM hat, wird dieser angelegt und ein Aktivierungsbrief zugestellt. Nach seiner Aktivierung gelangen seine Zugangsinformationen zurück zur PV. Danach kann sich der Promovend in der Client-Anwendung anmelden.

 

  • Funktionenmanagement (FM): FM liefert an die PV die Personen, die berechtigt sind, Promotionen zu betreuen. Diese können dann in der Registrierung und Administrationsoberfläche unter ihrem Lehrstuhl ausgewählt werden.

Die Administrationsoberfläche bietet konfigurierten Administratoren die Möglichkeit, BIRT (Business Intelligence and Reporting Tools) Berichte hochzuladen und anzusehen. Mit Hilfe dieser Berichte läßt sich ein schneller Überblick über Sachverhalte wie z. B. “Wieviele Promovenden gibt es im Durchschnitt je Betreuer in jeder Fakultät?” gewinnen.

Es gibt ein Rechtemanagement, das vorgibt, welcher Administrator Promovenden suchen, freischalten, Berichte ansehen und Berichte hochladen darf. Ferner gilt, das Administratoren bei der Suche und Berichten nur diejenigen Daten sehen, für die sie konfiguriert sind. Dies ermöglicht es, die Administrierung der Promovenden auch durch Mitarbeiter der dezentralen Promotionsbüros erledigen zu lassen.

Die PV speicherte zum 01.03.2011 die Daten von 1.191 aktiven Promovenden. Sie hat sich zur Verwaltung von Promovendendaten bewährt und soll in Zukunft noch weiter ausgebaut werden.

Wenn Sie sich selbst ein Bild von der PV machen wollen, finden Sie den Direkteinstieg unter https://www.docdaten.uni-erlangen.de/.

Promotion-Management – What is it?

Up to May 2010 PhD-students at the FAU Erlangen-Nuremberg were managed mostly via pen and paper and Excel lists. The management with this method for over 1.000 PhD-students finally reached its limits. Therefore the development of the PhD-student management started in November 2009. The software development was ordered by  FAU’s grad school, represented from the leader Ms Dr. Monica Mayer.

The promotion-management is a modern web application with which the PhD registrations and according data can be managed electronically. With this method an university-wide central overview of running as well as completed promotions can be reached.

In a closer look the promotion management consists of three web applications:

  • The registration, available for PhD-students to enter their data and to download their adviser-confirmation-form as PDF. With the help of the adviser-confirmation-form the adviser of the PhD-student assure and confirm quickly with a signature that the data for the promotion proposition are correct.

 

  • The administration surface to see and change the data and for the final activation of the PhD-student. Activation means that the PhD-student, on the side of the PV, is activated and personal and contact data are delivered. A PhD-student is activated if he/she hands in the from the adviser signed adviser-confirmation at the grad school.

 

  • The client application, available for PhD-students to view their data.

The PV is connected to further FAU systems:

  • Organizational-structure management FAU.ORG: from FAU.ORG organizational data for professors, chairs, institutes, departments and faculties are transferred. These are needed for the selection of advisers during the registration.

 

  • Identity Management (IdM): After a PhD-student has been activated, his/her personal- and contact-data are transmitted to IdM. If the PhD-student doesn’t already have an entry in IdM, one is added for him/her and an activation letter will be sent. After the activation the login data are transmitted back to PV. After that the PhD-student can log into the client application.

 

  • Function Management (FM): FM delivers the persons, who are allowed to advise the PhD-student, to the PV. Those can then be chosen in the registration and administration surface within in one chair.

The administration surface gives the possibility for configured admins to upload and read BIRT (Business Intelligence and Reporting Tools) reports. With the help of those reports, a quick overview of issues, e.g. “How many PhD-students are at every faculty according to each adviser?” can be gained.

There is a right management which dictates which admin is allowed to search for or to activate PhD-students, to view and to upload reports. Furthermore it is considered that admins can only see the data within a search for which they are configured for.  This allows the administration of the PhD-students to be done by the employees of the decentralized promotion office.

The PV already saved data from 1.191 active PhD-students until 01.03.2011. It proved itself for managing the data of PhD-students and is supposed to be further enlarged in the future.

If you want to have an own view of the PV, you can find a direct entry at https://www.docdaten.uni-erlangen.de/.

Release 1.2 der Promovierendenverwaltung (PV) online

English Version
Seit 23.03.2011, 17:00 ist das Release 1.2 der PV online. Es gab folgende nach außen hin sichtbare Veränderungen:

  • Verbesserungen an Usability und Geschwindigkeit

    U. a. wurde in allen drei Web-Anwendungen (Registrierung, Admin-Oberfläche, Client-Anwendung)
    der eigene Menüpunkt Betreuer hinzugefügt und der Workflow, sowie die Performance verbessert.

  • Anpassung an das Universitätsdesign

    Es erfolgte eine Angleichung an das Corporate Design der Universität, so dass docdaten wie andere
    Webanwendungen der Universität aussieht.

  • Vereinheitlichte Betreuer (geliefert vom Funktionenmanagement (FM))

    Die Betreuer eines Promovenden wurden zuvor als Freitext eingegeben. Nun werden die auswählbaren
    Betreuer vom Funktionenmanagement geliefert, so dass nur wirklich an der FAU vorhandene Betreuer
    ausgewählt und abgespeichert werden können. Die als Freitext eingegebenen Betreuer mussten auf FM-Betreuer gematched und migriert werden. Damit verbunden wurde die Obergrenze von drei Betreuern auf beliebig viele erweitert.

  • Promotionsbüro-Mitarbeiter-Login via SSO

    Die Promotionsbüro-Mitarbeiter könne sich via SSO anmelden und sehen nur die Promovenden-Daten,
    für die sie zuständig sind. Sie können Datenänderungen durchführen, sowie Reports betrachten.
    Die Reports werden bisher nur von der Graduiertenschule hochgeladen.

  • Rechtemanagement (sowohl Datenauswahl, als auch Funktionsauswahl)

    Den Admins wurden unterschiedliche, teilweise mehrere Rollen zugeordnet, welche festlegen, ob Reports hochgeladen werden dürfen, betrachtet werden dürfen und ob Promovenden freigeschaltet werden dürfen. Des weiteren wurden die Daten, die ein Admin betrachten und bearbeiten darf auf seine Rolle eingegrenzt.

  • Konsolidierte Fächerliste für das Hauptfach des Promotionsvorhabens

    Es erfolgten Umbenennungen, Löschungen und Neuaufnahmen der auswählbaren Hauptfächer. Auch hierbei mussten Promovenden-Datensätze angepasst werden.

  • Lehrstuhl-Kurzname

    Für jeden Lehrstuhl ist ein Kurzname hinterlegbar, der z. B. in Reports angesprochen werden kann.

  • Betreueraufstellung mit Datenübersicht über jeden Promovenden

    Für jeden Betreuer wurde eine Übersicht über seine freigeschalteten Promovenden erzeugt und für jeden freigeschalteten Promovenden ein Datenblatt. Diese PDFs wurden ausgedruckt und an die Betreuer verschickt.

Daneben erfolgten noch weitere, sorgfältig konzipierte Verbesserungen an der Oberfläche und dem Backend der PV.

Release 1.2 of PhD Management (PV) is online

Since 23.03.2011, 5 PM the release 1.2 of PV is online. There are following changes which are visible to the outside:

  • Improvements on usability and speed

    Among others in all of the three web applications (registration, admin interface, client application) an own menu point advisor added and the workflow aswell as the performance has been improved.

  • Matching to University Design

    There has been a matching to the university’s corporate design to make docdaten look like the other university’s web applications.

  • Unified Advisors (delivered from Function Managment (FM))

    A PhD student’s advisor has former been entered as free text. Now there are chosable advisors delivered from the function management so that only advirors can be chosen and saved who are actually working at the FAU. The advisors entered as free text had to be matched and migrated to FM advisors. Accordingly the maximum of three advisors has been raised to indefinetely.

  • Promotion Office Employees’ Login via SSO

    The promaotion office employees can now login via SSO and only see the PhD students’ data for whom they are responsible for. They can change data aswell as look at reports. The reports have been so far uploaded by the grad school

  • Right Management (aswell as Choice of Data and Choice of Function)

    The admins have been assigned to different, sometimes multiple roles, which determine if reports can be uploaded, read and if PhD students can be activated. Furthermore data which the admin can read and modify have been constricted to his/her role.

  • Consolidated Subject List for Main Subject of PhD Plan

    There have been name changes, deletes and additions of chosable main subjects. Here also the Phd student data had to be adjusted.

  • Department Nickname

    For every department a nickname is now attributed which e.g. can be addressed in reports.

  • Advisor List with Data Overview or every PhD Student

    For every advisor an overview of his/her activated PhD students has been generated and a data sheet for every activated PhD student. These PDF forms have been printed out and sent to the advisor.

There have also been further, thoroughly concipated improvement on the surface and in PV’s backend.

Abkündigung CIT2

English Version
Mit der Ankündigung des Ausscheidens von Herrn Buzek ist es ruhig um CIT2 geworden. Seine Entscheidung wurde unter anderem zum Anlass genommen, das Thema Campus Management kritisch zu überdenken. Inzwischen ist klar, dass die Universitätsleitung zeitnah eine strategische Neuausrichtung beschließen wird.
Der Entscheidung der UL möchte ich nicht vorgreifen, so viel ist aber bereits jetzt klar: CIT2 ist mit der bisherigen Ausrichtung nicht mehr mit der zukünftigen Campus Management Strategie vereinbar.

Daher wurde am 23.02.2011 beschlossen, das das organisatorische Projekt CIT2 aufzulösen und das bestehende Personal sowie die Projekte in die Stabsstelle “Projekte & Prozesse” am RRZE zu integrieren.
Der Betrieb der “mein campus” Plattform liegt bei der Gruppe “Campus IT (CIT)”, geleitet von Frau Andrea Grimm.
Die Stabsstelle wird von Herrn Dr. Peter Reiß als meinem Stellvertreter und mir geleitet.
Die Stabsstelle fungiert zukünftig als Software-Entwicklungsabteilung und wird die Gruppe CIT nach Kräften unterstützen.

Für die im Rahmen von CIT2 geplanten Module sind die Gespräche über Fortführung oder alternative Realisierung bereits angelaufen.
Für die gute und fruchtbare Zusammenarbeit bedanke ich mich bei Ihnen allen!
Ich bin mir sicher, dass wir im Zuge der einzelnen Entwicklungsprojekte wieder das Vergnügen haben werden, zusammen arbeiten zu können, worauf ich mich sehr freue.

Meine letzte Bitte geht in die Richtung der Studierenden: Ich würde mich freuen, wenn wir den Dialog aufrecht erhalten könnten. Über Vorschläge wie dies zu gestalten ist, bin ich sehr dankbar.

Announcement CIT2

 

With the announcement of Mr. Buzek leaving it has become quiet around CIT2. His decision became an occasion among others to critically rethink the topic of campus management. Meanwhile it is clear that the university administration soon will decide a stragetic redirection.
I don’t want to anticipate the decision of the university administration, but this is already clear: CIT2 is with the previous focusing not compatible with the upcoming Campus Management Strategy.

Therefore, on 23.02.2011 it has been decided that the organisational project CIT2 will be dissolved and the pesonnel aswell as the projects will be integrated to the staff unit “Projects & Processes” at the RRZE.
The maintenance of the “mein campus” platform is within the group  Gruppe “Campus IT (CIT)”, managed by Ms. Andrea Grimm. The staff unit is now managed by Mr. Dr. Peter Reiß as my substitute and me.

The staff unit will further function as a software development department and will support the group CIT by all means.

Discussions about continuances or alternative realisations for the in the frame of CIT2 planned modules are already in process.
Thank you all for a good and productive teamwork!

I am sure that due to the individual development projects we will have the pleasure to work together again, to which I am looking forward to.

My last request is tend towards the students: it would be a pleasure to keep up the dialogue. I’m very thankful about suggestions how to create this.

 

Logging von Grails-Applikationen in JBoss

Kurzanleitung:

  • Aus Classloader-Gründen darf die Applikation nicht eine eigene log4j-xxx.jar beinhalten. Diese kann aus dem war-file entfernt werden durch folgenden Eintrag in BuildConfig.groovy:
    [groovy]
    grails.war.resources = { stagingDir ->
    delete(file:”${stagingDir}/WEB-INF/lib/log4j-1.2.16.jar”)
    delete(dir:”${stagingDir}/WEB-INF/classes/org/grails/tomcat”)
    }
    [/groovy]
    (Der Eintrag mit tomcat ist für das Thema hier nicht relevant, entfernt aber unnötige Klassen aus dem war-file.)
  • Die Grails-Log4j-Konfiguration aus Config.groovy wird im JBoss nicht ausgewertet. Daher sind die Einträge in der JBoss-Log4j-Konfiguration ${JBOSS}/server/default/conf/jboss-log4j.xml nachzuziehen.
    Beispiel für Controller:
    [xml]
    <category name=”grails.app.controller.MyController”>
    <priority value=”INFO”/>
    </category>
    [/xml]
    Man beachte auch das “grails.app.controller“-Präfix!
  • Eine weitere Seltsamkeit ist, dass nach einem Undeploy oder Redeploy eines Grails-war-files das Logging des JBoss komplett beendet wird, d.h. absolut nichts mehr in die Logdatei geschrieben wird. Den Grund und eine saubere Lösung dafür habe ich noch nicht gefunden, aber als Workaround ist es möglich, ein touch auf ${JBOSS}/server/default/conf/jboss-log4j.xml auszuführen. Da diese Konfiguration regelmäßig eingelesen wird, erscheinen die Logmeldungen wieder.

Logging of Grails application in JBoss

Brief administration:

  • Because of  Classloader reasons the application can not have an own  log4j-xxx.jar. It can be deleted from the war-file with the following entry in  BuildConfig.groovy:
    [groovy]
    grails.war.resources = { stagingDir ->
    delete(file:”${stagingDir}/WEB-INF/lib/log4j-1.2.16.jar”)
    delete(dir:”${stagingDir}/WEB-INF/classes/org/grails/tomcat”)
    }
    [/groovy]
    (The entry with tomcat is not relevant for this topic, but deletes unnecessary classes from the war-file.)
  • The Grails-Log4j-configuration from Config.groovy is not evaluated in JBoss. Therefore the entries need to be moved in the JBoss-Log4j-onfiguration ${JBOSS}/server/default/conf/jboss-log4j.xml.
    Example for Controller:
    [xml]
    <category name=”grails.app.controller.MyController”>
    <priority value=”INFO”/>
    </category>
    [/xml]
    Keep the “grails.app.controller“-Prefix in mind!
  • Another oddity is that after an undeploy or redeploy of a Grails-war-file the logging of the JBoss will be completely closed,  which means that absolutely nothing is written in the log file. We haven’t found yet the reason and a clean solution for this problem, but as a Workaround it is possible to make a touch to ${JBOSS}/server/default/conf/jboss-log4j.xml. Because this configuration will be importet regularly the logging messages will reoccur.

IP mit Hostnamen ergänzen

English Version

Beschreibung

Es ist schwierig IP-Adressen richtig zuordnen zu können. Erst durch eine Auflösung mit den Hostnamen werden sie verständlich. Aus diesem Grund sollen diese mit den entsprechenden Hostnamen ergänzt werden. Die am RRZE verwendeten Firewallregeln basieren auf IP-Adressen. Um diese leichter zu verstehen und somit bearbeiten zu können müssen sie in Hostnamen aufgelöst werden.
Händisch wäre diese Ergänzung sehr aufwendig. Daher sollte hierfür ein Skript geschrieben werden. Ich habe mich entschieden Perl zu verwenden, da diese Skriptsprache die gewünschte Funktionalität und Flexibilität bietet.

Benutzung

[bash] $ ./ipHostname.pl -i INPUTFILE -o OUTPUTFILE[/bash]

Beispiel

[bash]

$ ./ipHostname.pl -i ipinput.txt -o ipoutput.txt

dali.rrze.uni-erlangen.de/131.188.84.???
web.de/213.165.64.???
mordor.rrze.uni-erlangen.de/131.188.12.???

Hosts saved to file: ipoutput.txt

[/bash]

Das letzte Oktett der IPs wurden aus Sicherheitsgründen zensiert.

Quellcode

[perl]
#!/usr/bin/perl
#
# Inputs IP address from log file and outputs
# host name to screen and file.
#
# Typical usage: ./ipHostname.pl -i inputfile -o outputfile [-s]
#

use Getopt::Long;
use strict;
use warnings;

my $outputfile = 0;
my $inputfile = 0;
my $silent = 0;
my $counter = 0;

#Sind die Optionen, welche Ausgewählt werden könen/müssen
GetOptions (
“o=s” => \$outputfile,
“output=s” => \$outputfile,
“i=s” => \$inputfile,
“input=s” => \$inputfile,
“s|silent” => \&silent,
“h|help|?” => \&syntax);

#Wenn Inputfile oder Outputfile nicht angegeben sind soll die Syntax ausgegeben werden, da beide Parameter Pflichtfelder sind
if ((!$inputfile ) || (!$outputfile )) {
&syntax;
}

#Die Variable $silent wird hier so gesetzt, dass es keine Ausgabe auf der Konsole gibt
sub silent {
$silent = 1;
}

#Hier werden In- und Outputfile geöffnet
open(IP, $inputfile) || warn “Can’t open input $inputfile: $!\n”;
open(HOST, “>$outputfile”) || warn “Can’t open output $outputfile: $!\n”;

print “\n” if !$silent;

#Datei wird zum gesplittet um sie richtig verarbeiten zu können
while() {
my @foo = split(/ /,$_);
my @ip = grep(/\d+\.\d+\.\d+\.\d+/,@foo);
my $ip = $ip[0];
#IPs werden gesplittet und mit gethostbyaddr gecheckt. Anschliessend folgt nur die Ausgabe.
if ($ip) {
my @numbers = split(/\./, $ip);
my $ip_number = pack(“C4”, @numbers);
my ($name) = (gethostbyaddr($ip_number, 2))[0];
if ($name) {
print “$name/$ip\n” if !$silent;
print HOST “$name/@foo”;
} else {
print “This IP has no name: $ip\n” if !$silent;
print HOST “(no host name)/@foo”;
}
}else {
print HOST “@foo”;
}
}
if ($outputfile && !$silent) {
print “\nHosts saved to file: $outputfile\n\n”;
}
close IP;
close HOST;

#Hilfe
sub syntax {

if ($counter == 0) {
print “\nipHostname.pl \n
Usage: ./ipHostname.pl -i inputfile -o outputfile [options]
-i Path to Inputfile
-o Path to Outputfile
-h –help Print this Help
-s Silence
-silent Silence
\n”;
++$counter;
}
}
exit;
[/perl]

IP Supplement with Hostname

Description

It is difficult to assign IP-adresses correctly. Only by breaking up through the hostname they become understandable. Because of this reason the hostname should be added to these. The firewall rules, used at the RRZE, are based on IP-adresses. To make this process easier to understand and therefore easier to work with the hostnames need to be broken up.
These supplements are very time consuming if you do this per hand. Therefore a skript is needed. I decided to use Perl, because this script language offers the needed functionality and flexability.

Usage

[bash] $ ./ipHostname.pl -i INPUTFILE -o OUTPUTFILE[/bash]

Example

[bash]

$ ./ipHostname.pl -i ipinput.txt -o ipoutput.txt

dali.rrze.uni-erlangen.de/131.188.84.???
web.de/213.165.64.???
mordor.rrze.uni-erlangen.de/131.188.12.???

Hosts saved to file: ipoutput.txt

[/bash]

The last octet of the IPs has been cencored because of safety issues.

Source Code

[perl]
#!/usr/bin/perl
#
# Inputs IP address from log file and outputs
# host name to screen and file.
#
# Typical usage: ./ipHostname.pl -i inputfile -o outputfile [-s]
#

use Getopt::Long;
use strict;
use warnings;

my $outputfile = 0;
my $inputfile = 0;
my $silent = 0;
my $counter = 0;

#Sind die Optionen, welche Ausgewählt werden könen/müssen
GetOptions (
“o=s” => \$outputfile,
“output=s” => \$outputfile,
“i=s” => \$inputfile,
“input=s” => \$inputfile,
“s|silent” => \&silent,
“h|help|?” => \&syntax);

#Wenn Inputfile oder Outputfile nicht angegeben sind soll die Syntax ausgegeben werden, da beide Parameter Pflichtfelder sind
if ((!$inputfile ) || (!$outputfile )) {
&syntax;
}

#Die Variable $silent wird hier so gesetzt, dass es keine Ausgabe auf der Konsole gibt
sub silent {
$silent = 1;
}

#Hier werden In- und Outputfile geöffnet
open(IP, $inputfile) || warn “Can’t open input $inputfile: $!\n”;
open(HOST, “>$outputfile”) || warn “Can’t open output $outputfile: $!\n”;

print “\n” if !$silent;

#Datei wird zum gesplittet um sie richtig verarbeiten zu können
while() {
my @foo = split(/ /,$_);
my @ip = grep(/\d+\.\d+\.\d+\.\d+/,@foo);
my $ip = $ip[0];
#IPs werden gesplittet und mit gethostbyaddr gecheckt. Anschliessend folgt nur die Ausgabe.
if ($ip) {
my @numbers = split(/\./, $ip);
my $ip_number = pack(“C4”, @numbers);
my ($name) = (gethostbyaddr($ip_number, 2))[0];
if ($name) {
print “$name/$ip\n” if !$silent;
print HOST “$name/@foo”;
} else {
print “This IP has no name: $ip\n” if !$silent;
print HOST “(no host name)/@foo”;
}
}else {
print HOST “@foo”;
}
}
if ($outputfile && !$silent) {
print “\nHosts saved to file: $outputfile\n\n”;
}
close IP;
close HOST;

#Hilfe
sub syntax {

if ($counter == 0) {
print “\nipHostname.pl \n
Usage: ./ipHostname.pl -i inputfile -o outputfile [options]
-i Path to Inputfile
-o Path to Outputfile
-h –help Print this Help
-s Silence
-silent Silence
\n”;
++$counter;
}
}
exit;
[/perl]