Dokumentation. Software Quellcodedokumentation

Transkript

1 Dokumentation Software Quellcodedokumentation Alexandria ist eine Open-Access Repository Software, welche initial am Institut für Medien und Kommunikationsmanagement an der Universität St.Gallen entwickelt wurde. Die Entwicklung der Repository Software startete im Jahr 2004 und hat sich über die Jahre zu einer vollständig Open-Access kompatiblen Archiv-Software entwickelt. Seit dem Jahr 2009 wird die Software von der magazine.one UG weiterentwickelt, einer Ausgründung aus dem Institut für Medien und Kommunikationsmanagement an der Universität St.Gallen. Das vorliegende Dokument beschreibt die Spezifikation und Softwarearchitektur der Alexandria Plattform. Das Dokument ist hierbei in die folgenden acht Abschnitte untergliedert: EINLEITUNG ARCHITEKTUR BIBLIOTHEKEN QUELLCODE DATENBANK KONFIGURATION WARTUNG CHANGELOG Grundlagen und Quellcodestandards Architektur und Aufbau des Quellcodes Eingebundene Fremdbibliotheken Strukturierung des Quellcodes und wichtige Elemente Datenbankstruktur der Software Konfiguration und Erweiterungen des Quellcodes Anleitungen zur Wartung des Quellcodes Version und Autoren der Dokumentation EINLEITUNG Die Entwicklung der Software begann im Jahre 2004 am Institut für Medien und Kommunikationsmanagement im Auftrag der Universität St.Gallen. Seit dieser Zeit wurde die Software stetig weiterentwickelt. Seit dem Jahr 2009 wird diese Weiterentwicklung und Bereitstellung von der magazine.one UG übernommen. Die Entwicklung orientiert sich hierbei an der erfolgreichen LAMP Open- Source Architektur bestehend aus dem Linux Betriebssystem, dem Apache Webserver, der MySQL Datenbank und der PHP Programmiersprache. Nichts desto trotz unterstützt die Software eine Vielzahl von Betriebssystemen wie Windows, BDS oder MacOSX. 1

2 Der Softwarequellcode wird anhand zahlreicher Open Source Entwicklungsstandards entwickelt, um eine zuverlässige und einfache Weiterentwicklung gewährleisten zu können. So wurde besonders Wert auf die sorgfältige Dokumentation und Strukturierung gelegt. Insbesondere die Entwicklungsstandards der PHP PEAR Community fanden Anwendung. Nachfolgend sollen diese daher kurz vorgestellt werden, um eine Anleitung für die Erweiterung bzw. Anpassungen des Quellcodes zu geben. Kontrollstrukturen, Funktionsaufrufe & Funktionsdefinitionen Die PHP PEAR Qualitätsstandards geben direkte Vorgaben für das Formatieren und Gestalten des Quellcodes und seiner Funktionen bzw. Klassen. Genaue Angaben dazu sind unter folgender Adresse zu finden Kommentare Die Kommentierungen innerhalb des Quellcodes entsprechen den Konventionen der Pear Community und damit der standardisierten Vorgehensweise der PHP Community. Weitere Informationen hierzu können Sie der PHPDoc Webseite entnehmen: Namenskonventionen Entsprechend den PHPDoc und PHP PEAR Konventionen ist die Formatierung von Bezeichnern vorgenommen. Klassen werden hierbei immer mit beschreibenden Namen versehen und Abkürzungen vermieden. Sie sollten immer mit einem Großbuchstaben beginnen und ähnlich den PEAR Klassen die Hierarchien reflektieren. Funktionen starten grundsätzlichen mit einem Kleinbuchstaben und werden nach dem "bumpy case" oder "camel caps" Syntax beschrieben: ARCHITEKTUR In der Software sind die verschiedenen Schichten, wie die Präsentationsschicht und Datenbankschicht, strikt voneinander getrennt. Die unterschiedlichen Schichten sind in der nachfolgenden Abbildung aufgeführt. Jede der Schichten baut hierbei auf eine zentrale Bibliothek bzw. Technologie auf. 2

3 Präsentationsschicht (Smarty Template Engine) Renderingschicht (XSLT Rendering) Sprachschicht (PEAR Translation Bibliothek) Cachingschicht (Anwendungsmodul) Applikationsschicht Authentifizierungsschicht (LiveUser) Loggingschicht (PEAR Log) Datenbankschicht (PEAR DB) Nachfolgend werden diese einzelnen Schichten im Detail beschrieben und deren technologische Rahmenparamenter erläutert. Präsentationsschicht Die Präsentationsschicht nutzt zur Darstellung der Inhalte die Smarty Template Engine (siehe Abschnitt Bibliotheken) und die CSS Versionen 1 und 2. Aktuell werden der Internet Explorer und der Firefox Browser unterstützt. Die Stylesheets sind im styles Verzeichnis zu finden, welches sich in print und screen Unterverzeichnisse unterteilt. Diese beherbergen die verschiedenen Stylesheets für die Anzeige im Browser und die Darstellungsweise beim Druck der Seite. Es finden sich drei verschiedene Stylesheet Spezifikationen in unterschiedlichen Dateien. Nachfolgend sind diese aufgelistet und ihre Funktion beschrieben: default.css form.css layout.css - Generelle Formatierungen und Anpassungen der Darstellung - Formatierung von Formularelementen - Spezifikationen des Layouts Die Smarty Templates, welche für die Erstellung der HTML Webseiten verantwortlich sind, finden sich im templates Verzeichnis. Jedes Modul nutzt seine eigenen Templates. Hierbei gibt es unterschiedliche Templates, wobei z.b. ein Template für die Darstellung von Tabellen und ein anderes wiederum für die Darstellung von Formularen zuständig ist. Zu beachten ist, dass die von den Modulen (siehe Applikationsschicht) aufgerufenen Templates zur Darstellung des Modulinhaltes in verschiedene übergeordnete Templates eingebettet sind. Ausgangspunkt der Darstellung ist immer der Aufruf des default.tpl Template. Alle weiteren inkludierten Templates lassen sich dort einsehen. Die Modul- 3

4 spezifischen Templates werden dann im core.tpl eingebunden. Modultemplates unterscheiden sich von übergeordneten Templates durch den vorangestellten Unterstrich im Modulnamen. Renderingschicht Die Renderingschicht der Software ist für die Umwandlung der XML Daten für die verschiedenen Ausgabeformate zuständig. Als Haupttechnologie kommt hierbei XSLT zum Einsatz. Im xsl_def Verzeichnis finden sich zahlreiche Ausgabeformate. Weitere Information zu XSTL finden sich auf der W3C Webseite: Sprachschicht Die Sprachschicht der Software ist ähnlich der Präsentations- und Renderingschicht vom eigentlichen Quellcode abstrahiert. Die im Quellcode verwendeten Identifikationsstrings für Begriffe oder Texte werden gegen die in der Datenbank vorgehaltenen Übersetzungen aufgelöst. In der Datenbanktabelle lang_translation sind die entsprechenden Übersetzungen gespeichert. Die Datenbanktabelle lang_configuration dient der Konfiguration der unterschiedlichen unterstützten Sprachen. In der Software sind standardmäßig englische, deutsche, italienische und französische Sprachunterstützung enthalten. Weitere Sprachen können bequem hinzugefügt oder entfernt werden. Weitere Anpassungen, wie die Konfiguration der Standardsprache, können in der Konfigurationsdatei vorgenommen werden (siehe Installationsdokumentation). Cachingschicht Die Cachingschicht wird durch eine zentrale Caching-Schnittstelle gesteuert. Diese Schnittstelle stellt verschiedene Optionen zur Verfügung. Einerseits kann die Zeitdauer, die ein Objekt im Cache erhalten bleiben soll, angegeben werden, sowie der Speicherpfad unterhalb des tmp Verzeichnisses. Grundsätzlich werden alle Caching-Objekte unterhalb dieses Verzeichnisses gespeichert. Ferner gibt es die Möglichkeit zwischen dem File und dem Function Caching-Containern zu wählen. Der File Caching-Container speichert komplette Dateien zwischen, wohingegen der Function Caching-Container das Ergebnis von Funktionsaufrufen zwischenspeichert. Die Cachingschicht basiert hierbei auf dem PEAR Cache Projekt und nutzt dieses um Objekte im Filesystem zu speichern. Diese Caching-Schnittstelle wird grundsätzlich global zu Verfügung gestellt und in den unterschiedlichen Klassen und Modulen verwendet. Die Caching- Schnittstelle im cache Unterverzeichnis im classes Verzeichnis stellt hierbei das globale Interface zur Verwendung der Cachingfunktionalität zur Verfügung. 4

5 Applikationsschicht Die Applikationsschicht unterteilt sich in drei verschiedene Ebenen. Zu unterscheiden ist zwischen initialen Modulen, Basisklassen und Anwendungsmodulen. Zunächst wird bei einem Seitenaufruf standardmäßig die index.php Datei aufgerufen. Dies geschieht durch die in der.htaccess Datei spezifizierten Rewrite Regeln im Stammverzeichnis der Software. Folgend werden die weiteren Schichten durch das im core Verzeichnis vorhanden init.inc.php Skript initialisiert und die dafür notwendigen Module aufgerufen. Diese Module sind wiederum unterhalb des modules Verzeichnisses verortet und greifen auf die im classes Verzeichnis bereitgestellten Basisklassen zurück, um den Seiteninhalt an die Rendering- und Präsentationsschicht zu übergeben. Diese Basisklassen greifen wiederum teilweise auf die von den entsprechenden PEAR Klassen bereitgestellten Funktionen zurück. Die Erweiterung der Software um neue Module sollte folglich unterhalb des modules Verzeichnisses stattfinden. Authentifizierungsschicht Die Software unterscheidet zwischen internen und externen Personen. Beide Rollen unterscheiden sich im Zugang zur Plattform. Ausschließlich interne Personen können sich an der Plattform anmelden. Die Überprüfung der Zugangsdaten erfolgt anhand der in der Datenbank gespeicherten Zugangsdaten oder gegen eine externe Authentifizierungsquelle. Diese externe Authentifizierungsquelle kann zum Beispiel ein LDAP Baum oder auch eine SOAP Schnittstelle sein. Sollte hierbei die externe Authentifizierungsquelle einmal nicht verfügbar sein, so ist es für die bereits bestehenden Nutzer trotzdem möglich sich weiterhin anzumelden. Ferner besteht die Möglichkeit weitere Authentifizierungscontainer hinzuzufügen bzw. den bestehenden LDAP Authentifizierungscontainer auszutauschen. Eine komplette Liste der unterstützten Authentifizierungsquellen findet sich auf der PEAR Auth Projektwebseite: Bei der ersten Anmeldung an der Plattform wird automatisch ein interner LiveUser Nutzeraccount angelegt, welcher von der externen, konfigurierten Authentifizierungsquelle übernommen wird. Ferner ist eine Unterstützung für die automatische Deaktivierung von Nutzeraccounts implementiert. Sollte ein Nutzer aus einem externen Authentifizierungscontainer entfernt worden sein, so wird dieser Nutzer automatisch deaktiviert und sein Personenprofile aus der Datenbank entfernt. Die nachfolgende Abbildung verdeutlicht die beschriebene Vorgehensweise zum Authentifizierungsprozess unter Verwendung eines externen LDAP Authentifizierungscontainers. 5

6 Nutzer ist eingeloggt Login Fehler Ja Nein Initiale Module Ja Ist der Nutzer eingeloggt? LDAP & Datenbank Authentifizierung Nein Datenbankabfrage ob Nutzer bereits existiert und ob das Passwort in der Datenbank dem eingegebenen entspricht. Basisklassen LiveUser Eine weiterführende Dokumentation findet sich hierzu im Quellcode in der auth-perm.class.php im authentification Unterverzeichnis des classes Verzeichnisses. Loggingschicht Die Software enthält eine eigene Logging Schicht, die es ermöglicht Fehlermeldungen sowohl auf dem Bildschirm anzuzeigen, per zu versenden oder in eine Logdatei zu schreiben. Die Bildschirmausgabe unterscheidet hierbei zwischen einer klassischen Ausgabe auf dem Bildschirm und einer Integration in das Firefox Browser Tool Firebug (siehe Installationsdokumentation). Diese Funktionalität wird zentral verwendet und beinhaltet neben den Fehlern der Applikationsschicht auch Fehlermeldungen der Datenbankschicht und sämtlichen weiteren verwendeten PEAR Bibliotheken. Die Ausgabe von Fehlermeldungen erfolgt in die syslog.log Datei, welche sich im log Verzeichnis befindet. Die Logging Klasse im init Unterverzeichnis des classes Verzeichnis bildet wiederum den Zugangspunkt zur abstrahierten Loggingschicht unter Verwendung des PEAR Log Paketes. Weitere Informationen finden sich auf der PEAR Log Webseite: 6

7 Datenbankschicht Die Abstraktion der Datenbankschicht ist unter Verwendung des PEAR DB Paketes umgesetzt worden. Die PEAR DB ermöglicht hierbei die Verwendung unterschiedlicher Datenbanken. Informationen zum PEAR DB Packet finden sich auf der Webseite des PEAR Projektes Zu beachten ist, dass das PEAR DB Paket durch das PEAR MDB2 Paket abgelöst wurde, jedoch aktuelle Sicherheitspatches weiterhin eingespielt werden. Ausschließlich neue Features werden nur ins neue MDB2 Paket aufgenommen. Hinweis: Durch die Verwendung der neuen XML/XPath Funktionalitäten von MySQL muss vor der Nutzung einer anderen Datenbank als MySQL ein intensiver Test der Software durchgeführt werden. Weitere Information zu den XML/XPath Funktionalitäten finden sich im Abschnitt zur Datenbank in diesem Dokument. BIBLIOTHEKEN Die Software baut auf verschiedenen externen PHP Bibliotheken auf. Zu diesen gehören die Pear Bibliotheken, die Smarty Template Engine und das LiveUser Authentifizierungsframework, wobei die benötigten PHP PEAR Bibliotheken bei der Installation der Software automatisch installiert werden. Hingegen sind die Smarty Template Engine und das Authentifizierungsframework LiveUser feste Bestandteile des Quellcodes. Beide Bibliotheken sind unterhalb des classes Verzeichnisses zu finden. PEAR Bibliotheken Verschiedene PEAR Bibliotheken werden in der Software an zentralen Punkten verwendet. Die PEAR Basisbibliotheken werden bereits automatisch mit PHP zusammen installiert, wobei die restlichen automatisch vom Installationsskript hinzugefügt werden. Die Liste dieser Bibliotheken kann im Installationsverzeichnis eingesehen werden. Wichtig hierbei ist, dass immer die entsprechenden Versionen installiert sind. Weitere Informationen zu den PEAR Bibliotheken finden sich auf der PEAR Webseite: 7

8 Smarty Template Engine Die Open-Source Template Engine Smarty findet in der Software Anwendung zur Darstellung der Nutzeroberfläche (Präsentationsschicht). Hierdurch sind PHP und HTML Quellcode voneinander getrennt und können von unterschiedlichen Personen gewartet werden. Um die Konfiguration und Bearbeitung der Smarty Templates zu erleichtern, kann in der Konfigurationsdatei in der Template Sektion der debugging Parameter aktiviert werden. Wird dieser Parameter auf true gesetzt, so wird ein spezielles Fenster geöffnet, welches Debug- und Laufzeitinformationen enthält. Weitere Informationen finden sich auf der Webseite des Open-Source Projektes und der dort auffindbaren Dokumentation zur Nutzung von Smarty: LiveUser Die LiveUser Bibliothek stellt ein User authentication and permission management framework dar, welches in der Software für die Nutzerauthentifizierung und Rechtesteuerung auf Anwendungsebene verantwortlich ist. Diese Rechtesteuerung wird unter anderem in der Modulkonfiguration verwendet, um den Zugriff auf die einzelnen Module zu steuern. Ferner wird die Nutzer-ID zur Zugriffsteuerung auf bestimmte Inhalte der Plattform verwendet. Während bei der Modulkonfiguration die Rechte basierend auf Applikationsbereichen vergeben werden, wird bei den Zugriffsrechten die Verknüpfung aus User-ID und z.b. Publikation verwendet. Hinweis: Die im Quellcode verwendete LiveUser-Version entspricht nicht der aktuellen im PEAR Repository enthaltenen Version. In der im Quellcode enthaltenen Version wurden zahlreiche Fehler beseitigt, welche zum damaligen Zeitpunkt im PEAR Projekt nicht beseitigt waren. Weitere Informationen hierzu finden sich im Abschnitt zur Modulkonfiguration und der LiveUser Projektewebseite: Javascript Bibliotheken Die Software verwendet zwei grundlegende Bibliotheken zum Rendering der Plattform. Die Overlib Bibliothek wird für das Anzeigen von Tooltips verwendet und ist standardmäßig durch die Smarty Template Engine unterstützt. Die jquery Bibliothek findet Verwendung bei der Überprüfung von Formularfeldern und der Anzeige von Fehlern bei der Dateneingabe. overlib - ToolTip Bibliothek für MouseOver Effekt 8

9 jquery - Manipulation und Überprüfung von Formularen Die jeweiligen Bibliotheken sind im javascript Verzeichnis zu finden. Weiter Informationen zu den Bibliotheken finden sich auf den jeweiligen Webseiten der Projekte: QUELLCODE Der Quellcode ist in zahlreiche Unterverzeichnisse untergliedert. Die nachfolgende Tabelle zeigt die verschiedenen Unterverzeichnisse und deren Funktion. Verzeichnisstruktur Verzeichnisname classes cmd config core docs INSTALL images javascript log modules styles templates tmp ttf uploads xml_def xsl_def Beschreibung Globale Klassen zur Verwaltung von Publikationen, Projekten und Profilen, sowie Logging, DB und Authentifizierung etc. genutzt in allen Modulen Shell Skript zur Wartung der Plattform bzgl. Mailings, Imports und Datenbank Globale Konfigurationsdatei Zentrale Einsprungsskripte der Software, welche die notwendigen globalen Klassen, wie z.b. Logging, aufrufen Dokumente zur Software Installationsskripte zum Set-Up der Plattform Bilder für Webansicht und PDF Darstellung Javascript Dateien und Bibliotheken Logging Verzeichnis, in das die Log Dateien und Fehlermeldungen der Software geschrieben werden Modulverzeichnis, welches alle Module der Plattform beinhaltet CSS Stylesheets Smarty Templates zum Rendering der Webausgabe Temporäre Dateien der Software, wie z.b. beim Upload von Dateien Truetype Fonts genutzt zum Rendern der PDF Ausgaben Verzeichnis speichert Volltexte von Publikationen, Profilbilder und Buchcover XML Formulardefinitionen, globale Navigationsdefinition und Texte für Kontakt, Impressum etc. XSLT Formatierungsregeln für Web, Excel, PDF und weitere Ausgabeformate 9

10 Basisklassen Unterhalb des classes Verzeichnisses befinden sich die Basisklassen, welche von jedem Modul verwendet werden. Die nachfolgende Aufstellung gibt einen Überblick über die einzelnen Basisklassen und deren Funktion. Verzeichnis authentification cache content-objects file form init ldap liveuser log mail navigation oai-pmh pager permissions smarty statistic store util webservices xml Funktion Klassen, die Authentifizierung der Nutzer gegen Datenbank und externe Authentifizierungsquelle (LDAP/SOAP) regeln Klassen, die das Zwischenspeichern von Funktionsergebnissen und Dateiinhalten steuern Klassen zum abstrahierten Zugriff auf Content-Objekte in der Datenbank. Dies betrifft den Zugriff auf Publikationen, Projekte, Profile, Amazon Inhalte und Wikipedia Inhalte Klasse für das Handling der Uploads, aber auch externen Downloads aller Art (Graphiken, Statistiken, PDF etc.) Neue Multiform und Formular-Parsing Methoden, welche die Klassen im store Verzeichnis zukünftig ersetzen sollen (aktuell ungenutzt) Initiale Basisklassen (siehe nachfolgende Tabelle) Klassen zum Handling von LDAP Anfragen LiveUser Bibliothek Klassen zum Logging von Fehlern und Warnhinweisen Klasse zum Versenden von Mails Parsen von Navigationslinks und Erzeugen der Navigation Klassen für die OAI-PMH Schnittstelle Klasse zum Pagen (Blättern) von Inhalten, steuert z.b. das Blättern durch Publikationen Permission Framework, der auf die Nutzer IDs der LiveUser Bibliothek aufbaut und die Zugriffsrechte auf Ebene der Content-Objekte steuert Smarty Template Engine Klassen Datenbankabfragen für die Darstellung von Statistiken Erweiterungen von PEAR Quickform um Multiform Funktionalitäten Allgemeine Utility Klassen zur allgemeinen Unterstützung Klassen zur Abfrage von Web Services Schnittstellen (Google/Amazon) Klassen zur Nutzung von XML und dem Parsen der in XML definierten Formulare und deren Umwandlung in Quickform Objekte Ferner sind unterhalb des classes Verzeichnisses im init Verzeichnis die initialen Basisklassen zu finden, welche bei jedem Aufruf einer Webseite aufgerufen werden und automatisch allen Modulen zur 10

11 Verfügung stehen. Nachfolgend finden sich eine Übersicht dieser Klassen und eine kurze Funktionsbeschreibung. Klassen AuthInit ConfigInit DAOInit ErrorHandling Logging LangInit QFInit TPLInit Funktion Initialisiert die Authentifizierung und den LiveUser Container Lädt die globale Konfiguration aus dem config Verzeichnis Stellt Verbindung zur Datenbank her und erstellt globales Objekt Initialisiert Error Handling (in Zusammenhang mit Logging Klasse) Stellt zentralen Logging Mechanismus zur Verfügung Lädt Mehrsprachigkeit und stellt Übersetzungsschnittstelle zu Verfügung Lädt Quickform Konfiguration und initialisiert Formular-Rendering Lädt Smarty Template Bibliothek und stellt globales Rendering Objekt zur Verfügung DATENBANK Das Datenbankmodell der Software basiert auf einem dynamischen Konzept, das auf der automatischen Generierung von Formularen auf Basis von XML Formulardefinitionen vorgenommen wird. Neue Formularfelder können hierbei hinzugefügt werden, ohne Änderungen an der Datenbank vornehmen zu müssen. Das Datenbankmodell besteht in seiner Grundstruktur aus drei verschiedenen Bereichen, die nachfolgend in der Graphik dargestellt werden: Projekte Publikationen Profile Upload Upload Zugriffsrechte Authentifizierung (Datenbank / externe Quelle) Die verschiedenen Inhalte sind hierbei eng mit den Zugriffsrechten verbunden. Das unterliegende Authentifizierungsystem LiveUser stellt die grundlegenden Zugriffsrechte auf Anwendungsebene zur Verfügung, wohingegen die Zugriffsrechte auf einzelne Inhalte wie z.b. einem Publikationsvolltext von der 11

12 Software selbst überprüft werden. Insofern werden in einem Bereich der Datenbank die Inhalte selbst abgespeichert und Zugriffsrechte auf Anwendungs- und Inhaltsebene jeweils ebenfalls getrennt gespeichert. Hieraus ergibt sich die im Folgenden vorgestellte Datenbankstruktur. Die Datenbankstruktur der Alexandria Software besteht aus sieben verschiedenen Tabellentypen die in folgende Gruppen eingeteilt werden können: 1. Allgemeine Tabellen 2. Import Tabellen 3. Language Tabellen 4. Logging Tabellen 5. Permission Tabellen 6. LiveUser Tabellen 7. Temporäre Tabellen Die allgemeinen Tabellen dienen der Speicherung der Inhalte, wie Publikationen, Projekte und Profile. In den Logging Tabellen werden hauptsächlich die Zugriffe, Suchanfragen oder Aktionen, die auf der Plattform durchgeführt wurden, gespeichert. Die Permission Tabellen enthalten die Zugriffsrechte von Gruppen und Personen auf bestimmte Inhalte der Plattform. Die LiveUser Tabellen entstammen dem PEAR::LiveUser Projekt und beinhalten alle User und Zugriffsrechte innerhalb der Applikation. Die Temporären Tabellen dienen hingegen einzig der performanten Anzeige und dem Abruf von Inhalten. Im Weiteren werden die Tabellen und ihr Zweck zusammengefasst dargestellt. Allgemeine Tabellen Tabellenname co_content_articles co_content_news co_inheritance co_institutes co_profiles_ext co_profiles_int co_projects co_projects_rel co_publications co_publications_rel co_relation_users co_relation_users_seq co_upload_files co_user_settings Zweck/Beschreibung Hilftstexte und Beschreibungen unterhalb von Eingabefeldern Nachrichten vom Plattform-Manager Beziehungen zwischen z.b. Publikation und Volltext-Datei Institutsprofildaten Profildaten von externen Autoren/Mitarbeitern Profildaten von internen Autoren/Mitarbeitern Metadaten von Forschungsprojekten Verknüpfung zwischen Forschungsprojekt und Mitarbeitern Metadaten von Publikationen Verknüpfung zwischen Publikationen und Autoren Verknüpfung Publikationen, Projekte und Profile mit Besitzer Sequenztabelle für neue Einträge in co_relation_users Tabelle Hochgeladene Dateien von Publikationen, Forscherprofilen und Institutsprofilen Persönliche Nutzereinstellung 12

13 newsletter_subscribers Externer Newsletter Adressen Import Tabellen Tabellenname ico_amazon ico_wikipedia Zweck/Beschreibung Amazon Import Buchdaten Wikipedia Import Artikel Language Tabellen Tabellenname lang_configuration lang_translation Zweck/Beschreibung Konfiguration Mehrsprachigkeit der Plattform Übersetzungen Logging Tabellen Tabellenname co_log_edit co_log_fulltextrequest co_log_import co_log_redirect co_log_search co_log_views co_log_workflow Beschreibung Bearbeitung von Inhalten durch Plattform-Manager Volltextanfragen ( Adresse und Status) IWI Import Log Weiterleitung von externen Links Suchanfragen Views und Downloads der Plattform Workflow Status und Bearbeitungsstand von Publikationen Permission Tabellen (Zugriffsrechte) Tabellenname co_permissions_groups co_permissions_platformmanager co_permissions_publicationmanager co_permissions_users Beschreibung Zugriffsrechte für Gruppen Liste der Plattform-Manager Liste der Publication-Manager Zugriffsrechte für einzelne Nutzer LiveUser Tabellen (User-Management) Tabellenname Beschreibung liveuser_applications Applikationsdefinitionen liveuser_applications_seq Sequenznummer liveuser_applications Tabelle liveuser_areas Bereichsdefinitionen liveuser_areas_seq Sequenznummer liveuser_areas Tabelle liveuser_area_admin_areas Bereichsdefinition für Administratoren (ungenutzt) liveuser_grouprights Gruppenrechte liveuser_groups Gruppendefinitionen liveuser_groups_seq Sequenznummer liveuser_groups Tabelle 13

14 liveuser_groupusers liveuser_group_subgroups liveuser_languages liveuser_languages_seq liveuser_perm_users liveuser_perm_users_seq liveuser_rights liveuser_rights_seq liveuser_right_implied liveuser_right_scopes liveuser_translations liveuser_userrights liveuser_users liveuser_users_seq Zuordnung Gruppen und Nutzer Untergruppendefinition Sprachdefinitionen Sequenznummer liveuser_languages Tabelle Zuordnung Permission-User-ID und Auth-User-ID Sequenznummer liveuser_perm_users Tabelle Rechtedefinition Sequenznummer liveuser_rights Tabelle Implizite Rechtedefinitionen Gültigkeitsbereiche von Rechten Übersetzungen Rechtezuordnung Nutzer Nutzerdefinition und Passwörter Sequenznummer liveuser_users Tabelle Temporäre Tabellen Tabellenname oai_repository _tmp_profiles_int _tmp_search Beschreibung Temporäre Tabelle für OAI-PMH Metadatensätze Temporäre aggregierte interne Profile aus co_profiles_int und liveuser_users Tabelle Temporärer Suchindex für Profile und Publikationen Hinweis: Die Software nutzt zur Extraktion der im XML Format gespeicherten Daten den neuen MySQL Befehl ExtractValue() und zur Manipulation der Datensätze UpdateXML(). Bei einem Wechsel auf eine andere Datenbank als MySQL sollte daher die Verfügbarkeit von XML/XPath Funktionalitäten überprüft werden. Weitere Informationen zur XML/XPath Unterstützung von MySQL finden sich auf folgender Webseite: Entity-Relationship Modell Nachfolgend ist das Entity-Relationship-Modell der Datenbankstruktur zur Software abgebildet. Die Darstellung ist ferner im docs Verzeichnis des Quellcodes als Graphik und im MySQL Workbench Format abgelegt. Nicht enthalten in dieser Graphik ist das von LiveUser verwendete Datenbankmodell. Dies kann der LiveUser Projektwebseite entnommen werden (siehe Abschnitt Bibliotheken). 14

15 Hinweis: Die MySQL Workbench Software zur Bearbeitung des Entity-Relationship-Modells kann kostenlos von der MySQL Webseite heruntergeladen werden. KONFIGURATION Datenbank Als zentrale Schnittstelle innerhalb des Quellcodes fungiert die Datenbankklasse, welche im init Verzeichnis unter halb des classes Verzeichnisses zu finden ist. Im const Verzeichnis unterhalb des init Verzeichnisses sind weiterhin die Datenbankkonstanten zu finden, welche im Quellcode verwendet werden. Bei einer Erweiterung der Datenbanken sollte in der db-const.inc.php daher eine entsprechende Konstante angelegt werden. Sollten weitere Erweiterung der Datenbankabstraktionsschicht notwendig werden, sind diese in der db.class.php vorzunehmen. Templates Die Smarty Templates der Plattform sind im templates Verzeichnis vorzufinden. Werden neue Templates erzeugt, sind diese diesem Ordner hinzuzufügen. Wie bereits beschrieben (siehe Abschnitt ARCHITEKTUR) 15

16 werden modulspezifische Templates mit einem Unterstrich am Anfang des Dateinamens gekennzeichnet. Sollte es notwendig werden die Abstraktionsschicht zu erweitern, so findet sich im init Verzeichnis die tpl.class.php Templateklasse. Das Rendering der Templates startet hierbei durch den Aufruf des default.tpl Templates. Dieses Standardtemplate bindet wiederum die folgenden Templates ein: header.tpl core.tpl footer.tpl - HTML Header - HTML Body Sektion - HTML Footer Das core.tpl Template ist hierbei für das Rendering der Module zuständig und bindet die folgenden Templates ein: top.tpl navigation_base.tpl navigation_context.tpl _backend_workflow.tpl {$inc_content_tpl} related_links.tpl _globalsearch.tpl bottom.tpl - Kopfbereich der Webseite (Logo, Plattformname, Sprachauswahl etc.) - Globale Navigation (Kopf und Fußbereich) - Kontextnavigation (rechts) - Workflow-abhängige Navigation und Hinweise - Module-abhängiges Template - Verknüpfte Links unterhalb des Moduls - Globales Suchfeld am Seitenende - Fußzeile der Seite Navigation und Module Soll ein neues Modul zur Software hinzugefügt werden oder die Navigation geändert werden, so befinden sich im navigation Verzeichnis unterhalb des xml_def Verzeichnisses die entsprechenden Konfigurationsdateien. Das navigation Verzeichnis unterteilt sich hierbei in zwei Unterverzeichnisse: conf - globale XML Modul- und Navigationskonfiguration context - modulspezifische XML Konfigurationen der kontextuellen Navigation Das conf Verzeichnis beinhaltet hierbei die Moduldefinition, wobei diese gleichzeitig mit der Konfiguration der Navigation verbunden ist. Hierbei gibt es fünf globale Konfigurationsdateien: header footer demand issue context - Konfiguration der Header-Navigation (oben) - Konfiguration der Footer-Navigation (unten) - Konfiguration der bedarfsorientierten Navigation (links unten) - Konfiguration der themenbezogenen Navigation (links oben) - Konfiguration der kontextuellen Navigation (rechts oben) 16

17 Entscheidend zu bemerken ist hierbei, dass jede Datei Module enthält, welche einerseits den Pfad zum entsprechenden Modul im module Verzeichnis, als auch die PageID (pid), die Rechtegruppe und den Namen des Moduls enthalten. Nachfolgend sind die einzelnen Parameter einer Modulkonfiguration aufgeführt: name type pid parent_pid goto href inc only permission options attr value id - Name des Moduls - Typ des Moduls - Eindeutige Page ID des Moduls - Zuordnung des Modules zum übergeordneten Modul - Weiterleitung des Links zu einem anderen Modul - Verlinkung des Moduls auf eine externe URL - Pfad zum Modul - Modul sichtbar im Frontend oder Backend - Rechtelevel des Moduls - Optionale Parameter zur Konfiguration des Moduls - Optionale CSS Stylesheet Parameter - Default Parameter Definition bei Drop-Down-Boxes - ID des Quickform Elements (nur für kontextuelle Navigation) Das definierte Rechtelevel des Moduls gibt hierbei an, welche Gruppen (LiveUser Gruppen) auf dieses Modul zugreifen dürfen. Die Rechtedefinitionen und die entsprechenden Konstanten können im core Verzeichnis der permissions.inc.php Datei entnommen werden. Diese bilden die Verknüpfung zu den in der LiveUser Datenbanktabelle liveuser_rights vorgehaltenen Rechtedefinitionen (siehe LiveUser Dokumentation). Rendering Das Rendering der verschiedenen Ausgabeformate wird, wie bereits erwähnt, über die XSLT Technologie gesteuert. Etwaige Anpassungen der Ausgaben sind daher im xsl_def Verzeichnis vorzunehmen. So befinden sich im web Unterverzeichnis die XSLT Templates für die Ausgabe von Publikationen im HTML Format. Hierbei werden die in der Datenbank gespeicherten XML Daten innerhalb der XSLT Transformation gefiltert, formatiert und sortiert. Entsprechenden Änderungen der Inhalte der HTML Ausgabe müssen daher in den XSLT Dokumenten vorgenommen werden. WARTUNG Die Wartung der Software und Datenbank geschieht üblicherweise über das Kommandozeilenskript im cmd Verzeichnis. Das cmd.php Shell Skript muss hierbei von der Kommandozeile ausgeführt werden. 17

18 Werden keine Parameter beim Aufruf des Skriptes angegeben, so wird eine Hilfe ausgegeben. Diese zeigt die verschiedenen Parameter, mit denen das Skript aufgerufen werden kann, an. Folgend sind die verschiedenen Wartungsmöglichkeiten über dieses Skript aufgeführt und kurz beschrieben: Hinweis: Bitte überprüfen Sie, dass das cmd.php Skript ausführbare Rechte besitzt ( chmod 0744 cmd.php ). Anderenfalls kann dieses Skript nicht von der Kommandozeile ausgeführt werden. Funktion Datenbankoptimierung Import von IWI Profile, Projekte und Publikationen Amazon Buchdatenimport Import Wikipedia Artikel Erstellung Such-Cache Erstellung Profile-Cache Erstellung OAI-Repository- Cache Mailing Volltext Anfrageservice Mailing Besucher Volltext Beschreibung Bei Aufruf der Datenbankoptimierungsoption werden mit Hilfe des optimize SQL Befehls die Überhänge der MyISAM Tabellen entfernt. Dies entspricht einer Defragmentierung der Tabellen. Über die Option werden die Profile, Projekte und Publikationen des Institutes für Wirtschaftsinformatik in die Datenbank importiert. Ferner ist es notwendig die neuen Nutzer der IWI LDAP Gruppe automatisiert zu importieren. Anderenfalls können die Profile, Projekte und Publikationen keinem internen Nutzeraccount zugeordnet werden. Alexandria nutzt in großem Umfang die durch die Amazon Web Services zur Verfügung gestellten Buchdaten. Hierbei werden die Buchdaten von Amazon zu den entsprechenden ISBN Nummern, die durch die Nutzer eingegeben wurden, importiert. Dieser Prozess importiert die Artikel, welche dem Namen einer Person in der Datenbank entsprechen und bei denen das Wort Universität St.Gallen im Text vorkommt. Ist ein solcher Artikel zu einer Person vorhanden, wird unterhalb des Personenprofils ein Link zum Wikipedia Artikel gesetzt. Für den internen Suchindex ist es notwendig regelmäßig den Suchcache zu erneuern. Dieser Suchindex stellt die notwendigen Suchergebnisse über die Metadaten der Software zur Verfügung. Für die schnelle Darstellung und Vermeidung von komplexen Datenbankabfragen zur Laufzeit werden die LDAP-Userprofile und die von den Nutzern eingegebenen Profildaten zu einem gemeinsamen Profil aggregiert. Bei Abfrage der OAI-PMH Schnittstelle wird eine statisch generierte Datenbanktabelle abgefragt, um eine möglichst hohe Performance bei der Auslieferung der Metadatensätze zu erreichen. Hierzu muss regelmäßig der OAI-Repository Cache erneuert werden. Der Volltext Anfrageservice ist ein Dienst, der den internen Forschern eine gesammelte Mail zu Anfragen bzgl. der Verfügbarkeit von Volltexten zustellt. Anfragende Benutzer werden hierbei informiert, sobald ein von ihnen 18

19 Mailing Newsletter Mailing Workflow Mailing Forthcoming Mailing Vollständigkeit User Account Synchronisation angefragter Volltext auf der Plattform verfügbar ist. Mittels dieser Option wird eine monatlicher Newsletter automatisch aus den aktuellen Publikationen und Projekten erstellt und versendet. Dieser Prozess versendet -Anfragen an die entsprechenden Nutzer der Plattform bei denen vom Plattform-Manager eine Publikation zur Ergänzung zurück an den Autor gegeben wird. Publikationen, welche vom Autor als Forthcoming gekennzeichnet werden, können mit diesem Dienst auf die Überprüfung des Status der Publikation aufmerksam gemacht werden. Dieser Dienst kann verwendet werden, um den Nutzer der Plattform eine Nachricht zukommen zu lassen ihre Publikationen auf Vollständigkeit zu überprüfen. Hierbei werden interne Nutzeraccounts deaktiviert und deren Personenprofil entfernt, wenn diese im externen Authentifzierungscontainer deaktiviert wurden. Löschen der kompilierten Smarty Templates Um die kompilierten Smarty Templates zu löschen, müssen alle im./templates/compiled_templates/ Verzeichnis vorhandenen Dateien gelöscht werden. Die Templates werden beim nächsten Aufruf automatisch wieder neu kompiliert und in diesem Verzeichnis abgelegt. Hinweis: Das Caching der Templates darf nicht verwendet werden und auch nicht in der Konfiguration aktiviert werden! Löschen von temporären Dateien Zum Löschen der temporären Dateien können die Inhalte des tmp Verzeichnis komplett gelöscht werden, inklusive der Unterverzeichnisse und Dateien. Die Verzeichnisse werden beim nächsten Aufruf automatisch wieder erstellt. Amazon Bücher neu synchronisieren Sollte beim Import der Amazon Buchdaten ein Fehler auftreten, kann dieser durch das Löschen der alten Daten problemlos beseitigt werden. Der Neustart des Imports kann hierbei auch manuell erfolgen. Folgende Schritte sind hierzu notwendig: 1. Löschen der Inhalte der ico_amazon Tabelle 19

20 2. Löschen des amazon Unterverzeichnisses im upload Verzeichnis 3. Start des Import-Daemons über das Wartungsskript im cmd Verzeichnis CHANGELOG Version der Dokumentation Autoren der Dokumentation Thomas Nicolai Lars Kirchhoff 20