English Version

Der neue Kern von FAU.ORG zeichnet sich durch moderne Technologien, schlankeres Design, verbesserte Modularität und neue Interoperabilität aus. Dieser Artikel stellt die neuen Kernkomponenten aus technischer Sicht vor und gibt einen kleinen Einblick in die Entwicklungsarbeit mit modernen Softwarekonzepten bei P&P.

Ein Dinosaurier in neuem Gewandt

Der neue FAU.ORG Kern setzt auf längst Bewährtes auf: relationale Datenbanken. Mit dem Java Content Repository System Jackrabbit als Persistierungs-Backend hatte man zwar Versionierung und dynamische Schemata, es ließen sich Versionen jedoch nur chronologisch geordnet erzeugen. Anders formuliert war es nicht ohne Weiteres möglich in der Vergangenheit zu arbeiten, insbesondere Änderungen der Vergangenheit auf die Gegenwart auswirken zu lassen.

Daher wurde für den neuen Kern ein Konzept entwickelt, was man aus der Videokodierung kennt. Hier werden nicht für jedes Bild (oder auch Frame) des Videos ganze Bilder (Keyframe) gespeichert, sondern nur in bestimmten Abständen. Alle dazwischen liegenden Frames speichern lediglich Änderungungsinformationen von einem Bild zum nächsten. Damit lassen sich die darzustellenden Informationen verlustfrei komprimieren.
In FAU.ORG findet das gleiche Prinzip seine Anwendung.
Der aktuelle Tag liegt immer als vollständige Information in einem klassischen Relationenschema vor. Dabei wurde schlicht davon ausgegangen, dass die meisten Zugriffe auf die Organisationsstruktur zum aktuellen Tag stattfinden und nicht in der Vergangenheit oder Zukunft. Alle Änderungen an Organisationseinheiten werden lediglich als Änderungsinformationen gespeichert. Im Gegensatz zu einem Videocodec allerdings mit dem neuen und dem alten Wert, damit man Zustände von Organisationseinheiten sowohl zeitlich vorwärts als auch rückwärts berechnen kann. Mit dieser Methode ist es möglich geworden, den Zustand des Organisationsbaums zu jedem beliebigen Zeitpunkt zu berechnen. Der Mehraufwand ist dabei verschwindend gering und liefert durch die Verwendung einer relationalen Datenbank mit bedacht gewählten Indizes gute Performance. Die Implementierung verwendet für den Zugriff auf die Datenbank Hibernate, wodurch weitestgehend objektorientierte Datenbankzugriffe verwendet werden konnten und das darunter liegende Datenbanksystem ohne Weiteres ausgetauscht werden kann. Durch Hibernate lassen sich aus einer Datenbank zu ladende Objekte direkt initialisieren, d.h. das Resultat der Abfrage an die Datenbank muss nicht mehr durch den Programmierer in die objektorientierte Welt übersetzt werden, sondern findet im Hibernate Framework selbst statt. Lediglich für die Berechnung eines Zustands in der Vergangenheit oder Zukunft werden die Attributwerte aus den Änderungstabellen geladen und per Java Reflection als Objekte instanziert.

Viele kleine Helfer

FAU.ORG wird nicht nur als zentrale Instanz die Organisationsstruktur der Universität Erlangen-Nürnberg verwalten, sondern eine Reihe externer, heterogener Systeme mit den verwalteten Daten provisionieren. Da jede Nacht für den aktuellen Tag der oben beschriebene Keyframe berechnet werden muss, werden gleichzeitig alle Änderungsereignisse, die an diesem Tag gültig werden ausgelesen. Diese Änderungen müssen an die externen Systeme verschickt werden. Um das System später leichter um neue anzubindende Systeme zu erweitern, strebt man eine möglichst generische Architektur an. Daher wurde der neue Kern von FAU.ORG ausschließlich als EJB-Komponenten (Enterprise JavaBean) implementiert. Diese Technologie birgt unter anderem die folgende Vorteile in sich:

• Implementierung gegen Schnittstellen als Grundlage der Umsetzung
• losere Kopplung der Komponenten durch kleinere Module, die per Annotationen miteinander verbunden werden können
• leichteres Neu-Deployen von Komponenten on-the-fly im laufenden Betrieb, wenn Aktualisierungen oder Bugfixes vorliegen
• einfachere Transaktionsverwaltung out-of-the-box
• Trennung der Methoden, die durch interne und externe Aufrufe verwendet werden dürfen/können (lokale und entfernte Schnittstelle)
• andere Projekte aus P&P können diese Komponenten einfach nutzen
• problemlose Anbindung an einen Enterprise Service Bus (ESB), über den die Exportprozesse für externe Systeme leichter und generischer umgesetzt werden können

Durch die Verwendung von EJBs und dem ESB können Änderungen einfach als Nachrichten über den Bus verschickt und von den verschiedenen Treibern, die externe Systeme anbinden, entgegengenommen und verarbeitet werden. Weiterhin macht diese Methodik die Konfiguration dieser Prozesse einfacher.

FAU.ORG setzt also auf Altbewährtes, Aufgebohrtes, Brandneues und lose Gekoppeltes und ist damit gerüstet für alle zukünftigen Aufgaben. 🙂

Inside FAU.ORG 2.0

FAU.ORG’s new core is characterized by its use of modern technologies, a slim design, advanced modularity and new interoperability. This article introduces the new core components from a technical point of view and gives some insight into the developing process with modern software concepts at P&P.

A dinosaur with new clothes.

FAU.ORG’s new core uses a proven system: relational databases. While you already had versioning and dynamic schemata with Java Content Repository System Jackrabbit as a persistance backend, versions could only be created in a chronological order. In other words, you could not simply ?work in the past?, changes in the past with an effect on the present were rather difficult.

So a new concept was created for the core, adapted from video coding. Not every picture (or frame) in the video is saved as a complete picture (or keyframe), instead keyframes are only created in certain intervals. All the frames in between store only changes from one picture tothe next. That way, the information to be displayed can be compressed without loss. FAU.ORG implements the same principle.

The current day always contains the complete information in a classic relational schema. It is assumed that most will access the organisational structure on the current day and not at some point in the past or future. When changes are made to the organisational units, only those changes are stored. The difference to a video codec is that both the new and the old value are saved, so that organisational units’ states can be recreated both forward and backwards in time. With this method, it is possible to create the state of the organisational tree at any point in time. The additional workload is negligible, and by using a relational database with cautiously chosen indices, performance is good. The implementation uses Hibernate for accessing the database, so that most database accesses are object oriented, making sure that the basic database system can easily be exchanged. Hibernate allows direct initialisation of objects loaded from the database, i.e. results from accessing the database do not have to be translated into the object-oriented world, but are used directly within the Hibernate Framework. Attribute values are only loaded from the change tables and instanced via Java Reflection as objects when calculating a state in the future or past.

Lots of little helpers

FAU.ORG is not only going to manage the Universiy Erlangen-Nuremberg’s organisational structure as central instance, it will also provision a number of external, heterogenous systems with the managed data. Since the keyframe mentioned above needs to be constructed every night, all change events relevant for the next day are read. These changes need to be sent to external systems. To ease expansion into new systems later, it was aimed to keep the architecture as generic as possible. FAU.ORG’s core, e.g., was implemented exclusively as EJB components. This technology comes with the following advantages:

• Implementation against interfaces as basis for the realisation.
• Loose coupling of components through use of smaller modules, which can be connected via annotations.
• Easier new deploying of components on-the-fly in a running system, when updates or bugfixes are available.
• Easier transaction management out-of-the-box.
• Separation of methods that can be called internally and externally (local and remote interfaces).
• Other P&P projects can use these components easily.
• Easy connection to an Enterprise Service Bus (ESB), so that export processes for external systems can be implemented easier and more generically.

By using EJBs and an ESB, changes can be transferred as messages through the bus, and can be accepted by the various drivers that connect external systems. Furthermore, this method makes configuration of the processes easier.

To sum up, FAU.ORG combines things well tried, finely tuned, brand new and losely coupled, and is thus ready for all future tasks.

English Version

Seit dem 19.01.2010 werden alle Einträge und Änderungen der Organisationsstruktur der Friedrich-Alexander-Universität über die zentrale Webanwendung FAU.ORG online abgewickelt.

Bayerische Hochschulen werden immer stärker in die Pflicht genommen, ihre Zahlungs- und Leistungströme transparent darzustellen. Dies soll durch die Einführung einer bayernweit verbindlichen universitären Kosten- und Leistungsrechnung (KLR) in diesem Jahr erreicht werden, für die wiederum Daten aus den unterschiedlichen Bereichen der Universität zusammengeführt werden. Die KLR setzt eine zentrale Datenbank, die Organisations- und Kostenstellennummern verwaltet voraus. Die technische Implementierung einer entsprechenden webbasierten Anwendung zur Verwaltung der Organisationsstruktur der Friedrich-Alexander-Universität steht im Fokus des Projekts FAU.ORG.

Über die Webanwendung hat derzeit ein noch kleiner Kreis Zugriff auf die Organisationsstruktur der Universität Erlangen-Nürnberg und die Berechtigung zur Datenänderung. Über die E-Mail-Adresse fau.org-support@zuv.uni-erlangen.de eingehende Anfragen und Änderungswünsche werden bearbeitet. Zukünftig werden die Daten automatisiert an die angeschlossenen Systeme übertragen.

Deshalb setzt sich das Projekt FAU.ORG auch in diesem Jahr noch fort. Ein Team aus Mitarbeitern der Zentralen Universitätsverwaltung (ZUV) und des RRZE arbeitet an der Anbindung der Finanz- und Sachmittelverwaltung HIS FSV. Und auch der Identity Management (IdM) Self Service sowie das Informationssystem UnivIS sollen integriert werden. Weitere Systeme folgen nach.

Aktuelle Informationen zur Entwicklung finden Sie hier.

Kontakt

Markus Leber, ORR
Leiter Kanzlerbüro
Markus.Leber@zuv.uni-erlangen.de

Hendrik Eggers
RRZE, Projekte & Prozesse
Hendrik.Eggers@rrze.uni-erlangen.de

Friedrich-Alexander-University introduces online management of organisational structure

Since 19.01.2010, all new entries and changes in the Friedrich-Alexander-University’s organisational structure are conducted online via web application FAU.ORG.

Bavarian universities are increasingly held to make their costs and services transparent. One step in this direction is the introduction of statewide cost and activity accounting (Kosten- und Leistungsrechnung, KLR) for universities. For this, data from various sectors of the university needs to be merged. Using a central database that allows maintenance of organisational numbers and cost units enables KLR to be implemented. FAU.ORG focusses on the creation and technical implementation of a web-based application for managing the Friedrich-Alexander-University’s organisational structure.

So far, a small group of people has access to and permission to change the University Erlangen-Nuremberg’s organisational units. Queries and requests for changes arriving via fau.org-support@zuv.uni-erlangen.de are processed, the resulting data is then transferred to all connected systems.

Project FAU.ORG will continue its work this year. A team consisting of members of the central university management (ZUV) and the RRZE are working on a connection to finance and assets management system HIS FSV. Next in line to be integrated are the Identity Management (IdM) Self Service and the information system UnivIS. Further systems will follow further down the line.

Current information about the development can be found here in the blog.

Contact

Markus Leber, ORR
Head of Chancellor’s office
Markus.Leber@zuv.uni-erlangen.de

Hendrik Eggers
RRZE, Projects & Processes
Hendrik.Eggers@rrze.uni-erlangen.de

English Version

Als zentrale Komponente zur Verwaltung der Organisationsstruktur der Universität Erlangen-Nürnberg hat FAU.ORG nun das Release der zweiten Version erreicht. Seit der ersten Version hat sich hier einiges verändert. Die Benutzeroberfläche weist einige Neuerungen und verbesserte Features auf und die Kernkomponente wurde sogar komplett neu entwickelt. Dieser Blogartikel stellt das neue, bessere, schnellere und einfachere FAU.ORG vor.

Neue Datenhaltung

Die neu entwickelte Kernkomponente von FAU.ORG basiert nun auf einer relationalen Datenbank und bietet die folgenden Möglichkeiten:

• Abbildung der benötigten Informationen in ein geeignetes Entity-Relationship-Schema
• Persistierung der Daten und Änderungen auf diesen Daten (in separaten Relationen)
• Unterstützung der temporalen Semantik für die Speicherungen von Änderungen in der Vergangenheit, Gegenwart und Zukunft
• Volltextsuche in den Daten der Gegenwart

Zunächst wurde aus dem Datenmodell der ersten Version ein Entity-Relationship-Modell (ER-Modell) mit geringen Modifikationen erstellt. Da die meisten Attribute einer Organisationseinheit einwertige Daten enthalten, hätte man nur eine sehr geringe Anzahl an Relationen mit vielen Attributen entwerfen können. Dann wäre es jedoch nicht mehr so einfach gewesen, zusammen gehörende Daten zu gruppieren und später eine feingranulare Zugriffskontrolle auf bestimmte Attributgruppen zu implementieren. Über dies lässt sich mit mehreren Tabellen ein Mechanismus namens Lazy Loading nutzen. Hierbei werden aus der Datenhaltung nicht mehr alle verfügbaren Daten geladen, sondern nur noch das, was der Benutzer gerade benötigt. Das spart Hauptspeicher und ist in den meisten Fällen effizienter.

Neben den Relationen zur Speicherung der eigentlichen Daten, werden in FAU.ORG alle Änderungen von Beginn an auch als Änderungsereignisse in zwei eigenen Tabellen gespeichert. Ein Änderungsereignis bezieht sich auf das Erstellen, Modifizieren und Löschen von Daten einer Attributgruppe. Jedes Änderungsereignis enthält eine Reihe von Änderungseinträgen, die den alten und den neuen Wert des modifizierten Attributs, sowie das Datum der Änderung und das Datum, ab dem die Änderung gültig wird, enthalten. Dadurch ist es möglich in der Zeit zu reisen, da der Zustand jeder Organisationseinheit für jeden beliebigen Zeitpunkt aus dessen Änderungsereignissen berechnet werden kann.

Damit nicht bei jedem Zugriff der Zustand einer Organisationseinheit berechnet werden muss, enthält die Datenbank den Stand der Gegenwart in den eigentlichen Relationen zur Datenhaltung. Diese können schneller ausgelesen werden. Ändert der Benutzer etwas in der Zukunft werden für diese Änderungen lediglich Änderungsereignisse erstellt und gespeichert. Eine eigene Komponente liest jede Nacht die Änderungsereignisse aus, die für den aktuellen Tag gültig werden und setzt diese Änderungen im Stand der Gegenwart um. Damit wird der Zustand in den Tabellen immer up-to-date gehalten. Eine ähnliche Komponente wird in späteren Versionen externe Systeme mit diesen Änderungen provisionieren. Werden die Organisationsdaten in der Vergangenheit geändert, trägt die Datenhaltung diese Änderungen ebenfalls als Änderungsereignisse ein, prüft danach jedoch zusätzlich, ob sich diese Modifikationen auf die Gegenwart auswirken. Dies ist der Fall, wenn das Attribut der betroffenen Organisationseinheit zwischen dem Änderungszeitpunkt der Vergangenheit und dem Stand der Gegenwart nicht noch einmal modifiziert wurde. Die Änderung wird dann dementsprechend in den Relationen der Gegenwart umgesetzt.

Für die Suche wurde in der neuen Datenhaltung wieder eine Volltextindizierung integriert. Das heißt, dass Benutzer nach beliebigen Stichwörtern in allen Attributen suchen können. Die Volltextsuche kann in zukünftigen Versionen so erweitert werden, dass sie auch die Daten der Vergangenheit und Zukunft indiziert.

Neue und verbesserte Features in der Weboberfläche

Die Benutzeroberfläche von FAU.ORG hat ebenfalls einige Neuerungen zu bieten. So lassen sich beispielsweise Kontaktdaten, die Anschrift und die Statistikschlüssel rekursiv ändern. Das bedeutet, dass die Änderungen auch bei allen bzw. ausgewählten Kindern dieser Organisationseinheit umgesetzt werden. Das Verschieben von Einheiten ist nun auch problemlos möglich. Der Benutzer muss lediglich eine neue Organisationsnummer vergeben (dazu mehr weiter unten) und die Einheit wird mit allen Kindern im Baum an die entsprechende Stelle verschoben.

An der Benutzerfreundlichkeit der Weboberfläche wurde ebenfalls gearbeitet. Die Übersichtsseite einer Organisationseinheit enthält nun Sprungmarken, damit Benutzer schneller zur gewünschten Information gelangen. Des Weiteren unterstützt FAU.ORG nun die Anmeldung per SSO. Die wichtigsten Funktionen sind nun direkt aus dem Baum der Organisationseinheiten abrufbar. Des Weiteren zeigt der Baum nun die Langbezeichnung der Einheiten, was die Lesbarkeit verbessert.

Für die Integration der temporalen Semantik wurde in die Hauptseite eine Auswahlbox für das Systemdatum eingebaut. Hier wählt der Benutzer das Datum, in dem das System gerade betrieben wird. Damit entscheidet man also, ob man sich in der Vergangenheit, Gegenwart oder Zukunft arbeiten möchte. Die angezeigten Daten entsprechen dem zum ausgewählten Datum gültigen Stand der Organisationsstruktur. Das gewählte Systemdatum wird in allen Seiten in der kleinen Infobox auf der rechten Seite angezeigt.

Die verschiedenen Zustände (oder Versionen) der Organisationseinheiten lassen sich in der Historienansicht abrufen. Hier wird angezeigt, wer die Änderung erstellt hat, wann die Änderung erstellt wurde und zu welchem Zeitpunkt die Änderung gültig werden soll. Diese Ansicht lässt sich auf bestimmte Attributgruppen und Zeiträume filtern. Die Weboberfläche unterscheidet zudem seit der zweiten Version normale und kleine Änderungen. Eine kleine Änderung bezeichnet Modifikationen an den Daten, die lediglich Schreibfehler oder ähnliches betreffen und keine Wertänderung im eigentlichen Sinne darstellen. Kleine Änderungen lassen sich in der Historienansicht ausfiltern, was der Übersichtlichkeit beiträgt.

Das Erstellen von Brücken wird nun vollautomatisch von der Weboberfläche übernommen. Zur Erinnerung: jede Organisationseinheit besitzt eine Organisationsnummer aus fünf zweistelligen Zahlen. Der Organisationsbaum wird nach diesen Nummern aufgebaut und besitzt daher eine maximale Tiefe von fünf Ebenen. Ein Beispiel: der Hauptknoten des RRZE im Baum besitzt die Organisationsnummer 10 11 12 00 00. Dessen Vaterknoten hat dementsprechend die 10 11 00 00 00. Es kann nun vorkommen, dass ein Knoten einem Vaterknoten zugeordnet ist, der mehr als eine Ebene höher im Baum liegt. Mit anderen Worten überspringt ein Kind damit eine oder mehrere Ebenen. Der Datenmanagement-Lehrstuhl der Informatik besitzt beispielsweise die 15 13 00 16 00 und überspringt die dritte Ebene im Baum. Damit der Baum keine Lücken aufweist, existieren an diesen Stellen besondere Knoten, sogenannte Brücken (hier die 15 13 00 00 00), die als letzte definierte Stelle in der Organisationsnummer eine Doppelnull besitzen. Das Erstellen von Brücken wird in der zweiten Version nun vollkommen automatisch übernommen, sobald eine Brücke benötigt wird. Brücken werden ebenfalls automatisch gelöscht, falls sie keine Kinder mehr besitzt.

Zu den technischen Finessen werde ich im nächsten Blog-Artikel einen tieferen Einblick in die Umsetzung der Version 2 liefern.

RRZE ? Projects & Processes (P&P): An organisational structure in space and time

An organisational structure in space and time

The University Erlangen-Nuremberg’s central component for managing its organisational structure, FAU.ORG, has released its second version. There have been quite a few changes since the first version was originally released. Several improvements have been made to the user interface, improved features have been added and a new core component has been developed. This articles introduces the new, better, faster and easier-to-use FAU.ORG.

New Data management

FAU.ORG’s newly developed core component is now based on a relational database and offers the following:

• Mapping the necessary information in a suitable entity relationship schema
• Both persistance of data and changing the data (in separate relations)
• Supporting temporal semantics for saving changes in the past, present and future.
• full-text search in present data.

First, an entity relationship model (ER-model) was created from version 1’s data model with only a few changes. As most of the organisational units’ attributes only contain single values, a system with only few relations and a large number of attributes would have been possible. This would have impeded both the grouping of data belonging together, and a later implementation of access control for attribute groups. Use of several tables also allows use of a method called Lazy Loading. With this method, not all available data is loaded from data storage, but only the items the user needs at the moment. This saves memory and is more efficient in most cases.

In addition to saving the actual data, all changes in FAU.ORG are saved as change events in two tables. A change event is given when an attribute group is created, modified or deleted. Every change event contains a number of change entries with the old and new value of the modified attribute, date of the change and the date the change becomes active. This makes ?time travel? possible, as the state of every organisational unit at any point in time can be recreated from these change events.

To avoid having to create the state of an organisational unit with every access, the database contains the present state in the relations for data storage, as these can be read faster. If a user changes something in the future, change events are created and saved. A separate component reads these change events every night, selects those that become active the next day and includes them in the present state. That way, the tables are kept up to date. A similar component will later provision external systems with these changes. If organisational data is changed in the pats, data storage also enters these changes as change events, but then goes on to check if the modification affects the present state. That is the case if the attribute of the organisational unit in question is not modified again between the time of change in the past and the present state. Then, the change is included in the present relations.

For searching, the new data storage has been provided with a full-text index. That allows the user to search for keywords in all attributes. This can be expanded in future versions to allow indexing of past and future data.

New and improved features in the web interface

There are several improvements in FAU.ORG’s user interface as well. Recursive changing of contact data, mailing address and statistical keys is now possible, allowing changes for all or selected children of an organisational unit. Moving units is also much easier now. The user only needs to enter a new organisational number (more on this further down), and the unit and all its children are moved to a new place in the tree.

The website is now much more user-friendly. The starting page contains new jump labels, allowing users to get to the wanted information more easily. Furthermore, FAU.ORG now supports SSO login. The most important functions are available directly from organisational unit tree. The tree also uses the long description of units now, improving readability.

For better integration of the temporal semantic, the main page now features an entry box for the system date. Here, the user can chose the date at which the system runs. That way, you can chose whether to work in the past, present and future. The data displayed matches the organisational structure valid at the selected date. The system data chosen is always displayed in an info box on the right side of the screen.

The organisational units’ different states (or versions) can be selected in the history view. Here you can see who entered a change, and at what time that change will become active. Filters for attribute groups and time periods can be used in this view. The web interface also differenciates between normal and small changes. A small change indicates minor modifications to data like fixed spelling mistakes. They do not normally represent real changes to the values themselves. These small changes can be filtered out in the history view.

Bridges are now created automatically by the web interface. A reminder: Every organisational unit has its own organisational number, consisting of five two-digit numbers. The organisational tree is created from these numbers and accordingly has a maximum depth of five levels. E.g.: The RRZE’s main node in the tree is organisational number 10 11 12 00 00. Its father node is therefore 10 11 00 00 00. It is possible, however, for nodes to be attached to a father node that is more than one level higher up the tree. In other words, the child jumps one or more levels. Since the tree cannot have any ?gaps? special nodes, so called bridges, are entered in these places. Their last defined digit ist 00 (in our example 15 13 00 00 00). These bridges are now created automatically when they are needed. They are also deleted automatically if they do not have any children.

For the finer technical details, I will use the next blog article to give some insight into version 2’s implementation.