Realisierung eines Kundencenters als TYPO3- Erweiterung mit Anbindung an SugarCRM und Redmine. Bachelorthesis

Realisierung eines Kundencenters als TYPO3- Erweiterung mit Anbindung an SugarCRM und Redmine Bachelorthesis zur Erlangung des akademischen Grades eines Bachelor of Engineering (B. Eng.) von Sebastian Stein Erstbetreuer: Dr. rer. nat. Thomas Meinike Zweitbetreuer: B. Eng. Christian Opitz Arbeitsplatz: Netzelf Agentur für guten Eindruck GbR eingereicht am: 05.03.2010

II Erklärung Ich versichere hiermit, dass ich die vorliegende Arbeit selbstständig ohne fremde Hilfe verfasst und keine anderen als die im Literaturverzeichnis angegebenen Quellen benutzt habe. Stellen, die wörtlich oder sinngemäß aus veröffentlichten oder noch nicht veröffentlichten Quellen entnommen sind, wurden als solche kenntlich gemacht. Die Zeichnungen oder Abbildungen in dieser Arbeit sind von mir selbst erstellt wurden oder mit einem entsprechenden Quellennachweis versehen. Diese Arbeit ist in gleicher oder ähnlicher Form noch bei keiner anderen Prüfungsbehörde eingereicht worden. Merseburg, den 05.03.2010 Unterschrift Studierender

III Inhaltsverzeichnis Abkürzungsverzeichnis... V Abbildungsverzeichnis... VII 1 Einleitung... 1 1.1 Fallstudie... 1 1.2 CRM- und PMS-Systemwahl... 2 1.3 Aufgabenstellung... 4 1.4 Aufbau dieser Arbeit... 5 2 Grundlagen... 7 2.1 TYPO3... 7 2.1.1 Allgemeines... 7 2.1.2 Installation und System-Konfiguration... 11 2.1.3 TypoScript... 14 2.1.4 Systemarchitektur... 15 2.2 FLOW3-Technologie... 17 2.2.1 Das Extension-Framework Extbase... 17 2.2.2 Die Template-Engine Fluid... 22 3 Analyse vorliegender Datenzugänge... 26 3.1 SugarCRM-Webservice... 26 3.1.1 Modul- und Datenstruktur... 26 3.1.2 SOAP-RPC... 28 3.1.3 Die WSDL-fähige PHP-Klassenbibliothek: NuSOAP... 30 3.2 Redmine-Webservice... 34 3.2.1 PMS-Ressourcen... 34 3.2.2 REST... 36 3.2.3 RESTful Webservice-Client: PHP-ActiveResource... 38 4 Entwicklungskonzept... 42 4.1 Anforderungen/Lösungsansatz... 42 4.2 Entwicklungsumgebung... 45

IV 4.3 Entwicklungsrichtlinien... 46 5 Entwicklung... 49 5.1 TYPO3-Testaufbau... 49 5.2 Die Nutzer-Authentifizierung... 52 5.2.1 Der native Authentifizierungsprozess... 52 5.2.2 Die Auth-Service -Klasse... 53 5.3 Das Extbase -Frontend-Plugin... 58 5.3.1 Konfiguration... 58 5.3.2 Anwendungslogik... 61 5.3.3 Steuerungslogik... 63 5.3.4 Darstellungslogik... 65 6 Auswertung... 67 6.1 Ergebnis... 67 6.2 Zusammenfassung... 70 6.3 Ausblick... 71 Literaturverzeichnis... VIII Anhang... XII A. Verzeichnisstruktur von SugarMine... XII B. Quellcode-Ausschnitt einer AccountController -Action... XIII C. Quellcode-Ausschnitt eines Fluid -Templates... XIV D. SugarMines Tickets (aus forge.typo3.org)... XVII

V Abkürzungsverzeichnis API ASCII BE CDATA CLI CMS CRM CRUD CSS CURL CVS DAM DBAL DDD DMS DTD ECMS ERP EXT FE GPL GUI HTML HTTP IETF IT IDE JSON LAMP LDAP MVC MySQL PHP PI PDT Application Programming Interface American Standard Code for Information Interchange Backend Character Data Command Line Interface Content-Management-System Customer-Relationship-Management Create, Read, Update, Delete Cascading Stylesheet Client for URLs Concurrent Versions System Digital Asset Management Database-Abstraction-Layer Domain Driven Design Dokumenten-Management-System Document Type Definition Enterprise-Content-Management-System Enterprise Resource Planning Extension Frontend General Public License Graphical User Interface Hypertext Markup Language Hypertext Transfer Protocol Internet Engineering Taskforce Informationstechnik Integrated Development Environment JavaScript Object Notation Linux, Apache, MySQL, PHP Lightweight Directory Access Protocol Model-View-Controller My Structured-Query-Language PHP Hypertext Preprocessor Plugin PHP Development Tool

VI PMS REST RoR RPC RSS SaaS SOAP SV SVN TER TS TSFE UML URI URL W3C WCMS WSDL XML XSD XSLT Projektmanagementsoftware REpresentational State Transfer Ruby on Rails Remote Procedure Call Really Simple Syndication Software as a Service Simple Object Access Protocol Service Subversion TYPO3-Extension-Repository TypoScript TypoScript Frontend Unified Modeling Language Uniform Resource Identifier Uniform Resource Locator World Wide Web Consortium Web-Content-Management-System Web Services Description Language Extensible Markup Language XML-Schema-Definition Extensible Stylesheet Language Transformation

VII Abbildungsverzeichnis Abb. 1: Cloud Computing am Beispiel eines Kundencenters als System-Knotenpunkt... 2 Abb. 2: System-Umgebung des Kundencenters SugarMine... 5 Abb. 3: WCMS-Leistungsklassen... 8 Abb. 4: Backend Ansicht des Install Tools von TYPO3 4.3... 12 Abb. 5: Trennung von Layout, Inhalt und Steuerung... 14 Abb. 6: Die Systemarchitektur von TYPO3... 16 Abb. 7: Das Model-View-Controller Paradigma... 19 Abb. 8: Die schichtweise Architektur des Domain Driven Designs von Extbase... 20 Abb. 9: Aggregat-Ansicht der Entitäten der Blog-Extension... 21 Abb. 10: Die Template-Engine als zentraler Verarbeitungsprozess der View... 23 Abb. 11: Routing von SOAP-Nachrichten durch den HTTP-POST... 29 Abb. 12: Formatiert dargestellte WSDL-Definitionen der Operation get_entry... 33 Abb. 13: SVN-Repository-Browser von Redmine... 35 Abb. 14: Ressourcen-Manipulation via URL nach REST... 37 Abb. 15: Aufgabenbereiche von SugarMine als Kundencenter... 44 Abb. 16: Leere Verzeichnisstruktur eines Frontend-Plugins unter Extbase... 48 Abb. 17: Seitenbaum der Testumgebung von SugarMine im TYPO3-Backend... 51 Abb. 18: Der Prozess-Chart für die Erzeugung einer Nutzersession unter TYPO3... 52 Abb. 19: UML-Klassendiagramm (Vererbung) der Auth-Service -Klassen... 55 Abb. 20: UML-Klassendiagramm (Inkludierung) der Repository-Klassen im FE-Plugin. 62 Abb. 21: Prozessdelegationen einer beispielhaften Datenabfrage aus dem Frontend... 64 Abb. 22: Fehlerbenachrichtigung bei einer Datenänderung im Kundencenter... 68 Abb. 23: Tickets (Issues) aus Redmine im Kundencenter SugarMine... 69 Abb. 24: Belange (Cases) aus SugarCRM im Kundencenter SugarMine... 69

1 1 Einleitung 1.1 Fallstudie Diese Arbeit beschäftigt sich mit der Konzeption und dem programmiertechnischen Umsetzung eines Kundencenters, das im Auftrag der Agentur Netzelf steht. Ein Kundencenter bietet für ein Unternehmen die Möglichkeit, dem Kunden einen transparenten Einblick in den aktuellen Projektzustand zu gewähren. Die dadurch gewonnene Schnittstelle zwischen dem Kunden und dem Dienstleister vereinfacht den Informationsaustausch und dient der reibungslosen Kommunikation beider Geschäftsparteien. Im Kundencenter agiert der Auftraggeber förmlich im Projekt und gewinnt, durch den zusätzlichen Einfluss, gegenüber dem Dienstleister an Vertrauen. Zudem wird dem Kunden ein Einblick in die vom Auftragnehmer erfassten Daten gewährt. Dem dienstleistenden Unternehmen steht es dabei offen, inwieweit es dem Kunden Einblick und Eigeninitiative bei der Verwaltung der erfassten Daten zugesteht. Diese Möglichkeit erlaubt es, verwaltungstechnischen Aufwand bei der Datenpflege bzw. Datenerfassung von Kundendaten für das Unternehmen einzusparen. Es liegt also auf der Hand, dass der unternehmerische Einsatz eines Kundencenters dem Arbeitsfluss im Projektablauf auf beiden Seiten der Geschäftsabwicklung zu Gute kommt. Aufgrund der Vielfältigkeit möglicher Geschäftsfelder erscheint es unmöglich, auf eine fertige Software-Lösung zu setzen. Ein programmiertechnischer Eigenaufwand lässt sich also nicht verhindern. Jedoch existieren etablierte Open-Source IT-Systeme für das Management von Projekten und Kundendaten, die zusammengefasst eine solide Grundlage für Kundencenter-Funktionen abgeben. Hierbei wäre es die eigentliche Aufgabe des Kundencenters, die notwendigen Daten aus den Projekt- und Kundenmanagement-Systemen auszulesen und für den Kunden anschließend in einem eigenständigen Portal darzustellen. Da davon auszugehen ist, dass derartige Kundenoder Projektmanagement-Systeme datenbankgestützt sind, ist für das Kundencenter keine zusätzliche Persistenz der Daten notwendig. Es bietet sich für die Umsetzung des Kundencenters also ein Portal an, das vollständig auf Cloud Computing basiert. Die dabei ausgelesenen Daten können temporär an die Session des autorisierten Nutzers gebunden werden. Das zu entwickelnde Kundencenter ist demnach als eigenständige Dienstleistungssoftware (SaaS) zu verstehen, die in der bestehenden Firmen- Internetpräsenz (ECMS) integriert, als Schnittstelle zwischen den eingesetzten

2 Verwaltungssystemen (CRM und PMS) fungieren soll. Die folgende Abbildung zeigt, dass das Kundencenter an die eingesetzten Verwaltungssysteme gebunden und damit nur für einen vordefinierten Systemaufbau einsatzfähig ist. Abb. 1: Cloud Computing am Beispiel eines Kundencenters als System-Knotenpunkt 1.2 CRM- und PMS-Systemwahl Für die Auswahl der webbasierten Management-Systeme ist neben der Funktionalität auch die zur Verfügung gestellte API ausschlaggebend. Ohne eine vorhandene Programmierschnittstelle ist es für das Kundencenter unmöglich, auf externe Daten eines in sich abgeschlossenen Systems zuzugreifen, ohne dabei festgelegte Sicherheitsstrukturen zu verletzen. Außerdem kommt für dieses Projekt nur der Einsatz von Open-Source-Software in Frage, was die Auswahl proprietärer Management- Systeme von vornherein ausschließt. Dennoch brauchen sich Open-Source-Systeme nicht vor den kommerziellen Konkurenz-Produkten zu verstecken, was vor Allem auf einen stetig wachsenden Marktanteil vergleichbarer Open-Source-Systeme zurückzuführen ist. Diese Prognose hat sich nach einer Abfrage-Analyse auf verschiedenen Open-Source-Portalen, wie zum Beispiel Sourceforge (URL.: Sourceforge.net), bestätigt. Weiterhin ist zu beachten, dass der Begriff Open-Source mindestens auf einen offenen Quellcode, jedoch nicht zwangsläufig auf eine kostenfreie Verwendung, schließen lässt. Das ausgewählte System sollte zudem ein gewisses Marktreife-Potenzial aufweisen und den Open-Source Gedanken anhand einer Developer-Community widerspiegeln. Sogenannte Hosted-CRM oder -PMS kommen, neben den proprietären Systemen, für die Auswahl ebenfalls nicht in Frage, da hier keine absolute Datensicherheit gewährleistet werden kann insbesondere für sensible Kundendaten die von Dritten einsehbar wären.

3 Da die allgemeinen Auswahl-Kriterien der Systemwahl festgelegt sind, kann sich die weiterführende Selektion auf das jeweilige Aufgabengebiet beschränken. Kundenbeziehungsmanagementsoftware (CRM) Erst durch die Anbindung an ein CRM-System ist das Kundencenter in der Lage, den Kunden die Verwaltung und Einsicht von kunden- und auftragsbezogenen Daten zu ermöglichen. Grundsätzlich dient ein Kundenbeziehungsmanagement dem Kundenkontakt einer Firma. Ein CRM-System stellt dem Projekt- bzw. Kundenmanager ein Werkzeug zur Verfügung, das die Verwaltung von Kundenbeziehungen erleichtert. Vorhandene Aspekte für das Projektmanagement können integriert sein, sind aber nicht zwingend notwendig. Diverse technische Aspekte, die ein Projekt betreffen, sind ausschließlich auf Entwickler-Seite zu verwalten. Das nicht-technische CRM-Projektmanagement könnte demnach als erste Anlaufstelle die Lücke zwischen Auftraggeber und Entwickler schließen. Nach ausführlichen Recherchen hat sich herausgestellt, dass die Systeme Vtiger und SugarCRM den gestellten Anforderungen voll und ganz gewachsen sind. Letztendlich ist das Projektmanagement und betriebswirtschaftliche Personal zu dem Entschluss gekommen, SugarCRM (Community Edition) einzusetzen da es, subjektiv gesehen, eine bessere Nutzerfreundlichkeit aufwies. Außerdem genießt das Grundsystem von SugarCRM ein hohes Marktreifepotential nicht zuletzt wegen der alternativen, kommerziellen Enterprise-Version. Projektmanagementsoftware (PMS) Eine Projektmanagementsoftware stellt für das Kundencenter Daten zur Verfügung, die dem Auftraggeber einen ungetrübten Einblick in den aktuellen Projektfortschritt ermöglichen. Das bisherige PMS von Netzelf hört auf den Namen Dot Project. Die letztendliche Entscheidung gegen das System ist darin begründet, dass es sich derzeit in einer sehr frühen Entwicklungsphase befindet, was auf den System-Wechsel auf das Zend- Framework zurückzuführen ist. Aufgrund der Tatsache, dass betriebswirtschaftliche Projektmanagement-Funktionen bereits durch SugarCRM und Microsoft Project abgedeckt werden, ist es sinnvoll, auf eine PMS zu setzen, die auf das technische Unternehmens-Portfolio zugeschnitten ist.

4 Für Netzelf bietet sich daher ein System an, das den Anforderungen der Software- Entwickler und Designer entgegenkommt. Für das Kundencenter eröffnen sich damit Projektdaten, die dem Fachpersonal des Auftraggebers zur Verfügung gestellt werden können. Dazu zählen unter anderem der Zugriff auf das Ticket-System sowie der durch den Code-Browser ermöglichte Einblick in den versionskontrollierten Entwicklungsfortschritt (z.b. aus SVN- oder CVS-Repository). Die Verwendung dieser Features für das Kundencenter, gilt es im 26 (Anaylse vorliegender Datenzugänge) zu überprüfen. Sowohl Redmine, als auch Trac entsprechen den genannten Anforderungen als webbasierte Projektmanagementsoftware. Beide Systeme sind auf die Verwaltung von Software-Projekten spezialisiert und besitzen einen gleichwertigen Funktionsumfang. Hauptsächlich durch die Unterstützung zu einer übersichtlichen Verwaltung mehrerer Projekte fiel die Entscheidung auf Redmine. Der erfolgreiche Einsatz von Redmine unter der TYPO3-Entwickler-Gemeinde 1 untermauert diesen Entschluss. 1.3 Aufgabenstellung Als Enterprise-Content-Management-System (ECMS) bietet TYPO3 die Grundlage für die Internetpräsenz der Agentur Netzelf. Es hat sich herausgestellt, dass derzeit kein Kundencenter als TYPO3-Extension im TYPO3-Extension-Repository (TER) vorliegt. Dieser Umstand spricht dafür, für das benötigte Kundencenter eine Open Source Entwicklung auf der Grundlage einer TYPO3-Erweiterung durchzuführen. Neben Redmine, welches für das Software-Projektmanagement eingesetzt wird, steht SugarCRM für das Kundenmanagement zur Verfügung. Jedes der erwähnten Systeme hat sich als optimales IT-Werkzeug für das entsprechende Aufgabengebiet etabliert. Aus drei Systemen folgen drei in sich abgeschlossene Arbeitsumgebungen. Dieser Umstand erscheint für die Verwaltung optimal, erschwert jedoch die zusammengeführte Online- Präsentation von gemeinsamen Kunden- und Projektdaten. Um das Kundencenter zu realisieren, das relevante kundenbezogene Daten aus SugarCRM und Redmine zusammenfasst und darstellt ist, wie erwartet, eine weitere in sich abgeschlossene Web- Applikation notwendig. Die optimale Umgebung für diese Applikation bietet TYPO3, wo das Kundencenter als Schnittstelle zu den Projektmanagementsystemen Redmine und SugarCRM direkt in die bestehende CMS-Seitenstruktur, in Form einer TYPO3-1 URL: forge.typo3.org

5 Extension, integriert werden kann. (siehe: Abb. 2) Als Extension-Name ist die Bezeichnung SugarMine festgelegt. Ein Kunde, der sich in SugarMine anmeldet, muss gegen die Kundentabelle der SugarCRM-Datenbank authentifiziert werden können. Anschließend soll der autorisierte Kunde als Frontend-Nutzer unter TYPO3 angemeldet sein und sich in SugarMine befinden. In diesem Kunden-Portal hat der Nutzer Einsicht und Kontrolle über freigeschaltete Kunden- und Projekt-Daten aus den Verwaltungstools SugarCRM und Redmine. Abb. 2: System-Umgebung des Kundencenters SugarMine 1.4 Aufbau dieser Arbeit Grundlagen. Das folgende Kapitel beschäftigt sich ausschließlich mit Grundlagenwissen über TYPO3, das als CMS die Basis der Extension-Entwicklung ausmacht. Weiterführend werden zukunftsweisende Technologien vorgestellt, die aus dem aktuellen FLOW3-Framework stammen und ebenfalls unter TYPO3 als Entwicklungsgrundlage für das Kundencenter dienen: das Extension-Framework Extbase und die Template-Engine Fluid. Das Kapitel Grundlagen stellt somit den Recherche-Schwerpunkt dieser Arbeit dar, setzt Grundkenntnisse in Webtechnologien voraus und bereitet technologisches Verständnis auf spätere Abschnitte, wie der Entwicklung, vor.

6 Analyse. 26 dient der Analyse der Webservices, die SugarCRM und Redmine in Form einer API anbieten. Hierbei wird neben der theoretischen Recherche, die eine Vergleichsanalyse der vorliegenden Webservices erlaubt, auch eine programmiertechnische Umsetzung durchgeführt. Auf der Grundlage dieser Tests kann der praktische Nutzen, sowie die Durchführbarkeit der Webservice-APIs geprüft und miteinander verglichen werden. Ergebnis dieser Untersuchungen sind Erkenntnisse über die projektbezogene Einsatzfähigkeit der Webservice-Technologien und -APIs, die den Datenzugang zu den PMS- und CRM-Systemen für das Kundencenter ermöglichen. Konzept. Basierend auf den gewonnenen Erkenntnissen aus der vorangegangenen Hauptrecherche stellt 42 das Entwicklungskonzept des Kundencenters vor. Neben den technologisch ausformulierten Systemanforderungen, werden hier erste Aspekte vorgestellt die als Lösungskonzept in Frage kommen. Weiterhin wird die Arbeitsweise der Programmierung erläutert und anhand von eingesetzten Entwicklungsumgebungen und -werkzeugen beschrieben. Abschließend werden Entwicklungsrichtlinien besprochen. Sie sind von TYPO3 und FLOW3 vorgegeben und betreffen explizit die nachfolgende Programmierung der Kundencenter-Extension. Entwicklung. Für die technische Realisierung des Kundencenters fließen im 49 Recherche, Analyse und Konzept in die Durchführung zusammen. Einleitend wird der lokale TYPO3-Testaufbau beschrieben, der ausschließlich als Test- und Entwicklungsumgebung für die Kundencenter-Extension dient. Weiterführend wird der Extensionaufbau des Kundencenters erläutert und der Entwicklungsvorgang anhand von Prozesscharts, UML-Diagrammen und kurzen Quellcode-Ausschnitten beschrieben. Dabei spiegelt sich die Kapitelunterteilung in der modularen Struktur der Extension wider. Auswertung. Im 67 wird das Ergebnis des Kundencenters mit Hilfe von Bildschirmaufnahmen aus der Sicht des Browsers präsentiert. Dabei wird das praktische Ergebnis ebenfalls aus der Sicht des administrativen Extension-Nutzers erläutert. Die hauptsächliche Projekt-Auswertung findet in der Zusammenfassung statt, wo die vorliegende Arbeit kurz reflektiert wird. Abschließend wird auf zukünftige Verbesserungen und Weiterentwicklungen des Kundencenters eingegangen, die sich vor allem auf die Veröffentlichung als eigenständige Extension, sowie die System- Implementierung bei Netzelf beziehen.

7 2 Grundlagen 2.1 TYPO3 2.1.1 Allgemeines Ein Web-Content-Management-System (WCMS) dient als webbasierte Software zur Erstellung und Verwaltung von Internetseiten. Der unbestreitbare Vorteil eines Content-Management-Systems liegt in der Wartbarkeit und Flexibilität der Webseitenverwaltung. Während das Aussehen der Webseite über ein HTML-Gerüst und verschiedene Code-Teile gesteuert wird, können leicht veränderliche Elemente, Texte und Bilder in diesem Template, der Formatvorlage, angezeigt werden. Das zu Grunde liegende Template, das dass Aussehen steuert, lässt sich mit den entsprechenden Kenntnissen ändern, und diese Änderungen wirken sich auf alle bereits erstellten Webseiten aus. Die Inhalte, also Texte und Bilder, die in das Template eingebunden werden, lassen sich dagegen unabhängig vom Template oder anderem Programmcode anpassen, löschen und neu erstellen. Typischerweise sollen die zuständigen Mitarbeiter diese Aufgabe so einfach wie möglich erledigen können. Hierfür sind häufig keine Kenntnisse in HTML, der beschreibenden Websprache, nötig. 2 Kasper Skårhøj, der Erfinder und ehemalige Chefentwickler von TYPO3, hatte diesen Vorteil und Nutzen eines CMS schon frühzeitig erkannt und 1998 begonnen, die Grundlage für das heutige, modular aufgebaute TYPO3, zu schaffen. Das Ergebnis war eine objektorientierte, vollständig in PHP geschriebene, plattformunabhängige Serverapplikation, für deren Bedienung man lediglich einen Webbrowser benötigt. Die dafür benötigte LAMP/WAMP 3 -Architektur erlaubt eine sowohl offene, als auch standardisierte Grundstruktur. Erstmals im Jahr 2000 unter der GPL lizensiert (GNU General Public License) und veröffentlicht, wurde TYPO3 schließlich als Open-Source- Software durch zahlreiche freie Mitarbeiter weiterentwickelt. Es unterliegt einer wachsenden Entwickler-Community und ist durch den modularen Rahmenaufbau und den Extension Manager ebenso modular erweiterbar. Im TER 4, dem Extension- Verzeichnis für TYPO3, existieren derzeit über 4000 solcher Erweiterungen. Allerdings deckt TYPO3 nicht nur Funktionen ab, die einem Web-Content-Management- System (WCMS) gerecht werden, wie zum Beispiel dem Verwalten webfähiger Inhalte. 2 [Stöckl, Bongers 2006] Einstieg in TYPO3 4.0, S.12 3 Abk.: Linux/Windows, Apache, MySQL, PHP 4 Abk.: Typo3-Extension-Repository; URL: http://typo3.org/extensions/repository/

8 Es gehört ebenfalls in den Bereich der Enterprise-Content-Management-Systeme (ECMS) und bietet Funktionen zur Gruppenverwaltung, die es dem System ermöglichen, auch als Portal oder Intranet in Erscheinung zu treten (siehe: Abb. 3). Abb. 3: WCMS-Leistungsklassen (Quelle: [Kroekertskothen 2005], S.6) Die Bezeichnung Enterprise-Web-CMS trifft es also auf den Punkt, wobei der Funktionsumfang auf die Erstellung von Internetseiten konzentriert ist. Ein Management auf der Druck-Plattform ist trotzdem möglich. Das Magazin t3n wird zum Beispiel über TYPO3 mit Hilfe der XML-Technologie automatisch aufgesetzt und generiert. TYPO3 ist ein mächtiges und zugleich flexibles System mit zahlreichen Features, die hauptsächlich von System- und TER-Erweiterungen abgedeckt werden. Eine komplette Feature-Übersicht ist online einsehbar. 5 Eine Aufzählung und Erläuterung der Grundfunktionen würde den Rahmen dieser Arbeit sprengen. Demnach werden in den folgenden Abschnitten nur die Enterprise-Fähigkeiten von TYPO3 aufgezeigt die es vor allem im Einsatz als ECMS für dieses Projekt auszeichnet. Folgende Anforderungen werden dabei laut Altmann an ein ECMS gestellt: Kennzeichnend für Enterprise Content Management Systeme ist die IT-Welt das Abbild bestehender Unternehmensprozesse, in denen es stattfindet. Zwischen Enterprise Resource Planning (ERP) und Customer Relationship Management (CRM), Dokumenten-Management-Systemen (DMS) und Office-Applikationen muss ein CMS 5 URL: http://www.aoemedia.de/typo3-cms/komplette-feature-liste.html

9 eine vereinende und vermittelnde Rolle einnehmen, um verschiedene Datenformate und Drittsysteme bei der Produktion und Präsentation von Inhalten nutzen zu können. 6 Aus dieser Anforderungsanalyse ist erkennbar, dass ein ECMS die ideale Basis für das Kundencenter als Systemschnittstelle darstellt. Sowohl ECMS als auch Kundencenter sind bestrebt, eine vermittelnde Rolle zwischen bestehenden Unternehmensprozessen einzunehmen. Es bietet sich daher an, das Kundencenter in das ECMS-Systemgefüge nahtlos einzugliedern. Folgende Enterprise-Funktionen verdeutlichen hierbei, wie TYPO3 den gestellten Anforderungen an ein ECMS gerecht wird: korrigieren kann. Zudem erlauben sogenannte Symlinks 10 Integrations- und Erweiterungsfähigkeit Durch die System-Extension DBAL 7 werden Datenbank-Klassen von TYPO3 derart erweitert, dass neben dem Zugriff auf MySQL auch andere Datenbanken angebunden werden können. Mit Hilfe dieser Teilfunktion der Extension-API und der Core-API ist TYPO3 auch dazu fähig, auf Fremdsysteme zuzugreifen. 8 Das modulare Rahmengerüst, der Extension-Manager, das Typo3 Extension Repository (TER) und die vordefinierten Entwicklungsrichtlinien nach den Project- Coding-Guidlines 9 erlauben zudem hochkompatible Möglichkeiten für Erweiterungen. Für die Extension-Entwicklung bietet TYPO3 vordefinierte Schnittstellen an, um Kern- oder Extension-Funktionen zu erweitern. Mit TYPO3 lassen sich unbeschränkte Seitenstrukturen realisieren und mehrfache Domains verwenden. Das erneuerte Frontend-Editing verbessert den Arbeitsfluss, indem der Redakteur auch aus dem Frontend heraus Seiteninhalte System- Administratoren durch die laufende TYPO3-Version umschalten und Updates vorzunehmen. Wartungsarbeiten können auch extern über das Command-Line- Interface (CLI) durchgeführt werden. Standardisierung und Internationalisierung TYPO3 setzt auf der offenen, standardisierten Architektur LAMP/WAMP auf. Somit ist für die Bereitstellung lediglich ein PHP-fähiger Apache-Webserver notwendig. 6 [Altmann et al. 2004] TYPO3, S.44 7 Abk.: Database-Abstraction-Layer 8 Vgl.: [AOE Media 2010] TYPO3-Funktionen für Unternehmen (Hrsg.) 9 URL: http://typo3.org/documentation/document-library/core-documentation/doc_core_cgl/4.1.0/view/1/1/ 10 Symbolische Links, die ein Umschalten auf einen anderen System-Kern bzw. auf eine andere Version ermöglichen

10 Durch Masken wird das Anlegen von mehrsprachigem Inhalt aus dem Backend heraus realisiert. Dabei ist es möglich, Sprachdateien über das XML-Format zu definieren, die wiederum von Übersetzungsagenturen bearbeitet werden können. Dafür ist die lokale Extension l10nmgr 11 verantwortlich. 12 Grundsätzlich sind für die Inhaltsverwaltung verschiedene Ausgabeformate möglich: XML, HTML, RSS, SOAP, DocBook und viele mehr. Rechte- und Zugriffsverwaltung Die Benutzer von TYPO3 können meist bestimmte Rollen in der Informationsverteilung eines Unternehmens innehaben. Durch ein geeignetes System von Berechtigungen kann die unerwünschte Erstellung oder Veränderung von Inhalten effektiv kontrolliert werden. 13 Mit Hilfe von Workspaces können ganze Arbeitsumgebungen für die Mitarbeiter vorgegeben werden. Die Live- Umgebung befähigt den entsprechenden Mitarbeiter, seine Artikel selbstständig zu publizieren. 14 Ein Lektor könnte so zum Beispiel die Artikel der Redakteure für eine Publikation freigeben oder eine nachträgliche Überarbeitung anfordern (Kollaborations-Fähigkeit). Desweiteren können neben den Backend- Nutzergruppen auch Frontend-Nutzergruppen definiert werden, damit nur autorisierte Besucher auf zugangsbeschränkte Webseiten-Bereiche zugreifen können. Datei- und Inhaltsarchivierung Dazu ist das Digital-Asset-Management (DAM) zu nennen: Es bietet erweiterte Funktionen zur Katalogisierung und Indexierung (Such- und Filtersystem) von veröffentlichungsfähigen Inhaltselementen an. Durch die Angabe von Metadaten sind diese auch durch Fremdsysteme auslesbar. Die Versionierung von TYPO3- Datensätzen erlaubt es, Änderungen von Datensätzen zu verfolgen und letztendlich auch rückgängig zu machen. Das Archivierungssystem des Content- Managements ist von dem Digital-Asset-Management abzugrenzen, da es nur die einfache Verwaltung beliebiger Inhalte betrifft. 15 Performance TYPO3 ist dynamisch. Alle Inhalte werden somit in Datenbanken gehalten und auf Abruf entsprechend erzeugt. Um die Serverlast bzw. Performance zu 11 Abk.: Localization-Manager 12 Vgl.: [AOE Media 2010] TYPO3-Funktionen für Unternehmen (Hrsg.) 13 [Torbek, Wüst 2006] TYPO3 Professionelle Webauftritte, S.14 14 Vgl.: [AOE Media 2010] TYPO3-Funktionen für Unternehmen (Hrsg.) 15 Vgl.: [AOE Media 2010] TYPO3-Funktionen für Unternehmen (Hrsg.)

11 erhöhen, wurde ein Caching eingeführt. Hierdurch werden sowohl Inhalte als auch vom System erzeugte Grafiken statisch gehalten, bis sich Veränderungen ergeben. 16 2.1.2 Installation und System-Konfiguration Die Anforderungen für die Installation von TYPO3 sind: ein einsatzfähiger Apache- Webserver mit PHP- und MySQL-Unterstützung. TYPO3 ist online in drei verschiedenen Paketen erhältlich: TYPO3-Source, TYPO3-Dummy oder TYPO3-Source+Dummy. Im Source sind erwartungsgemäß die Quelldateien vom TYPO3-Kern enthalten. Der Dummy enthält ein leeres Seiten-Gerüst mit zusätzlichen Konfigurationen und Dateien für die sofortige Verwendung von TYPO3. Diese Trennung ist sinnvoll, da die Update- Funktion durch Symlinks sich nur auf Kern-Dateien aus dem TYPO3-Source bezieht. Diese Symlinks erlauben den Wechsel zwischen beliebigen System-Versionen und schaffen damit eine uneingeschränkte Update-Fähigkeit für das laufende TYPO3- System. Leider ist diese Funktion zum Umschalten der Version nur unter Unix-Systemen verfügbar. Auf Windows-Systemen ist daher eine komplette Überschreibung der Kern- Dateien notwendig. Der folgende Abschnitt erläutert den Installationsablauf von TYPO3 anhand einer lokalen, virtuellen Webserver-Umgebung. Das frei verfügbare TYPO3-Paket mit zusätzlicher Dummy-Site, wird als Ordner in das Dokumenten-Verzeichnis des Webservers abgelegt. Über den Browser wird der entsprechende localhost gestartet und die index.php im TYPO3 Root-Verzeichnis geladen (zum Beispiel: http://localhost/typo3/index.php), welche die Anfrage an das Install Tool weiterleitet. Hierbei ist zu bemerken, dass in der besagten index.php nur Konstanten definiert werden und das tatsächliche Frontend-Rendering in der darin inkludierten index_ts.php stattfindet. Aus Sicherheitsgründen muss für die Aktivierung des Install Tools eine leere typenfreie Datei namens ENABLE_INSTALL_TOOL im Ordner typo3conf vorliegen. Außerdem ist es notwendig, Browser-Cookies aktiviert zu haben. Das im Browser dargestellte Install Tool ähnelt einem typischen Installations-Wizard aus Windows und bietet zwei Installations-Modi an: Der 123-Modus oder der Modus für fortgeschrittene Nutzer. Beide unterscheiden sich lediglich in der Angabe der optionalen Konfigurationen. Da es im 123-Modus auch nachträglich noch ohne weiteres möglich ist, sämtliche Konfigurationen vorzunehmen, erscheint es sinnvoll diesen Weg einzuschlagen. Zunächst werden Datenbankumgebungs-Parameter abgefragt, um 16 [Mittwald CM Service 2009 ] - Grundlagenwissen TYPO3 Version 4.2.x, S.27

12 TYPO3 damit zu verbinden. Diese Angaben sind ab sofort in Form von Arrays in der Datei localconf.php im Ordner typo3conf wieder zu finden. Ist keine leere TYPO3- Datenbank vorhanden, muss eine neue angelegt werden, um diese anschließend automatisch mit TYPO3-Datenbanktabellen füllen zu können. In der localconf.php befinden sich weitere Grundparameter und globale Variablen, wie zum Beispiel der Seitenname oder die Liste der installierten und geladenen Erweiterungen. Nach dieser kurzen Installations-Prozedur ist TYPO3 lauffähig und man kann sich mit dem Standard- Passwort im Backend einloggen oder weitere Konfigurationen vornehmen. Die erwähnten administrativen Konfigurationen sind auch aus dem Backend heraus definierbar. Für die Darstellung des Backends wird neben den Browser-Cookies auch aktiviertes JavaScript benötigt. Nach der Anmeldung durch die noch vorgegebenen Login-Daten erscheint schließlich das in drei Spalten aufgeteilte Backend Im Browser. Die linke Menü-Spalte hat die Auswahl der Haupt- und Submodule zum Inhalt. Für den derzeitig angemeldeten Administrator sind alle vorhandenen Hauptmodule einsehbar: Web, File, User tools, Admin tools und Help. Im Mittelbereich befindet sich, je nach ausgewähltem Modul, ein weiteres Navigations-Menü und rechtsseitig ist die eigentliche Arbeitsumgebung und Detailansicht angelegt. Um erneut die administrativen Konfigurationen des Install Tools zu erreichen, muss das Submodul Install unter dem Hauptmodul Admin tools ausgewählt werden. (siehe: Abb. 4) Abb. 4: Backend Ansicht des Install Tools von TYPO3 4.3

13 Wie der Name des Moduls Admin tools schon verrät, sollten nur ausgewählte Administratoren Zugriff auf diese Einstellungen haben. Die zu Beginn angelegte ENABLE_INSTALL_TOOL-Datei wird nach einer Stunde automatisch aus dem Ordner typo3conf gelöscht und ist hierfür weiterhin notwendig. Nach der Eingabe des Passworts, wird das Install Tool erneut mit folgenden Menüpunkten dargestellt: 1. Basic Configuration Dieses Feld enthält in PHP definierte Basis-Konfigurationen der Datei: typo3conf/localconf.php. Dazu gehören Datenbank-Einstellungen wie: User- Name, Password und Host. Außerdem existieren Einstellungen zu Bildverarbeitung, Mail-Server und Schreibrechten. 2. Database Analyzer Wie der Name vermuten lässt, dient dieser Menüpunkt der Analyse, Konfiguration und Manipulation der TYPO3-Datenbank. Darüberhinaus werden Hinweise zur TCA-Konfiguration 17 oder zu neuen Datenbank-Feldern gegeben. 3. Update Wizard Mit Hilfe der zur Verfügung gestellten Methoden können Anpassungen vorgenommen werden, um Änderungen zu beheben, die nicht rückwärtskompatible System-Updates nach sich ziehen. 4. Image Processing Hier ist eine Anleitung zur korrekten Einstellung für die verwendete Bildverarbeitungs-Software (ImageMagick oder GDLib) zu finden. 5. All Configuration Dieser Bereich enthält eine Auflistung und Beschreibung aller System- Konfigurationen, die im TYPO3_CONF_VARS-Array abgespeichert sind. 6. typo3temp/ Alle von TYPO3 erstellten temporären Dateien sind im Ordner typo3temp/ enthalten und können ebenfalls aus dem Install Tool heraus verwaltet werden. 7. Clean up database Der Clean Up Manager ist in der Lage, diverse Datenbank-Tabellen von unnützen Daten zu säubern. Dazu gehört zum Beispiel der Cache, der für den Schnellzugriff auf Bilder-Größen hochgeladener Bilddateien verwendet wird. 8. phpinfo() Es handelt sich um eine PHP-Funktion, mit der man aktuelle PHP- Statusinformationen auslesen kann. 17 Abk.: Table Configuration Array; Beschreibt, anhand eines PHP-Arrays, Datenbank-Tabellen, auf die TYPO3 zugreifen kann.

14 9. Edit files in typo3conf/ Hiermit ist eine Browser-Bearbeitung von Dateien aus typo3conf/ möglich. 2.1.3 TypoScript Das Anlegen von Seitenstruktur und Inhaltstypen ist weitestgehend selbsterklärend. Jedoch ist eine Seite in TYPO3 keine HTML-Datei, sondern ein einfacher Datensatz. Die Kontrolle dieser Datensätze erfolgt durch Templates in der Konfigurationssprache TypoScript. Templates sind in TYPO3 ebenfalls Datensätze und nicht mit HTML- Designvorlagen zu verwechseln. (siehe: Abb. 5) Abb. 5: Trennung von Layout, Inhalt und Steuerung (Quelle: [Net-Lab 2010]) TypoScript gehorcht im Backend auf eine Art Objektschreibweise, die durch Punkte getrennt wird: Objekt.Speicherposition.Eigenschaft = Wertzuweisung. Zuvor muss jedem Objekt ein entsprechender Typ auf die gleiche Art und Weise zugewiesen werden. Zur Ausgabe von Seiteninhalten ist also ein Template in der Wurzelseite notwendig, das auf die unterliegenden Seiten vererbt wird. Grundkonfigurationen wie zum Beispiel der Doctype werden im Konfigurations-Objekt config angegeben. Seiteninformationen, wie zum Beispiel die Navigation, befinden sich analog dazu im Seiten-Objekt page. Möchte man eine Designvorlage einbinden, muss der Pfad der CSS-Datei und des HTML-Templates im Seitenobjekt definiert werden. Der gewünschte Seiteninhalt kann dann im Seitenobjekt den Markern ###...### im HTML- Template zugeordnet werden. Dafür sind Angaben über Datenbanktabelle tt_content und Feldposition des Inhaltelements notwendig. Diese Feldpositionen 0, 1, 2 und 3 dienen als Selektoren und sind mit vorgeschriebenen Positionsnamen (mitte, links, rechts, rechts-außen) verknüpft, die der Redakteur später bequem auswählen kann. Eine weitere Besonderheit von TypoScript ist die Eigenschaft wrap, durch die angesteuerte Content-Objekte cobjects mit diversen HTML-Elementen umschlossen werden können.

15 Ein solches cobject kann zum Beispiel vom Typ Text sein und dann mit einem h3- Element umgeben werden. Ebenfalls sehr nützlich ist das cobject HMENU, das zur Definition von hierarchischen Menüstrukturen dient. Es bildet die Grundlage für verschiedene Menüobjekte, die eine automatisch angelegte Seitennavigation ermöglichen: Das TMENU erzeugt ein einfaches Textmenü und die Zustände eines GMENU sind dynamisch erzeugte Grafiken. Zusammenfassend dient TypoScript (TS) als Konfigurationssprache unter TYPO3 derart vielen Aufgabenbereichen, dass es schwer fällt, TypoScript einer expliziten Funktion zuzuordnen. Neben der erläuterten Trennung von Layout, Inhalt und Steuerung, fungiert TypoScript noch für weitere Aufgabenbereiche unter TYPO3. Sie wird genutzt, um TYPO3 und Erweiterungen zu konfigurieren, Templates zu konfigurieren und Marker zu ersetzen, Inhaltselemente wie z.b. Menüs dynamisch zu erstellen, Zusätzliche Funktionen und Klassen einzubinden, Grafiken zur Laufzeit zu erstellen, Backend-Konfigurationen vorzunehmen (TSConfig). 18 2.1.4 Systemarchitektur TYPO3 ist ein vollwertiges Komponentenframework, das der Erstellung von Webinhalten dient. Diese Modularität spiegelt sich in der Systemarchitektur (siehe: Abb. 6) durch folgende Komponenten wider: [ ] zum einen dem Systemkern, der sich auf einem Linux-Webserver mit symbolischen Links für mehrfache Installationen verwenden lässt. Dann stellen die Basisfunktionen die Funktionalität des Systems sicher, und die Entwicklungsschnittstellen (APIs) ermöglichen die Erweiterung des Systems und den einfachen Zugriff auf dessen Funktionen. So genannte Extensions (Erweiterungen) sind in großem Umfang bereits vorhanden und greifen auf Funktionen und Schnittstellen des Grundsystems zurück, um zusätzliche Funktionen bereitzustellen. Mit ihrer Hilfe kann dann eine speziell angepasste Konfiguration für ein Webprojekt geschaffen werden. Dies ist nur möglich, weil TYPO3 extrem modular aufgebaut ist. 19 18 [Opitz 2009] Konzeption und Entwicklung einer TYPO3-Erweiterung zur datenbankgestützten Formularerzeugung und -konfiguration, S.7 19 [Torbek, Wüst 2006] TYPO3 Professionelle Webauftritte, S.16

16 Abb. 6: Die Systemarchitektur von TYPO3 (Quelle: [Konert 2006], S.46) Aus der Systemarchitektur ist zu erkennen, dass es drei unterschiedliche Arten von Extensions gibt: System-Extensions, Backend-Module und Frontend-Plugins. Jede dieser Arten einer Extension stellt eine individuelle Erweiterung des TYPO3- Funktionsumfangs dar. System-Extensions (Abk.: Sysext) sind Erweiterungen, die schon fest im TYPO3-Kern integriert sind. Dazu gehört auch das Content-Management-System von TYPO3 (Sysext: CMS siehe: Abb. 6). Backend-Module sind Erweiterungen für die Redaktion im Backend. Sie sind in der Lage, sich in die vorhandene Benutzeroberfläche im Backend einzubetten. Frontend-Plugins können schließlich Inhalte im Frontend, also der dargestellten Webseite, manipulieren. Durch die Extension-API 20 wird eine Systemschnittstelle geschaffen, die eine uneingeschränkte Funktionserweiterung für den Kern ermöglicht. In dieser API werden alle Funktionen gekapselt, die für die Verwaltung der Extension notwendig ist. So finden sich hier Funktionen, die überprüfen, ob eine Extension bereits geladen ist oder wie der Pfad zu einer Extension genau lautet. [ ] 21 20 URL: http://typo3.org/fileadmin/typo3api-4.0.0/db/d23/classt3lib extmgm.html 21 [Ebner, Lobacher 2008] t3n, H.14, S.132, Teil2: Allgemeine APIs

17 Für eine individuelle Erweiterung bestehender Kern- oder Extension-Funktionalitäten existieren folgende Hilfsmittel: XCLASS Um aus einer Extension heraus eine vorhandene Klasse erweitern oder überschreiben zu können, ohne den Quellcode jener Klasse permanent zu verändern, wird am Ende dieser eigentlichen Klasse eine sogenannte XCLASS registriert. Instanziiert man die gewünschte Klasse über die dafür vorgesehene Methode t3lib_div::makeinstance(), kann die registrierte XCLASS-Klasse ohne Einschränkungen manipuliert werden. 22 Hooks Bei Hooks werden im Gegensatz zu XCLASS keine registrierten Klassen-Kopien zur Verfügung gestellt, sondern vom Entwickler fest definierte Bereiche (Methoden). Tritt eine Änderung der Ausgangsdatei ein, bleibt der Hook mit Sicherheit weiterhin einsatzfähig, sofern der Entwickler den Einsprungpunkt (Hook) nicht verändert hat. Services Services haben das gleiche Ziel wie Hooks oder XCLASS: Eine funktionale Erweiterung zu schaffen, ohne den vorhandenen Quellcode zu beeinflussen. Nur werden hier von TYPO3 vorgegebene Service-Typen registriert, damit TYPO3 die jeweilige Prozedur mit dem alternativen Programmcode ausführen kann. Eine auf diese Art und Weise registrierte TYPO3 Prozedur könnte zum Beispiel die komplette Nutzer-Authentifizierung darstellen. Die dabei anfallende Dienstgüte wird anhand einer prozentualen Angabe von Qualität und Priorität definiert und ausgewertet. 2.2 FLOW3-Technologie 2.2.1 Das Extension-Framework Extbase Vor der Veröffentlichung von TYPO3 4.3 haben sich Hilfsmittel wie der Kickstarter 23 und die Plugin-Basis-Klasse 24 bewährt, dem Extension-Entwickler eine nützliche Entwicklungsgrundlage zu bieten. In der Zeit moderner Programmier-Konzepte und Frameworks erscheint es jedoch veraltet und unpraktisch, den gesamten Programmcode 22 Vgl.: [Opitz 2009] Konzeption und Entwicklung einer TYPO3-Erweiterung zur datenbankgestützten Formularerzeugung und -konfiguration, S.18 23 Ein Installations/Konfigurations-Wizard, der für die Programmierung ein leeres Extension-Gerüst erstellt 24 URL zur Klassenreferenz: http://typo3.org/fileadmin/typo3api-4.0.0/df/d32/classtslib pibase.html

18 der Extension in nur einer Klassen-Datei zu verschachteln 25 und diese funktional lediglich um die entsprechende Basis-Klasse zu erweitern. Desweiteren hat sich gezeigt, dass die gewachsenen System-Strukturen von TYPO3 den modernen Anforderungen agiler Software-Entwicklung entgegen wirken. Das Entwickler-Team von TYPO3 hat sich letztendlich dafür entschieden, ein neues und zugleich zukunftsweisendes PHP- Framework für TYPO3 zu entwickeln, das die Vorteile etablierter Open Source PHP- Frameworks in sich vereint: FLOW3. Ein übersichtlicher Vergleich zu bekannten PHP- Frameworks ist online in Tabellen-Form verfügbar. 26 Momentan befindet sich die Entwicklung von FLOW3 noch in einer frühen Alpha-Phase. Die FLOW3-Integration und Fertigstellung von TYPO3 5 liegt daher noch auf einen unbestimmten Zeitraum. Die Projektabspaltung von FLOW3 ist darauf zurückzuführen, dass ein derart fortschrittliches Framework auch für eine systemunabhängige PHP-Entwicklung zur Verfügung gestellt werden sollte. Damit aktuell entwickelte Extensions auch in Zukunft mit TYPO3 5 kompatibel sind, wurde Extbase als technologischer Rückimport aus FLOW3 von Jochen Rau entwickelt und in den TYPO3 4.3 Systemkern integriert. Hierbei ist anzumerken, dass sowohl Extbase, als auch die Template Engine Fluid, als stabil deklariert sind, sich jedoch beide noch in Entwicklung befinden. 27 Extbase ist eine Systemextension (Sysext) die ein MVC-Framework für die Extension- Entwicklung bereitstellt. Der Einsatz einer Software-Architektur nach dem MVC- Paradigma (Model-View-Controller) dient hauptsächlich der Effizienz 28, Transparenz (Lesbarkeit und Verständlichkeit) und Flexibilität (Erweiterbarkeit) des Programmcodes. Diese Ziele werden durch eine modulare Programmstruktur ermöglicht, die eine komponentenweise Aufteilung in drei Einheiten aufweist: Modell (Model) Es handelt sich um ein Objekt, das ausschließlich Daten und Anwendungslogik (Application Logic 29 ) eines Aufgabenbereichs (Domäne) enthält. Präsentation (View) Diese Einheit ist nur für die Darstellung der Daten aus dem Modell verantwortlich. Steuerung (Controller) Der Controller interagiert mit Nutzereingaben, steuert den Datenfluss, löst Aktionen (Actions) aus, verwaltet Views und entscheidet, welches Modell zum Einsatz kommt. 30 25 Prozedurale-Programmierung (nicht-objektorientiert) führt zu ungeordneten Kontrollstrukturen, was der Flexibilität und Lesbarkeit schadet: Spaghetticode 26 URL: http://flow3.typo3.org/about/comparison/ 27 Vgl.: [Ross 2009] Get into FLOW3 with Extbase 28 Komplexität findet keine Rechtfertigung wenn Dinge einfach sein könnten ~ Leonardo Da Vinci 29 Beschreibt den funktionalen Informationsaustausch zwischen Datenbank und Nutzer-Schnittstelle

19 Extbase agiert hierbei als Vermittler (Dispatcher bzw. Main-Controller) zwischen der konventionellen und der neuen Software-Architektur. Ein typischer Programmablauf wäre eine Anfrage (Request) vom Dispatcher an den jeweiligen Controller, der das darauf bezogene Modell vorbereitet und entscheidet, welche Action ausgelöst wird. Jede Action besitzt als PHP-Methode genau eine View, an die das Modell übergeben wird. Abschließend reicht der Controller die erhaltene Antwort (Response) der View an das Frontend-Rendering von TYPO3 weiter. (siehe: Abb. 7) Abb. 7: Das Model-View-Controller Paradigma (Quelle: [Lemke, Dambekalns 2009], S.37) Der zweite konzeptionelle Grundpfeiler, der von FLOW3 geerbt wurde, ist das Domaindriven Design (DDD), das mit dem MVC-Framework auf einer schichtweisen Architektur (Layered Architecture) aufsetzt. (siehe: Abb. 8) Es handelt sich dabei um ein Architektur-Konzept, das es erlaubt, die Domäne in den Vordergrund komplexer Softwareprojekte zu stellen. Daraus resultiert eine verbesserte Abstimmung und Kommunikation zwischen Auftraggeber und Entwickler. Die Basis dafür bilden eine allgegenwärtige Sprache, die das Verständnis ausbaut und ein Modell, das als Objekt die Domäne in sich widerspiegelt und damit die Wirklichkeit repräsentiert: Domain Model. 31 Diese Reflektion wird erreicht, indem sich das Domänenmodell durch iterative Zyklen nach und nach der Realität annähert. Dabei ist es wichtig, dass das Modell in die Software-Architektur implementierbar ist. Das UML 32 -Klassendiagramm bietet dafür eine geeignete Darstellungsform. Um dem Extension-Entwickler eine geeignete grafische Benutzeroberfläche (GUI) für die Planung und Implementierung von Domänen- 30 Vgl.: [Lemke, Dambekalns 2009] - FLOW3 Framework, S.37 31 Vgl.: [Evans 2004] Domain Driven Design, S.3-4 32 Abk.: Unified Modeling Language

20 Beziehungen zu bieten, wird derzeit ein neuer Extbase Kickstarter 33 entwickelt. Wie von dessen Vorgänger gewohnt, wird auch der Extbase Kickstarter ein Extension- Grundgerüst vorbereiten können, das jedoch in diesem Fall nach den Regeln (Namenskonventionen und Verzeichnisstruktur) der MVC- und DDD-Architektur aufgebaut sein wird. Abb. 8: Die schichtweise Architektur des Domain Driven Designs von Extbase (Quelle: [Kurfürst 2009 c], S.36) Für das weitere Verständnis bietet es sich an, die Domäne als implementierte Software- Einheit zu durchleuchten: Hinter jedem Modell versteckt sich eine einfache PHP-Klasse (POPO 34 ), die es durch geeignete Eigenschaften und Methoden repräsentiert. Ist für das Modell eine umfassende Anwendungslogik notwendig, die einen Datenzugang voraussetzt, wird dieser über das Repository ermöglicht. Sobald dem Modell ein weiteres untergeordnet wird (Tochter-Modell), entsteht ein hierarchisch aufgebauter Sammelbehälter, der als Aggregat bezeichnet wird. Das Eltern-Modell stellt in diesem Kontext die Aggregat-Wurzel dar. All dies ist nach wie vor einer Domäne zugeteilt. 35 Nach den Prinzipien des Domain-driven Design arbeitet auch der aus FLOW3 rückportierte Persistence-Manager. Er ermöglicht es, Objekte, die hierarchisch nach ihrer jeweiligen Domäne miteinander verknüpft sind (Aggregat), automatisch zu persistieren. Somit werden alle Änderungen von Objekten (inkl. den Tochter-Objekten), die auf ein Repository aufsetzen, transparent beibehalten. Der Schlüsselpunkt dabei ist, dass man mit Objekten hantiert und über save()-methoden den Datenbankzugriff auslösen kann: Active Record Pattern 36. 33 URL: http://forge.typo3.org/projects/show/extension-extbase_kickstarter 34 Abk.: Plain Old PHP Object 35 Vgl.: [Lemke, Dambekalns 2009] - FLOW3 Framework, S.68 36 Ein Software-Modell das beschreibt, wie über CRUD-Funktionen (create, read, update, delete) ein Zugriff auf relationale Datenbanken erfolgt.

21 Folgende Abbildung zeigt das Aggregat einer Domäne der beispielhaften Blog-Extension vom Extbase-Entwickler Jochen Rau. Der Blog dient als Aggregat-Wurzel der Entitäten von Nachrichten (Posts). Dadurch können Änderungen über das Post-Repository dem jeweiligen Blog zugeordnet werden, der wiederum über das Blog-Repository persistiert wird. Abb. 9: Aggregat-Ansicht der Entitäten der Blog-Extension (Quelle: [Kurfürst 2009 c], S.92) Das FLOW3-Framework setzt sich aus zahlreichen Submodulen zusammen. Extbase hat neben MVC-Framework, DDD-Konzept und Persistence-Modul noch weitere Module des aktuellen Entwicklungsstands von FLOW3 übernommen: Object Manager Der Object Manager ist dafür zuständig, Objekte zu erstellen und deren Abhängigkeiten (über Dependency Injection 37 ) zueinander zu verwalten. Dabei existieren drei verschiedene Object Scopes 38 : Singleton (eine Obj.-Instanz), Prototype (normales Instanziieren) und Session (eine Obj.-Instanz, die an die Session gebunden ist). Der Session-Scope ist noch nicht implementiert, aber dafür vorgesehen. Reflection API Diese API erweitert die von PHP5 bereitgestellte Reflection 39 um das dokumentarische Abfragen von Kommentaren und Zwischenspeichern (Cached Reflection Service) der Reflection. 37 Reduziert starre Objekt-Abhängigkeiten, indem die gewünschte Instanz, dem Objekt injiziert wird. 38 Beschreiben die Verfügbarkeit und Zugänglichkeit von Daten, Methoden und Eigenschaften eines Objekts 39 Bietet eine API, die das zurückentwickeln (Reverse Engineering) von Klassen, Methoden und Interfaces ermöglicht

22 Security Framework Jegliche Sicherheits-Aspekte (z.b. Authentifizierung) werden zentral über das Security Framework verwaltet und über eine API zugänglich gemacht. Utility Module Es handelt sich um eine Klassen-Bibliothek, die Allzweck-Funktionen (z.b. für das Extension-Management) bereithält. Validation Module Dieses Modul enthält ein Framework für das Validieren und Filtern von Objekten, wobei auf vordefinierte und individuelle Regel-Muster zurückgegriffen werden kann. Error Module Hier finden Klassen Platz, die das Error- und Exception-Handling unterstützen. Property Module Das Property Module ist für das Setzen und Auslesen von Objekt-Eigenschaften zuständig. Configuration Framework Der Configuration Manager ist hierbei als zentrale Einheit dazu in der Lage, Konfigurationen zu definieren, kaskadieren und auszulesen. 40 2.2.2 Die Template-Engine Fluid Eine Template-Engine erweckt statische HTML-Templates zum Leben, indem es ermöglicht wird, Platzhalter mit Inhalten einer externen Datenquelle zu füllen. Die dafür notwendige Anwendungslogik übernimmt die Template-Engine (siehe: Abb. 10). Das klassische Templating mit TYPO3 ist von Markern und Subparts (siehe: Abschnitt 2.1.3) in der Designvorlage abhängig, was der Konsistenz im Template schadet. Im Gegensatz zu bekannten PHP-basierten Template-Engines (Smarty, PHPTAL, etc.), vereint Fluid folgende Eigenschaften: leicht verständliche Syntax, flexibel und einfach erweiterbar, objektorientierter Quellcode (PHP5) und strikte Trennung zwischen Layout und Steuerung (PHP-freies Template). 41 40 Vgl.: [Lemke, Dambekalms 2009] - FLOW3 Framework, S.1-2, S.10-11 41 Vgl.: [Kurfürst 2009 a] t3n, H.16, Fluid Templating leicht gemacht

23 Abb. 10: Die Template-Engine als zentraler Verarbeitungsprozess der View Fluid ist eine von Sebastian Kurfürst entwickelte Systemextension für TYPO3 4.3, die neben Extbase ebenfalls ihren Ursprung als Bestandteil im FLOW3-Framework hat. Dabei sind Extbase und Fluid eng miteinander verknüpft, denn Fluid stellt die Anwendungslogik der Template-View für das MVC-Framework von Extbase dar. Das bedeutet, Fluid erweitert die vorhandene View, die ausschließlich für das einfache Darstellen von Inhalten zuständig ist, um zusätzliche Kontrollmechanismen für das Template-Rendering. Dazu gehört zum Beispiel das Traversieren von Arrays und ganzen Objekten: Controller-Action (PHP-Datei): $array = array('key' => 'value', 'key2' => 'value2'); $this->view->assign('identifier', $array); Fluid-Template (HTML-Datei): <h3>{identifier.key2}</h3> Im PHP-Code-Beispiel wird das assoziative Array als Inhalt in die View gesteckt. Das erste Argument der assign()-methode dient dabei als Bezeichner, das zweite enthält das Daten-Array. Das der Controller-Action zugehörige Fluid-Template ist nun in der Lage, den gewünschten Key des übergebenen Arrays anhand einer punkteseparierten Notation ( { } - ähnlich JSON 42 -Notation) auszuwählen und den dazugehörigen Wert darzustellen. Hinter dieser neuen Anwendungslogik steckt ein Template-Parser von Fluid, der dem Rendering zwischengeschaltet ist. Wie erwähnt, ist Fluid auch dazu fähig, ganze Objekte zu traversieren: Das entsprechende Objekt wird wie gewohnt an die View übergeben. Dabei handelt es sich 42 Abk.: JavaScript Object Notation

24 vorzugsweise um ein Domänenmodell, das diverse Getter- und Setter-Methoden besitzt, die dessen Objekt-Eigenschaften repräsentieren. Der beispielhafte Ausdruck {identifier.objektname.objekteigenschaft} aus dem Fluid-Template ist daher gleichbedeutend mit dem Methoden-Aufruf: $objektname- >getobjekteigenschaft(). Diese Getter- und Setter-Methoden im Modell folgen einer Lower Camel Case 43 -Namenskonvention mit festgelegtem Präfix: get oder set. Je nach Domänen-Kontext können auch ganze Modell-Ketten im Aggregat vorliegen (siehe: Abb. 9). Um derartige Strukturen nach ihren Objekten und Eigenschaften zu iterieren, benötigt man die Kontrollstruktur einer Schleife. Jegliche Ausgabelogik wird bei Fluid über sogenannte ViewHelper realisiert, wobei hinter jedem ein XML-Element steckt, das wiederum einer PHP-Klasse aus dem Fluid-Core zugeordnet ist. Die Tatsache, dass ausschließlich Tags in der View benötigt werden, führt zu einem einheitlichen und übersichtlichen Template-Aufbau, zu dessen Verständnis keine direkten Programmierkenntnisse notwendig sind. Der For-ViewHelper <f:for> verhält sich als Kontrollstruktur im Fluid-Template wie eine PHP-Foreach Schleife. Die folgende Foreach-Kontrollstruktur stellt die Eigenschaften der vorhandenen Tochter-Objekte, in Form einer Liste dar: <ul> <f:for each="{parentobject.objects}" as="object"> <li>{object.eigenschaft}</li> </f:for> </ul> Außerdem ist es möglich eigene ViewHelper zu entwickeln, falls die schon vorhandenen nicht ausreichen sollten. Fluids ViewHelper besitzen dafür einen eigenen Namensraum (ähnlich XML-Namespace), der durch das Präfix f gekennzeichnet und standardmäßig implementiert wird. Durch das Implementieren eigener Namensräume ist es damit unmöglich, vorhandene ViewHelper mit eigenen zu überschreiben. Um sich wiederholende Template-Strukturen zu minimieren, existiert die Möglichkeit, Template- Layouts zu schreiben. Diese enthalten neben dem Standard-Layout einen Render- ViewHelper, dessen Section-Attribut die darzustellende Sektion aus dem Ziel-Template kennzeichnet. Abschließend muss auf den Zielseiten noch deklariert werden, um welches Layout-Template es sich handelt <f:layout name="..." /> und welche Sektion davon im Ziel-Template betroffen ist. 44 43 Camel-Case ist eine Trenn-Schreibweise für zusammengesetzte Wörter: lowercamelcase, UpperCamelCase 44 Vgl.: [Kurfürst 2009 b] Fluid Templating System, S.3, S.5-6

25 <f:section name="inhalt">...</f:section> Unter den Kontrollstrukturen existiert noch der sehr nützliche If-ViewHelper <f:if>, der mit dem Then- und Else-ViewHelper verschachtelt werden kann. Für diese If/Else- Bedingungen sind nur boolesche Ausdrücke miteinander vergleichbar. Neben den Link-ViewHelpern <f:link.email> und <f:link.external>, erlaubt es der ViewHelper <f:link.action> Links an Controller-Actions anzugeben. Ebenso können GET/POST-Parameter eines Formulars durch den Form-ViewHelper an beliebige Actions gesendet werden. Der Zugriff auf Sprach-Labels (XML-Format) ist über den Translate-ViewHelper möglich. Dadurch liegt eine simple und zugleich systemumfassende Lösung für die Mehrsprachigkeit in Extension-Templates vor. Hinter diesen und weiteren ViewHelpern steckt das Kernkonzept von Fluid, das dem Template-Designer eine weitreichende Anwendungslogik in Form von leicht verständlichen XML-Tags anbietet.

26 3 Analyse vorliegender Datenzugänge 3.1 SugarCRM-Webservice 3.1.1 Modul- und Datenstruktur SugarCRM ist als CRM-System eine Groupware 45 -Software, die das Unternehmens- Management unterstützt. Grundsätzlich fördert eine CRM-Software wie SugarCRM die Effizienz beim Einpflegen, Warten und Organsieren von Informationen über Kundenbeziehungen. 46 Für das Kundencenter stellen diese vom Projektmanagement verwalteten Kundenbeziehungen eine externe Datenquelle dar. Diese Daten liegen in der SugarCRM-Datenbank vor (siehe: Abschnitt 1.2). Aufgrund dessen ist es notwendig, den Sinn und Zweck der Daten zu verdeutlichen die für den Kundencenter relevant sind. Um die Datensätze zu verwalten, die für das Kundenbeziehungsmanagement anfallen, ist die Hauptnavigation der grafischen Benutzeroberfläche in verschiedene Hauptmodule unterteilt, die jeweils einen eigenen Arbeitsbereich repräsentieren: Verkauf, Marketing, Support, Aktivitäten, Kollaboration, etc. Hinter jedem der erwähnten Hauptmodule verstecken sich Submodule, die Formularfelder für die Datenerfassung und Werkzeuge für die Verwaltung und statistische Auswertung von Kundenbeziehungen und Projektaufträgen darstellen. Jedes Hauptmodul enthält als Arbeitsoberfläche verschiedene Teilbereiche (Sub-Module), die wiederum bestimmte Datenbereiche der Kundenbeziehungen repräsentieren. Diese Modul-Unterteilung spiegelt sich darüberhinaus auch in der Datenbankstruktur von SugarCRM wider, deren Tabellennamen sich größtenteils auf diese Sub-Module beziehen. Einen solchen Datenbereich kann zum Beispiel das Kontakt-Modul (Contacts) darstellen, das im Gegensatz zum Firmen-Modul (Accounts) nur Daten. eines Kunden als individuellen Geschäftspartner (Person) enthält. Dennoch kann dieser Kunde zu einer Firma gehören oder in Projekte involviert sein, was letztendlich die eigentliche Kundenbeziehung ausmacht, die auf einfachen Verknüpfungen zu anderen Modulen basiert (Relationships). Folgende Sub-Module sind dahingehend von Bedeutung, relevante Datenquellen für das Kundencenter abzugeben: 45 Eine Bezeichnung für eine Software, die für die kooperative Zusammenarbeit einer Gruppe von Menschen entwickelt wurde. 46 Vgl.: [Whitehead 2006] Implementing SugarCRM, S.17

27 Leads Leads stellen Interessenten oder einfache Kontakte dar, aus denen sich nach einer ausführlichen Auftragsanalyse Geschäftspartner (Contacts), Auftraggeber bzw. Unternehmen (Accounts) oder Geschäfts-Gelegenheiten (Opportunities) entwickeln können. Contacts Contacts sind individuelle Kontaktpersonen (ehemalige Leads), die sich als potentielle oder etablierte Geschäftspartner herausgestellt haben. Diese können mit beliebigen Modulen verknüpft werden, wie zum Beispiel: Accounts, Opportunities oder Campaigns. Damit stellt dieses Modul die ideale Nutzerprofil- Datenquelle für mögliche Endnutzer des Kundencenters dar. Accounts Die unter diesem Modul verwalteten Daten beziehen sich ausschließlich auf Kunden-Daten, wobei hier als Kunde der Auftraggeber bzw. das Unternehmen zu verstehen ist. Dazu gehören zum Beispiel Daten wie die Adresse zur Rechnungsstellung oder eine Unternehmens- bzw. Geschäftsfeld-Beschreibung. Opportunities Opportunities sind Verkaufs-Gelegenheiten, die auf maximal einen Account und beliebig viele Leads und Contacts bezogen werden können. Diese Modul-Daten beschreiben also die Chance auf eine möglichst gewinnbringende Geschäftsbeziehung. Cases Hier werden Probleme und Änderungswünsche gelistet, die den Service betreffen und von Kunden angegeben wurden. Es handelt sich also um eine Art Issue- Tracker 47 für nicht-technische Aspekte. Bug Tracker Wie der Name schon verrät, dient dieses Modul als Bug-Tracker dem Auflisten, Rückverfolgen und Verwalten von Produktfehlern. Campaigns Hier können umfassende Marketing-Kampagnen verwaltet und rückverfolgt werden. Projects Dieses Modul erlaubt es, Unternehmens-Projekte zu verwalten. Jedem Projekt muss ein SugarCRM-Nutzer als Projektmanager zugeteilt werden. 48 47 Mit diesem Software-Werkzeug können Issues (projektbezogene Anliegen) zurückverfolgt, dokumentiert und verwaltet werden 48 Vgl.: [SugarCRM Inc. 2008] Sugar CE User Guide, S.47, S.53, S.56, S.60-65, S.94, S.117

28 3.1.2 SOAP-RPC Die im vorherigen Kapitel 3.1.1 erläuterten SugarCRM-Module basieren auf systeminternen Datenmengen von SugarCRM, auf die extern (Kundencenter) nur über einen Webservice zugegriffen werden kann. Daher bietet SugarCRM mit Hilfe eines SOAP 49 -Webservices eine standardisierte Schnittstelle an, die anderen Servern oder Systemen öffentlich zugängliche SugarCRM-Anwendungen zur Verfügung stellt. Die Kommunikation zwischen Anbieter (Remote-Server mit Webservice) und Konsument (lokaler Server) erfolgt demnach komplett auf Serverebene. Sowohl SOAP als auch HTTP 50 gehören zu den Envelope-Protokollen, die Kopf (Header) und Körper (Body) mit einer Art Umschlag umschließen. Dabei kann SOAP als Kommunikationsprotokoll im Körper eines jeden Transfer-Protokolls versendet werden, da es transportunabhängig ist. Der hauptsächliche Datenverkehr von SOAP-Protokollen geschieht jedoch auf dem HTTP-Protokoll. Das bedeutet, dass der komplette SOAP- Envelope im HTTP-Körper enthalten ist. Voraussetzung dafür ist, dass der Inhalt des SOAP-Körpers auf XML basiert. Die Kombination aus HTTP-Nachricht mit XML- Dokument führt zu einer äußerst hohen Kompatibilität, denn jede Firewall kennt das HTTP-Protokoll und jeder Parser ist in der Lage, XML zu lesen. 51 Aus diesem Grund wurde SOAP entwickelt, denn veraltete RPC 52 -Services, die auf HTTP aufsetzen, verursachen ein Sicherheitsrisiko und damit verbundene Inkompatibilitäten. Trotz der HTTP-Kompatibilität enthält der SOAP-Envelope Definitionen im XML-Format, die einem RPC-Aufruf gleichen. Diese Ähnlichkeit zu XML-RPC führte zur Zusatz- Bezeichnung: SOAP-RPC. Von daher orientiert sich der Service an Informationen im Dokument anstatt auf dem Envelope. Der Datenaustausch erfolgt zudem durch individuelle Methoden über den POST 53 -Parameter innerhalb einer einzigen URI 54, wodurch keine Orientierung an der jeweiligen Ressource verfolgt wird, was charakteristisch für RPC-Verbindungen ist (siehe: Abb. 11). Im Gegensatz dazu verfolgt ein RESTful 55 - Webservice eine Software-Architektur, in der jede Ressource einer eindeutigen URI zugeordnet ist. 56 49 Abk.: Simple Object Access Protocol bzw. SOAP; URL: http://w3.org/tr/soap 50 Abk.: Hypertext Transfer Protocol 51 Vgl.: [Krause 2004] PHP5 Webserverprogrammierung unter Windows und Linux, S.819-822 52 Abk.: Remote Procedure Call; Zwischenanwendung (Middleware) die im Client-Server-Modell einen Aufruf ferner, spezialisierter Funktionen ermöglicht 53 Eine HTTP-Request-Methode für die Übertragung von Ressourcen zu einem Server über eine URI. 54 Abk.: Uniform Resource Identifier 55 Abk.: REpresentational State Transfer full; Ein Webservice der den Anforderungen gerecht wird, die das REST-Modell vorschreibt: repräsentativer, statusloser und generischer Datentransfer unter Einsatz etablierter Web Standards 56 Vgl.: [Richardson, Ruby 2007] RESTful Web Services, S.19, S.303

29 Abb. 11: Routing von SOAP-Nachrichten durch den HTTP-POST (Quelle: [Bayer 2002], S.5) Weiterhin missachtet SOAP-RPC die vorhandenen Möglichkeiten, die HTTP zum Beispiel für die Authentifizierung oder das Zwischenspeichern anbietet. Derartige HTTP- Funktionen müssen vom Entwickler selbstständig durch neue Vereinbarungen (Methoden) nach-entwickelt werden. Dieser Umstand ist auf den permanenten Transport der Methoden und Operationen über den POST-Parameter zurückzuführen. Sicherheitsaspekte, wie zum Beispiel die Beschränkung des lokalen Zugriffs auf den GET-Parameter (nur Lesezugriff), sind dadurch unmöglich. SOAP-Nachrichten werden mit einer vermittelten URI übertragen, wodurch für einen Router jedes HTTP-Paket vollkommen identisch aussieht. Eine Filterung über Router-Protokolle ist daher auch nicht möglich. Deshalb werden SOAP-Nachrichten von immer mehr Routern blockiert. 57 Folgende Syntax-Regeln sind laut W3C 58 für eine SOAP-Nachricht einzuhalten: muss über das XML-Format kodiert sein muss einen SOAP-Envelope Namensraum besitzen muss einen SOAP-Encoding Namensraum besitzen darf keine Verarbeitungs-Anweisungen (Processing Instructions) enthalten darf keine DTD 59 -Deklarationen (z.b.: DOCTYPE) enthalten 57 Vgl.: [Bayer 2002] - REST Web Services, S.4-5 58 Abk.: World Wide Web Consortium; Gremium für die Standardisierung von Web-Technologien 59 Abk.: Document Type Definition