DIPLOMARBEIT. HTBLuVA Dornbirn Höhere Lehranstalt für Wirtschaftsingenieurwesen Ausbildungsschwerpunkt Betriebsinformatik. Schullogo.

Transkript

1 Schullogo HTBLuVA Dornbirn Höhere Lehranstalt für Wirtschaftsingenieurwesen Ausbildungsschwerpunkt Betriebsinformatik DIPLOMARBEIT HeartBeat Visualizer Ausgeführt im Schuljahr 2008/09 von: Betreuer: Balter Martin Kuschny Daniel Müller Markus 5aI 5aI 5aI Prof. DI Diethard Kaufmann Dornbirn, am

2 inet-logistics HEARTBEAT VISUALIZER Diplomarbeit Balter Martin, Kuschny Daniel, Müller Markus Balter Martin, Kuschny Daniel, Müller Markus Seite 2 / 100

3 1 Vorwort Ziel des HeartBeat Visualizers ist es, eine innovative Visualisierung der bei inet-logistics anfallenden Log- und Monitor-Daten zu erzielen und gleichzeitig die Analyse- und Recherchemöglichkeiten zu optimieren. Der erste Teilbereich stellt der HeartBeat Visualizer dar. In diesem Bereich des Projektes wird die Weboberfläche mit einem Benutzersystem erstellt. Des weiteren ist der HeartBeat Visualizer durch Module dynamisch erweiterbar und durch ein eigenes Konfigurationssystem kann der HBV den individuellen Bedürfnissen angepasst werden Der HeartBeat Analyzer ist der zweite Teilbereich dieses Projektes. Das Ziel in diesem Bereich ist es, detaillierte Analyse- und Auswertungsfunktionen anzubieten. Es soll dem Mitarbeitern möglich sein, über diverse Suchkriterien Probleme und Transaktionen auf den Applikationen von inet-logistics zurückzuverfolgen, welche in einer übersichtlichen und strukturierten Darstellung aufbereitet werden. Des weiteren wird der HeartBeat Diamond umgesetzt. Im HeartBeat Diamond wird eine optische Visualisierung der eingehenden Log- und Monitor-Daten der inet-logistics Applikationen umgesetzt. Ein Hauptpunkt hierbei wird sein, diese Log-Daten zu verknüpfen und zweckgemäß darzustellen. Ziel der Visualisierung ist es, anhand der eingehenden Log-Daten darzustellen, wie stark die Applikationen zurzeit belastet werden und in welchen Bereichen diese Last auftritt. Balter Martin, Kuschny Daniel, Müller Markus Seite 3 / 100

4 2 Danksagung Wir, das Projektteam, bedanken uns bei unserem Projektbetreuer Prof. DI Diethard Kaufmann, der unser Projekt mit Leib und Seele betreut hat. Seitens der Schule HTL Dornbirn, und dem Unternehmen inet-logistics, stand Herr Kaufmann immer an unserer Seite und half uns bei den Problemen, die während der laufenden Arbeit entstanden sind. Weiters möchten wir uns beim Unternehmen inet-logistics bedanken, dass uns dieses Projekt ermöglicht hat. Zusätzlich möchten wir uns bei den Mitarbeitern von inet-logistics bedanken, die uns hilfreiche Tipps und Tricks zur Verfügung gestellt haben und ebenso die firmeninternen Arbeiten, die für das Projekt relevant waren, erledigten. Nicht zu vergessen sind auch unsere Eltern, die uns in jeder Hinsicht unterstützt haben und somit die Arbeiten am Projekt gefördert haben. Balter Martin, Kuschny Daniel, Müller Markus Seite 4 / 100

5 3 Preface The aim of the HeartBeat Visualizer is an innovative visualization of the arising log files. Also important is to optimize the analyse and the search function. The first part of the project is the HeartBeat Visualizer. In this part of the project the web surface and the user system is going to be created. Furthermore, the HeartBeat Visualizer is dynamically expandable with modules and with an own configuration system it is possible to adapt the HBV for your own requirements. (i.e. database linkage) The second part of the project is the HeartBeat Analyzer. The aim of this part is to develop a web surface, which provides analyzing functions for the produced log information by the applications of inet-logistics. The user is able to search with different filter criteria and so it allows him to have a look at the problems or actions, which accrue. Furthermore, the HeartBeat Diamond is going to be created in the third part. There we implement an optical visualization of the incoming log files. A principal point is to link the log and monitor files and to show these files convenient. With the HeartBeat Diamond, the user is able to see how the application is strained and where this load comes from. Balter Martin, Kuschny Daniel, Müller Markus Seite 5 / 100

6 4 Acknowledgement Our project team, would like to thank our project tutor, Prof. DI Diethard Kaufmann, who assisted our project. On the part of the school, HTL Dornbirn, and on the part of the company, inet-logistics, Diethard Kaufmann assisted us and helped us solving problems, which occurred during the work on the project. Furthermore, we would like to thank the company inet-logistics, which helped us to realize this project. Collateral, we would like to thank the colleagues of inet-logistics, which shows us helpful tips and tricks and also made in-house operations, which were relevant for the project. Not to forget is to say thanks to our parents which helped us in every way and so they made it possible to make a good project. Balter Martin, Kuschny Daniel, Müller Markus Seite 6 / 100

7 5 Inhaltsverzeichnis 1 Vorwort Danksagung Preface Acknowledgement Inhaltsverzeichnis Impressum Projektteam Markus Müller Martin Balter Daniel Kuschny Projektbetreuer Prof. DI Diethard Kaufmann Das Unternehmen Eidesstattliche Erklärung Phasenkonzept Projektorganisation Dokumentenstandards Projektsitzungen Zeitlicher Ablauf Soll-Zeitplan Ist-Zeitplan Vorphase Ist-Analyse Soll-Konzept Muss-Kriterien Wunsch Kriterien Entwurf Allgemein Realisierung Allgemein HBV HeartBeat Visualizer Allgemein HeartBeat Analyzer HBD HeartBeat Diamond Allgemein Testphase Balter Martin, Kuschny Daniel, Müller Markus Seite 7 / 100

8 9.7.1 Testphase vor PreAlpha Release Testphase vor Beta Release Testphase vor Release Candidate Testphase vor Final Release Tests bei inet-logistics Einführung und Wartung Einführung Prototyp PreAlpha Beta Release Candidate Final Wartung Hilfsmittel Software Entwicklungssoftware Dokumentations- und Projektmanagementsoftware Designsoftware Technologien Bibliotheken Hardware Entwicklungssystem Meilensteine und Projektablaufplan Meilensteinplan Projektablaufplan Glossar Abbildungsverzeichnis Literatur-und Quellenverzeichnis Literatur Quellen Balter Martin, Kuschny Daniel, Müller Markus Seite 8 / 100

9 6 Impressum 6.1 Projektteam Abbildung 6-1 Projektteam Balter Martin, Kuschny Daniel, Müller Markus Seite 9 / 100

10 6.1.1 Markus Müller Markus Müller nahm die Position des Projektleiters ein. Er koordinierte den gesamten Projektablauf und war Schnittstelle zwischen Projektbetreuer und dem Projekt. Neben seiner grundlegenden Tätigkeit als Projektmanager war Markus Müller zusätzlich am Design und in der Programmierung tätig Martin Balter Martin Balter war für die gesamte Datenbankverwaltung zuständig. Dazu gehörte das Pflegen der Daten von inet-logistics sowie die Aufrechterhaltung der Datenbank. Ebenso war er bei der Programmierung und beim Design tätig Daniel Kuschny Daniel Kuschny war in der Programmierung tätig. Bei entwicklungsspezifischen Fragen war er eine wichtige Ansprechperson im Team. Ebenso initialisierte er den HeartBeat Diamond und half beim Design mit. 6.2 Projektbetreuer Prof. DI Diethard Kaufmann Prof. DI Diethard Kaufmann nahm die Verantwortung des Projektbetreuers seitens der HTL Dornbirn sowie seitens des Unternehmens inet-logistics auf sich. Durch seine langjährige Erfahrung als Lehrer und Programmierer, konnte er uns durch seine kompetente und hilfsbereite Art jederzeit Hilfestellung leisten. Balter Martin, Kuschny Daniel, Müller Markus Seite 10 / 100

11 7 Das Unternehmen Abbildung 7-1 Firmenlogo inet-logistics Firma: inet-logistics GmbH Adresse: Holzriedstraße Wolfurt Tel: +43 (0) Fax: +43 (0) Homepage: Die inet-logistics in Wolfurt hat sich auf die Entwicklung und Vermarktung innovativer Softwarelösungen für Supply Chain Execution, d.h. für die Planung, Steuerung und Durchführung unternehmensübergreifender Logistikprozesse, spezialisiert. Diese Aufgaben werden auf Basis der von inet-logistics entwickelten Solution-Suite logisticsserver gelöst. Diese Internet Plattform wird in hochverfügbaren Rechenzentren betrieben und kann von allen Kunden im Internet genutzt werden. Diese Services erfordern eine komplexe Infrastruktur von Software und Hardware. Alle diese Systeme erzeugen zahlreiche Informationen, welche wertvolle Informationen über Normal- als auch Ausnahmezustände beinhalten. Balter Martin, Kuschny Daniel, Müller Markus Seite 11 / 100

12 8 Eidesstattliche Erklärung HeartBeat Visualizer Ich versichere, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe angefertigt und mich keinen anderer, als der im beigefügten Verzeichnis angegebenen Hilfsmittel bedient habe. Alle Stellen, die wörtlich oder sinngemäß aus Veröffentlichungen entnommen wurden, sind als solche kenntlich gemacht. Dornbirn, am Unterschrift: Dornbirn, am Unterschrift: Dornbirn, am Unterschrift: Balter Martin, Kuschny Daniel, Müller Markus Seite 12 / 100

13 9 Phasenkonzept 9.1 Projektorganisation In der Zeit vom 4. August 2008 bis 9. August 2008, wurde uns, Balter Martin, Kuschny Daniel und Müller Markus, die Möglichkeit gegeben, eine Woche bei inet-logistics zu arbeiten. Die hauptsächlichen Arbeiten in dieser Zeit waren die genaue Erfassung der Problemstellung, das Befragen betreffender Mitarbeiter, sowie die Erstellung von Dokumenten bzw. Dokumentenstandards. Durch diese intensive Arbeitswoche wurde uns ein guter Projektstart ermöglicht und wir konnten somit Anfang September mit der Umsetzung beginnen Dokumentenstandards Um ein einheitliches Erscheinungsbild zu schaffen, wurden Dokumentenstandards erstellt. Dieser Standard wurde in allen Dokumenten verwendet wie beispielsweise dem Pflichtenheft und den Präsentationen. Beispiel Dokumentenstandard Abbildung 9-1 Dokumentenstandards Balter Martin, Kuschny Daniel, Müller Markus Seite 13 / 100

14 Auf der linken Seite der Grafik Abbildung 9-1 Dokumentenstandard sehen Sie das Deckblatt eines jeden Dokumentes. Um die Vorlage anzupassen, muss der Ersteller des Dokumentes den Titel bzw. das Thema des Dokumentes und seinen Namen in die bereits vordefinierten Felder eingeben Projektsitzungen Regelmäßige Projektsitzungen halfen uns dabei, neue Aufgaben und Ziele zu definieren und die bereits erledigten Arbeiten zu besprechen. Ebenso wurde die Kommunikation zwischen dem Projektteam und dem Auftraggeber durch diese Sitzungen gepflegt. Beispiel eines Sitzungsprotokolls Abbildung 9-2 Sitzungsprotokoll Balter Martin, Kuschny Daniel, Müller Markus Seite 14 / 100

15 Sitzungsprotokollübersicht Datum Ort Anwesende Tätigkeit HTL Dornbirn Kaufmann, Balter, Kuschny, Müller Termin für Woche bei inet-logistics fixieren 1 Präsentation bei inetlogistics (Termin ausmachen) Wolfurt Kaufmann, Balter, Projektmanagement Kuschny, Müller Wolfurt Kaufmann, Balter, Kuschny, Müller, Martin Lampert Wolfurt Kaufmann, Balter, Kuschny, Müller, Thomas Abbrederis Wolfurt Kaufmann, Balter, Kuschny, Müller HTL Dornbirn Kaufmann, Balter, Kuschny, Müller Wolfurt Kaufmann, Balter, Kuschny, Müller, Thomas Abbrederis, Martin Lampert HTL Dornbirn Kaufmann, Balter, Kuschny, Müller besprechen Interview mit Mitarbeiter Wunschkriterien aufnehmen Sonstige Fragen klären Interview mit Mitarbeiter Wunschkriterien aufnehmen Genaue Featurespezifikation Projektmanagement Sonstige Fragen klären Präsentation für besprechen Teilnahme an Jugend Innovativ besprechen Weitere Vorgehensweise Vorstellung 1. Release Vorstellung d. Design Besprechung Projektplan Besprechung vorhandener Funktionen Informationen für Weiterentwicklung Balter Martin, Kuschny Daniel, Müller Markus Seite 15 / 100

16 9.1.3 Zeitlicher Ablauf In den nachfolgenden Zeitplänen werden die groben Phasen mit den zugehörigen Terminen veranschaulicht Soll-Zeitplan Im Soll-Zeitplan wird ersichtlich, wie wir uns den Verlauf des Projektes vorgestellt haben. Dieser wurde am Anfang des Projektes erstellt. Abbildung 9-3 Soll-Zeitplan Ist-Zeitplan Im Ist-Zeitplan wird ersichtlich, wie das Projekt schlussendlich verlaufen ist. Dieser wurde am Ende des Projekts erstellt. Abbildung 9-4 Ist-Zeitplan Balter Martin, Kuschny Daniel, Müller Markus Seite 16 / 100

17 9.2 Vorphase Durch eine Ausschreibung von inet-logistics wurden wir auf das Projekt HeartBeat Visualizer aufmerksam. Eine Präsentation des Projektes durch unsere BIBI Professoren, Prof. DI Kaufmann Diethard und Prof. DI Battlogg Klaus, welche bei inet-logistics angestellt sind, gab uns die letzte Bestätigung, dass wir dieses Projekt annehmen und umsetzen möchten. Nach diversen Abklärungen mit Prof. DI Diethard Kaufmann, bekamen wir auch von seiner Seite sowie Seitens inet-logistics die Zusage für das Projekt. So machten wir uns bereits Anfang August an die Arbeit. Wir waren vom 4. August 2008 bist 9. August 2008 bei inet-logistics im Betrieb tätig und hatten so die Möglichkeit das Projekt genauer zu erforschen und die Mitarbeiter persönlich zu befragen. In diesem Zeitraum wurden von uns das Pflichtenheft, die Dokumentenstandards sowie die Präsentationsvorlagen erstellt und ebenfalls Designs und ein Logo erarbeitet. Durch diese intensive Woche wurde uns ein guter Start ermöglicht und somit konnten wir schon Anfang September mit der eigentlichen Umsetzungen beginnen. Ausschreibung HTL Ingenieurprojekt Ausschreibung HeartBeat Visualizer Die inet-logistics GmbH in Wolfurt hat sich auf die Entwicklung und Vermarktung innovativer Softwarelösungen für Supply Chain Execution, also für die Planung, Steuerung und Durchführung unternehmensübergreifender Logistikprozesse spezialisiert. Diese Aufgaben werden auf Basis der von inet-logistics entwickelten SolutionSuite logistics-server gelöst. Diese Internetplattform wird in hochverfügbaren Rechenzentren betrieben und kann von allen Kunden via Internet genutzt werden. Diese Services erfordert eine komplexe Infrastruktur von Software und Hardware. Alle diese Systeme erzeugen zahlreiche Informationen, welche wertvolle Informationen sowohl über Normal als auch Ausnahmezustände beinhalten. Ziel des Projektes ist es, eine innovative Visualisierung dieser Informationen zu erzielen und gleichzeitig die Analyse und Recherchemöglichkeiten zu optimieren. Aufgaben: Logfile Collection Sammlung von LogFiles von unterschiedlichen Systemen Logfile Transformation Balter Martin, Kuschny Daniel, Müller Markus Seite 17 / 100

18 Transformation in ein zentrales Filesystem oder in eine Datenbank o Verknüpfung von zusammenhängenden LogEreignissen (ServiceÜbergreifende Aktivitäten) o Suche / Auswertungsmöglichkeit über die gesammelten LogDaten über ein GUI (z.b. WebApplikation) Zeitliche Suche Auswertungen/Suche nach BenutzerAktivitäten Auswertungen/Suche nach klassifizierten Fehlern Suche nach eindeutigen ID s (z.b. SessionID, ThreadID, AuftragsID s ) Volltextsuche (SearchEngine oder DB) Logfile Visualization Visualisierung von Log-Ereignissen von mehreren Servern bei inet-logistics aus dieser Visualisierung soll der aktuelle HealthStatus aller Services bei inetlogistics ersichtlich sein (Benutzeraktivitäten, Fehlerereignisse, Abweichung vom Normalbild ) Es soll optisch einen Gesamteindruck zu bekommen sein, was auf den Servern gerade los ist (d.h. im Normalbetrieb gibt es ein bestimmtes Muster, wenn viele Warnings, Errors oder Fatal Meldungen kommen, wird das entsprechend graphisch aufbereitet und bemerkt). Die Visualisierung soll an einem zentralen Ort bei inet-logistics laufend über einen Monitor gezeigt werden. Literatur / Quellen: [1] Peter Siering, Blinkenlogs c t 3/08, Seite 75 [2] LogFile Visualisierung mit gltail.rb siehe [3] log4j / Apache Logging Services [4] Chainsaw GUIbased Log viewer Kontakt: Günther Kapfer Holzriedstr: 29 A6961 Wolfurt guenther.kapfer@inet-logistics.com Phone: Balter Martin, Kuschny Daniel, Müller Markus Seite 18 / 100

19 9.3 Ist-Analyse Die Fehlersuche bei inet-logistics stellt eine zeitraubende und mühevolle Arbeit, welche von den Mitarbeitern ungern bearbeitet wird, dar. Das Analysieren der Fehler erfolgt in folgenden Schritten: Zugriff per FTP auf den zutreffenden Server bei dem der Fehler aufgetreten ist Ermitteln des Zeitraums durch Kontrolle der Logfiles o Problem Jedes Logfile ist 100MB groß und somit muss nach dem Zeitraum, in dem der Fehler aufgetreten, ist zuerst gesucht werden Ermitteln der Aktion bei welcher der Fehler aufgetreten ist o Beispiel eines Log-Eintrages " :44:05,497";"INFO";"LS_WWW-QueueWorker- 4";";;";"gw.prj.lose.ldl.BeauftragungDefault";"TransactionId= Daten transfer ans FreightBilling abgeschlossen..."; Analysieren des Problems Ermitteln zugehöriger Log-Daten Behebung des Problems o Benachrichtigen betreffender Mitarbeiter 9.4 Soll-Konzept Die Firma inet-logistics gab den Auftrag, eine innovative Visualisierung der anfallenden Log-Daten zu ermöglichen (HeartBeat Diamond) und gleichzeitig die Analyse- und Recherchemöglichkeit zu optimieren (HeartBeat Visualizer). Da ein derartiges Projekt noch nicht behandelt wurde, wurde der HeartBeat Visualizer vollkommen neu entwickelt. Dabei ist zu beachten, dass die von inet-logistics vorgegebenen Kriterien eingehalten werden und das Projekt den Wünschen (Design, wichtige Funktionen etc.) der Mitarbeiter angepasst wird. Folgende Punkte beschreiben, welche Kriterien geplant wurden und wie diese im Pflichtenheft fixiert wurden. Balter Martin, Kuschny Daniel, Müller Markus Seite 19 / 100

20 9.4.1 Muss-Kriterien HeartBeat Visualizer Portal Ziel des HeartBeat Visualizers ist es ein Portal System zu erstellen, welches es ermöglicht Module als Teilsysteme in das Basissystem zu laden. Das Portalsystem ist eine Webapplikation, welche in der inet-logistics als Auswertungsplattform für ihre erstellten Applikationen dient. Modulsystem Das Modulsystem des HeartBeat Visualizers ermöglicht es dynamisch neue Teilsysteme in die Applikation hinzuzuladen und deren Funktionalitäten somit zur Verfügung zu stellen. Die Module stellen eine Liste von Rollen zur Verfügung, welche es ermöglichen Benutzer-Einschränkungen für die Teilsysteme zu verteilen. Benutzersystem Der Zugriff auf das Portal muss mittels eines Benutzersystems eingeschränkt werden können. Jeder Benutzer hat die Möglichkeit sich mit seinen Benutzerdaten (Benutzername und Passwort) in das System einzuloggen. Dem Benutzer wird über ein Rollensystem zugeteilt, welche Berechtigungen er für das System hat. Jedes Modul des Modulsystems stellt eine Liste von Rollen zur Verfügung, welche in das Basissystem übernommen werden. Diese Rollen sind über einen im System eindeutigen Schlüssel definiert und können den Benutzern zugeteilt werden. In den Modulen kann dann überprüft werden, ob einem Benutzer eine Rolle zugeteilt ist. Zusätzlich werden dem Benutzer nur jene Module bzw. Modulfunktionen angezeigt, für welche er auch die Rollen zugeteilt hat. Benutzerverwaltung In der Benutzerverwaltung soll es möglich sein, die Benutzerkonten für das System zu verwalten. Dies schließt die Aktionen für das Anlegen, Bearbeiten, Aktivieren/Deaktivieren und Löschen der Benutzerkonten mit ein. Administrationsmodul Das Administrationsmodul ist ein fix integriertes Modul des HeartBeat Visualizer Portals. Es stellt Rollen, sowie Menüpunkte für die verfügbaren Untermodule zur Verfügung. Balter Martin, Kuschny Daniel, Müller Markus Seite 20 / 100

21 Rollenverwaltung Wie bereits im Punkt Benutzersystem angesprochen, werden Rollen verwendet um Benutzern den Zugriff auf Bereiche der Module zu ermöglichen oder zu verweigern. In der Rollenverwaltung ist es möglich, den Benutzern die verfügbaren Rollen zuzuweisen. HeartBeat Analyzer Das Modul HeartBeat Analyzer stellt Bereiche zur Auswertung von Log-Ausgaben zur Verfügung. Speichern der Logfilter / History Jeder Benutzer hat die Möglichkeit abgesetzte Suchen in der Monitor- und LogAnalyse abzuspeichern. Dies ermöglicht es dem Anwender oft verwendete Suchvorgänge schnell abzurufen, ohne die Filterkriterien neu spezifizieren zu müssen. Soll-Kriterium: Die Filterkriterien können in Kategorien unterteilt werden, welche der Benutzer anlegen kann. Muss-Kriterium: Ebenfalls gibt es eine fixe Kategorie History in welcher die letzten abgesetzten Suchanfragen gespeichert werden. Die Anzahl der gespeicherten Suchanfragen kann in der Systemkonfiguration hinterlegt werden. MonitorAnalyse Die MonitorAnalyse ermöglicht es die Monitordaten in der Tabelle JBMONLOG des inetlogistics Systems auszuwerten. In dieser Tabelle der Datenbank werden alle Funktionsaufrufe, welche in den Applikationen von inet-logistics getätigt werden, geschrieben. Die MonitorAnalyse soll einen Suchfilter zur Verfügung stellen, um die Einträge dieser Datenbank nach vordefinierten Kriterien zu filtern und auszuwerten. Die Funktionsaufrufe müssen anhand der Services gruppiert werden. Der Service ist anhand des Servernamens identifizierbar. Im Bereich der Suchergebnisse muss es möglich sein, über einen Klick auf eine Schaltfläche auf die LogAnalyse weitergeleitet zu werden. Der LogAnalyse werden hierbei jene Filterkriterien übergeben, sodass die Log-Einträge für den ausgewählten Eintrag dargestellt werden. Balter Martin, Kuschny Daniel, Müller Markus Seite 21 / 100

22 Soll-Kriterium: Neben den Einträgen, welche nach einer Suche dargestellt werden, sollen Buttons zur Verfügung stehen, welche es ermöglichen die Suche auf definierte Kriterien weiter einzuschränken. So soll es beispielsweise möglich sein über einen Button nach SessionID weiterfiltern die Suche nach der SessionID des gewählten Eintrags weiter zu filtern. Wunsch-Kriterium: Optional soll es dem Benutzer möglich sein das aktuelle Suchergebnis übersichtlich und ohne unnötige Designelemente in einer Druckansicht darzustellen. Mittels eines Buttons über dem Suchergebnis soll möglich sein die aktuelle Ergebnismenge als eines der folgenden Formate zu exportieren: Text XML (X)HTML CSV Über einen anderen Button kann die Ergebnismenge der Suche über eine versendet werden. LogAnalyse Die LogAnalyse ermöglicht es dem Benutzer, die Tabelle JBLOG auszuwerten. In dieser Tabelle werden die Log-Ausgaben der Funktionsaufrufe protokolliert. Die LogAnalyse bietet exakt dieselben Funktionen wie die MonitorAnalyse (siehe: MonitorAnalyse) und es gilt auch dieselbe Unterteilung in Muss-, Soll- und Wunschkriterien. Für die Navigation von der LogAnalyse zurück zur MonitorAnalyse sollen jene Funktionsaufrufe der MonitorAnalyse dargestellt werden, welche mit der Aktion des gewählten Log Eintrags zusammenhängen. Balter Martin, Kuschny Daniel, Müller Markus Seite 22 / 100

23 HeartBeat Diamond Der HeartBeat Diamond ist eine Desktop Applikation welche die Aktivitäten der Server visuell darstellt. Für die visuelle Darstellung wird das Open-Source Programm gltail verwendet. Dieses Programm ermöglicht es Log-Dateien zu überwachen und Ereignisse, welche in diese Dateien protokolliert werden, visuell darzustellen. gltail wurde in der Scripting-Sprache Ruby entwickelt, welche eine große Anzahl an Programmbibliotheken zur Verfügung stellt um das Entwickeln zu vereinfachen. Für die visuelle Darstellung der Log-Dateien verwendet gltail die Grafikbibliothek OpenGL. gltail ist ein Projekt, welches für Unix-Systeme entwickelt wurde. Es verwendet den tail Befehl der Gnu-Tools welcher es ermöglicht Dateien auf neu eingetragene Zeilen zu überwachen. Jedoch gibt es diverse Projekte auf dem Markt, welche diese Gnu-Tools auf andere Betriebssysteme, beispielsweise Windows, portiert haben. Somit ist gltail auch auf Windows verfügbar. HeartBeat Diamond Dokumentation In diesem Modul muss dem Benutzer eine Anleitung dargestellt werden, wie eine lokale Kopie des HeartBeat Diamond installiert wird. Anpassung der Datenquelle gltail bietet nur die Möglichkeit die Log-Daten aus Dateien zu beziehen. Jedoch gibt es ein Basissystem, welches es erlaubt neue Datenquellen zu erstellen. Die Aufgabe in diesem Projekt ist es nun, ein Modul zu erstellen, welches es erlaubt die Log-Daten in einem definierten Intervall aus der Datenbank zu beziehen. Balter Martin, Kuschny Daniel, Müller Markus Seite 23 / 100

24 9.4.2 Wunsch Kriterien Systemkonfiguration In der Systemkonfiguration soll es über eine Oberfläche möglich sein, Konfigurationen vorzunehmen, welche für das ganze System (benutzerübergreifend) gültig sind. Modulverwaltung Die Modulverwaltung soll es ermöglichen in einer Oberfläche die Module des Systems zu aktivieren und deaktivieren. Ebenfalls soll es dem Anwender möglich sein, Module zu löschen und hinzuzufügen. HeartBeat Diamond Steuerung In einer Oberfläche soll dargestellt werden, ob der HeartBeat Diamond des Dorfplatzes gerade aktiv ist und Möglichkeiten zum Starten und Stoppen der Applikation bietet. Branding Ebenfalls soll es möglich sein, eine Grafik angeben zu können, welche in den Hintergrund der Applikation gezeichnet wird. Dies ermöglicht es, dass das Projektlogo als Wasserzeichen im Hintergrund der Applikation dargestellt wird. Balter Martin, Kuschny Daniel, Müller Markus Seite 24 / 100

25 9.5 Entwurf Allgemein Es wurde ein Prototyp entwickelt, um bereits kommende Funktionen abschätzen zu können. Weiters lieferte der Prototyp eine Reihe von Informationen über die zukünftige Darstellung und Handhabung der Applikation. Bevor das Design entwickelt und erarbeitet wurde, wurden Skizzen gezeichnet und das Layout für die Grundstruktur der Applikation erstellt. Abbildung 9-5 Skizze für MonitorView In der Abbildung 9-5 Skizze für MonitorView ist es möglich eine Grundstruktur für die Auswertung der Log-Daten zu sehen. Das Layout wurde während der Entwicklung immer weiter ausgearbeitet und optimiert. Balter Martin, Kuschny Daniel, Müller Markus Seite 25 / 100

26 Prototyp Der Prototyp enthält schon die wesentliche Struktur, die für eine einfache und benutzerfreundliche Handhabung sorgt. Durch Ajax ist es möglich, ohne die Seite neuzuladen, Fehlermeldungen oder sonstige Informationen darzustellen. Dies stellt einen hohen Komfort für den Benutzer dar. Abbildung 9-6 Prototyp Login Balter Martin, Kuschny Daniel, Müller Markus Seite 26 / 100

27 In der Abbildung 9-6 Prototyp Login ist zu erkennen, dass eine falsche Eingabe des Passworts getätigt wurde. Das Dashboard des Prototyps ähnelt schon stark der Struktur des finalen Designs. Das Design beinhaltet die großen und übersichtlichen Buttons, die zu den unterschiedlichen Modulen führen. Das Menü beinhaltet die Übersicht über die verschiedenen Module, die dem Benutzer zur Verfügung stehen. Abbildung 9-7 Prototyp Dashboard Balter Martin, Kuschny Daniel, Müller Markus Seite 27 / 100

28 Bei der Auswertung der Log-Daten ist der Aufbau der Eingabe der verschiedenen Suchkriterien zu erkennen. Bei der Darstellung im Prototyp werden die Daten noch von den verschiedenen Server getrennt. Des Weiteren wurden die ganzen Funktionen zum Hinzufügen weiterer Filterkriterien an den rechten Rand platziert. Abbildung 9-8 Prototyp Suchmaske mit Suchergebnissen Balter Martin, Kuschny Daniel, Müller Markus Seite 28 / 100

29 9.6 Realisierung Folgende Punkte werden ausfüh ausführen, ren, welche Kriterien des Pflichtenheftes erfüllt wurden und wie diese technisch umgesetzt wurden Allgemein Abbildung 9-9 Bereichsstruktur des Projektes Das Projekt HeartBeat Visualizer, kurz HBV HBV, ist in mehrere Teilbereiche unterteilt. Der erste Teilbereich, der HeartBeat Visualizer, ist eine Webanwendung Webanwendung, welche als Grundlage für ein Analyseportal dient. Im HeartBeat Visualizer, welcher für inet inet--logistics logistics entwickelt wurde, ist ein Hauptmodul integriert, welches die Analysefunktionen für die Applikationen von inet inet-logistics logistics implementiert, der HeartBeat Analyzer. Der HeartBeat Analyzer bietet zwei Hauptansichten welche die Analysefunktionen für inet Hauptansichten, inet-logistics logistics bereitstellen. Die MonitorAnalyse und nd die LogAnalyse. LogAnalyse Diese Ansichten sind als Suchmasken aufgebaut, welche eine Suche mit definierten Filterkriterien in der Datenbank ermöglichen. Der HeartBeat Diamond ist der zweite große Teilbereich dieses Projektes. Der HeartBeat Diamond bietet eine Ech Echtzeitvisualisierung tzeitvisualisierung der eingehenden Log LogInformationen. Balter Martin, Kuschny Daniel, Müller Markus Seite 29 / 100

30 9.6.2 HBV HeartBeat Visualizer Allgemein Durch die Gliederung in mehrere Projektbereiche ergibt sich eine vier Schichten Architektur, in welche sich die Bereiche des HeartBeat Visualizers für inet-logist logistics einteilen en lassen. Abbildung 9-10 Schichtenarchitektur Basis Library Die erste Schicht, die Basis Library, beinhaltet alle Bibliotheken und Frameworks welche für den HeartBeat Visualizer verwendet wurden. Als Javascript Framework wurden die MooTools verwendet. Mittels diesem Framework wurden alle Javascript Aktionen durchgeführt, welche dynamische Eingaben oder ähnliches verarbeiten. Balter Martin, Kuschny Daniel, Müller Markus Seite 30 / 100

31 Das ganze Backend wurde mittels Java realisiert. Für die Webentwicklung wurde der J2EE Standard weitgehendst eingehalten um auch den inet-logistics Mitarbeitern eine leichte Übernahme der Applikation zu ermöglichen. Weiters wurden einige Bibliotheken von inet-logistics übernommen, um die Integration in die zukünftige Infrastruktur gewährleisten zu können. Für die Oberfläche wurde die Ajax-Bibliothek ICEfaces verwendet. Diese bietet einen Aufsatz auf den JavaServer Faces (kurz JSF) Standard, welcher als Komponente im J2EE enthalten ist. HeartBeat Visualizer Basis Framework Diese Schicht bietet die Grundlage für das Analyseportal. Über das Modulsystem lässt sich das System um neue Funktionen erweitern. Auch das Benutzersystem, welches eine Authentifizierung am System ermöglicht, befindet sich in dieser Schicht. Dadurch können die Bereiche der Module beliebig konfigurierbar für Benutzer zugänglich gemacht werden. Der letzte Bereich dieser Schicht ist das Konfigurationssystem. Dieser Bereich ermöglicht erst das dynamische Konfigurieren des Systems. Datenbankzugangsdaten, Modullisten etc. können durch das Konfigurationssystem in Dateien gespeichert und in der Anwendung verarbeitet werden. HeartBeat Analyzer Basis Framework Im Rahmen der Entwicklung des HeartBeat Analyzers für inet-logistics hat sich ein allgemeines Basis Framework entwickelt, das den HeartBeat Analyzer in beliebige Infrastrukturen eingliedern lässt. inet-logistics HeartBeat Analyzer Der HeartBeat Analyzer für inet-logistics gliedert sich in zwei Hauptbereiche bzw. Hauptansichten: die MonitorAnalyse und die LogAnalyse. Die MonitorAnalyse, eine der zwei Hauptansichten des HeartBeat Analyzers, bietet die Möglichkeit die Monitoring-Daten der JBMONLOG Tabelle auszuwerten (siehe: inetlogistics Datenbankmodell). Dies ermöglicht den Anwendern des HeartBeat Analyzers alle Schritte, welche ein Benutzer auf den Applikationen von inet-logistics durchgeführt hat, zurückzuverfolgen, um eine Fehleranalyse durchzuführen oder Auslastungsstatistiken anzufertigen. Balter Martin, Kuschny Daniel, Müller Markus Seite 31 / 100

32 Die LogAnalyse ist die zweite Hauptansicht des HeartBeat Analyzers. Diese Ansicht bietet die Möglichkeit die Log-Informationen der JBLOG Tabelle zu analysieren (siehe: inet-logistics Datenbankmodell). In der MonitorAnalyse ist es lediglich möglich die Aktionen des Benutzers anzuzeigen und zurückzuverfolgen. Jedoch um zu ermitteln ob bei einer Aktion ein Fehler oder ähnliches aufgetreten ist, wird die LogAnalyse benötigt. Diese ermöglicht eine Filterung der Log-Einträge, welche in der Datenbank zu einem Funktionsaufruf angelegt wurden. Mittels der lokalen MonitorID werden die Log Einträge dem Funktionsaufruf zugeordnet. Monitor-Daten: Diese Funktionsaufrufe sind über mehrere Server verteilt und durch die globale MonitorID fmafi1jd-19-ls_dka80 gruppiert. Jeder Eintrag hat eine eigene lokale MonitorID, um die zugehörigen Log-Daten abzurufen. CSERVERNAME CFUNCTION CGLOBALMONITORID CLOCALMONITORID LS_dka80 1 gw.prj.gui.bean:show fmafi1jd-19-ls_dka80 fmafi1-20-ls_dka80 BI_dka80 1 gw.bi.gui.bean:load fmafi1jd-19-ls_dka80 abual3-35-bi_dka80 Log-Daten: Die folgenden Log-Daten wurden zum Eintrag des Servers LS_dka80 1 angelegt. Abrufbar sind diese Informationen über die lokale MonitorID fmafi1-20-ls_dka80. CSERVERNAME CPRIO CCATEGORY CLOCALMONITORID LS_dka80 1 INFO gw.basis.servlet.httpservlet fmafi1-20-ls_dka80 LS_dka80 1 INFO gw.prj.lose.prj.vsa.servlet.vsa fmafi1-20-ls_dka80 Balter Martin, Kuschny Daniel, Müller Markus Seite 32 / 100

33 Datenbank inet-logistics Datenbankmodell Alle Applikationen von inet-logistics schreiben ihre Diagnostik Informationen in dieselbe Datenbankstruktur. An diese Struktur dockt der HeartBeat Visualizer an, um eine Auswertung dieser Daten in einer Weboberfläche zu ermöglichen: Abbildung 9-11 inet-logistics Log Datenbankmodell Dieses Datenbankmodell gliedert sich in zwei Teilbereiche: die Tabellen für die Monitoring-Daten sowie die Tabellen für die Log Informationen. Der erste Teilbereich beinhaltet die Tabellen JBMONLOG, JBMONFUN und JBMONMOD. Balter Martin, Kuschny Daniel, Müller Markus Seite 33 / 100

34 JBMONMOD Die Tabelle JBMONMOD beinhaltet alle Module von inet-logistics. Die Applikationen von inet-logistics gliedern sich in unterschiedliche Module, welche unterschiedliche Aufgaben übernehmen. Durch diese Module lassen sich die verfügbaren Funktionen gruppieren. Beispielwerte: Billing Pricing Versand Transport Zurzeit (Stand: ) existieren 30 Module, in welche die Funktionen untergliedert werden. JBMONFUN Alle Funktionen, zu denen Log-Informationen erzeugt werden, sind in der Tabelle JBMONFUN aufgelistet. Beispielwerte: gw.prj.lose.prj.vsa.servlet.versand.versanduebersicht gw.prj.lose.prj.scan.servlet.kundenauswahl gw.basis.servlet.testservlet Zurzeit (Stand: ) existieren 1037 Funktionen, welche in den Applikationen von inet-logistics ausgeführt werden können. JBMONLOG Alle Anwendungen von inet-logistics produzieren sogenannte Monitoring-Daten. Diese Monitoring-Daten beinhalten alle Funktionsaufrufe, die die Benutzer auf den Applikationen von inet-logistics durchführen. Loggt sich beispielsweise ein Benutzer in das System ein, wird ein Eintrag mit dem Wert gw.prj.lose.prj.vsa.servlet.login in die Datenbank eingetragen. Je nach Aktion stehen in einem solchen Eintrag zusätzliche Informationen zur Verfügung, die für eine etwaige Fehleranalyse relevant sind. In der JBMONLOG Tabelle werden diese Funktionsaufrufe abgelegt, um diese für eine spätere Auswertung zur Verfügung zu stellen. Der zweite Teilbereich bildet die JBLOG Tabelle. Balter Martin, Kuschny Daniel, Müller Markus Seite 34 / 100

35 JBLOG Zu jedem Funktionsaufruf, welcher in den von inet-logistics erstellen Anwendungen getätigt wird, werden zusätzliche Informationen in der Tabelle JBLOG abgelegt. Es werden zwischen Debug-Informationen, Zusatzinformationen, Warnungen, Fehlern und systemkritischen Fehlern unterschieden. Versucht beispielsweise ein Kunde eine Aktion durchzuführen, in welcher Stammdaten benötigt werden aber bisher keine angelegt sind, wird dies als Fehler in der Datenbank vermerkt. Sollte nun ein Kunde melden, dass er eine gewisse Aktion nicht durchführen kann, bietet die LogAnalyse die Funktionen zur Auswertung der Fehler des Benutzers. HeartBeat Visualizer Datenbankmodell Abbildung 9-12 Datenbankmodell des HeartBeat Visualizers Das Datenbankmodell des HeartBeat Visualizers stellt die Tabellen zur Verfügung um die notwendigen Systeminformationen des Portals persistent abzulegen. Die zwei Teilbereiche, Benutzerverwaltung und Filterspeicherung, bieten alle nötigen Tabellen, um die Daten der Standard HeartBeat Visualizer Installation abzulegen. Balter Martin, Kuschny Daniel, Müller Markus Seite 35 / 100

36 Der erste Teilbereich Benutzerverwaltung beinhaltet drei Tabellen, welche für die Ablage der Benutzer, der Rollen sowie der Benutzerrollenzuweisung verantwortlich sind. HBROLE In dieser Tabelle werden alle Rollen abgelegt, die vom System geladen werden. Dies ermöglicht eine spätere Zuweisung der Rollen an die Benutzer. Für die Rollen wird lediglich der Identifizierungsschlüssel benötigt: HBV_DASHBOARD HBA_MONITORVIEW HBUSER In dieser Tabelle werden alle Benutzerdaten abgelegt. Die Benutzerdaten beinhalten alle Informationen um sich am HeartBeat Visualizer anzumelden: Benutzername Passwort Ist der Benutzer gesperrt? Aktuelle SitzungsID HBUSERROLE Die Tabelle HBUSERROLE beinhaltet alle Zuweisungen der Rollen zu den Benutzern. Beispiele: Benutzer Rolle 1 (Benutzer01) 1 (HBV_DASHBOARD) 1 (Benutzer01) 2 (HBA_MONITORVIEW) 2 (Benutzer02) 1 (HBV_DASHBOARD) Der zweite Teilbereich des HeartBeat Visualizer Datenbankmodells beschreibt die Speicherung der Filterdefinitionen. HBFILTER Die Tabelle HBFILTER beinhaltet alle Suchfilter, welche der Benutzer abspeichern kann. Genauere Details zur Filterlink-Speicherung werden im Punkt HeartBeat Analyzer ausgeführt. Jedem Filter kann ein Name zugewiesen werden, um die Funktion des Filters genauer zu spezifizieren. Balter Martin, Kuschny Daniel, Müller Markus Seite 36 / 100

37 HBFILTERCATEGORY Um die Filter der HBFILTER Tabelle zu gruppieren, muss in der Tabelle HBFILTERCATEGORY eine Kategorie angelegt werden. Dieser Kategorie kann ein Name zugewiesen werden, um für den Benutzer verständliche Kategorien zu erzeugen. Die Kategorie wird dem Benutzer zugewiesen. Dies ermöglicht es dem Benutzer sich eine Reihe von Kategorien anzulegen, in die er seine Filter für eine spätere Wiederverwendung ablegt. Design Um den HeartBeat Visualizer perfekt in die Umgebung von inet-logistics ein zubetten wurde das Corporate Design von inet-logistics übernommen. Die Grundfarben für das Design sind dieselben wie im inet-logistics Logo, Blau und Grau. Das fertige Design wurde am 06. November 2008 fertiggestellt. Das Design wurde noch vereinheitlicht um eine benutzerfreundliche Darstellung zu gewährleisten. Es stand für die Entwicklung eine fertige HTML Datei mit dem Design für die unterschiedlichen Module zur Verfügung. Da das Design komplett dynamisch umgesetzt wurde, konnte sehr einfach, ohne weitere Änderungen am Design, für die unterschiedlichen Module weiterentwickelt werden. Dies gewährleistet bei der Entwicklung, ein einfaches Erstellen einer neuen Seite für ein Modul. Balter Martin, Kuschny Daniel, Müller Markus Seite 37 / 100

38 Abbildung 9-13 vorgefertigtes Design Designvorlage In der Navigationsleiste befinden sich die Menüpunkte, auf die ein Benutzer zugreifen kann.. Sobald der Mauszeiger über das Menü fährt, öffnet sich das Menü und man kann schnell und einfach zu den verschiedenen Modulen navigieren. Die Titelleiste zeigt dem Benutzer, in welchem Modul er sich gerade befindet. Im Top Content werden im Dashboard die Module angezeigt. In der LogAnalyse befindet sich hier die Suchmaske, um eine Suche abzusetzen. Die Darstellung der Ergebnisse der LogAnalyse wird im Bottom Content vorgenommen. Für weitere Module eignet es sich ebenfalls zum Darstellen von Informationen. Balter Martin, Kuschny Daniel, Müller Markus Seite 38 / 100

39 Farben Die Blautöne wurden vom inet-logistics Logo verwendet, und in einzelne Stellen des Designs eingearbeitet, wie zum beispielsweise in das Menü. Abbildung 9-14 Design Farbpalette Die Grautöne wurden verwendet um den Hintergrund zu gestalten. Durch Verläufe und Schatten wurde das Design abgerundet. Server Farben Für die Darstellung unterschiedlicher Server wurde das Feld Server in der LogAnalyse eingefärbt. Dies ermöglicht durch einen kurzen Blick, die sofortige Erkennung der unterschiedlichen Server. Farbe für den logistics-server Farbe für den billing-server Farbe für den pricing-server Farbe für den mapping-server Konfiguration der Server Farben Um die Farben für die unterschiedlichen Server anzupassen, findet man in der CSS Datei Base_Formular.css die Klasse mit den Anfangsbuchstaben der Server und kann diese somit ändern oder hinzufügen..ls { } background-color: #8DB3E2; Balter Martin, Kuschny Daniel, Müller Markus Seite 39 / 100

40 Portal Basissystem Abbildung 9-15 Schichten des Basis-Frameworks Logging Für das Erzeugen von Log-Informationen wird Log4J verwendet. Die Klasse LogManager, welche erstellt wurde, ermöglicht den Zugriff auf eine zentrale Log-Instanz, welche die Ausgabe der Informationen in die Standardausgabe (Konsole), Dateien und weitere Endpunkte verwaltet. Datenbankzugriff Der Datenbankzugriff wird über die Klassen von inet-logistics verwaltet. Ein Datenbankmanager lädt die Zugriffsdaten aus einer Konfigurationsdatei in das System und ermöglicht somit das dynamische Ändern der Datenbankverbindung. Für das Absetzen der Datenbankstatements werden ausschließlich PreparedStatements verwendet. Diese ermöglichen einen Schutz vor SQL-Injections und beugen dadurch einer Einschleusung ungewollter Abfragen vor welche dem System schaden. Balter Martin, Kuschny Daniel, Müller Markus Seite 40 / 100

41 Konfigurationssystem Beim Konfigurationssystem wird die externe Bibliothek Simple verwendet. Diese ermöglicht über Annotationen Variablen zu definieren. Somit ist es dem Framework von Simple möglich auf die unterschiedlichen Variablen und Klassen zuzugreifen und somit eine XML Struktur zu erzeugen. Das Framework ermöglicht es somit einfach, schnell und sicher XML Dateien für die unterschiedlichsten Informationen, die für die Konfiguration relevant sind, abzuspeichern und auszulesen. 1: // Annotation um die Variable als 2: // Attribut in einer XML Datei abzulegen 3: // Das Attribute hat den Namen classpath = "classpath") 5: private String _sclasspath = ""; Der ConfigManager Abbildung 9-16 Klassendiagramm des Konfigurationsmanagers Der ConfigManager hat die Möglichkeit während des Betriebs der Web Applikation neue Konfigurationsdateien einzulesen oder Veränderte neu zu laden und sie dem Programm zur Verfügung zu stellen. Bei der Initialisierung wird aus dem FaceletContext der aktuelle Pfad des Web- Applikation Ordners herausgeneriert. Danach wird der Ordner für die Konfigurationsdateien festgelegt, und eine Liste der Konfigurationsdateien in das Programm geladen. Danach werden die gefundenen und validierten Konfigurationsdateien vom Simple Serializer eingelesen und stehen danach in einer Map für die gesamte Applikation zur Verfügung. Balter Martin, Kuschny Daniel, Müller Markus Seite 41 / 100

42 Abbildung 9-17 Ablauf für das Laden der Konfiguration Balter Martin, Kuschny Daniel, Müller Markus Seite 42 / 100

43 Aufbau einer Konfiguration Zuerst erstellt man eine Klasse mit dem Namen der Konfigurationsdatei. Diese Klasse erbt vom ModuleConfig damit man die Konfiguration wieder neu laden oder neu auslesen kann. Sie bildet den Grundstock für die Konfiguration. Zu beachten ist, dass die Konfigurationsdatei den gleichen Namen wie die neu erstellte Klasse hat und noch die Endung.xml hat. Hier ein Beispiel: MailConfig = MailConfig.xml Die Konfigurationsdateien werden im war Ordner unter config/property abgespeichert. Abbildung 9-18 Aufbau des Konfigurationssystems Abbildung 9-19 Zusammenhang der Dateien des Konfigurationssystems Die ganzen Konfigurationsdateien werden vom ConfigManager verwaltet. Über ihn ist es möglich XML Dateien auszulesen und diese wieder in der Datei abzuspeichern. Des weiteren stellt der ConfigManager die geladen Konfigurationsdaten für die Applikation zur Verfügung und kann somit in den unterschiedlichsten Bereichen verwendet werden. Aufbau einer Konfigurationsdatei Die Konfigurationsdatei muss den gleichen Namen wie die Klasse haben und der Dateiendung.xml versehen werden. Dies ermöglicht dem ConfigManager genau die richtige Konfigurationsdatei für das richtige Konfigurationsmodul zu laden. Balter Martin, Kuschny Daniel, Müller Markus Seite 43 / 100

44 Modulsystem Um eine dynamische Erweiterung des Systems zu ermöglichen, wurde ein Modulsystem entwickelt. In einer Konfigurationsdatei werden alle Module angegeben, welche in das System geladen werden sollen: ModuleListConfig.xml: 1: <?xml version="1.0" encoding="utf-8"?> 2: <ModuleList> 3: <Module classname="inet.module.hbv.mainmodule"/> 4: <Module classname="inet.module.hbv.comp.hba.hbamodule"/> 5: </ModuleList> Im Attribut classname befindet sich der Name einer Java Klasse, welche von der Basisklasse für Module abgeleitet ist. Neben einem Modulnamen findet sich im Modul eine Liste von Aktionen, welche in diesem Modul durchgeführt werden können. Diese Aktionen definieren einen Seitentitel, die benötigte Rolle für den Zugriff auf diese Aktion, die URL der Zielseite und ein Bild welches in der Funktionsübersicht, dem Dashboard, dargestellt wird. Diese Module werden vom ModuleManager dynamisch beim Systemstart geladen. Die geladenen Rollen werden in die Datenbank eingetragen, sodass diese für die weitere Verarbeitung zur Verfügung stehen. Weiters bietet der ModuleManager Funktionen für das Laden der verfügbaren Aktionen des Benutzers. Balter Martin, Kuschny Daniel, Müller Markus Seite 44 / 100

45 Abbildung 9-20 Klassenstruktur des Modulsystems Balter Martin, Kuschny Daniel, Müller Markus Seite 45 / 100

46 Benutzersystem Das Benutzer- und Rollensystem des HeartBeat Visualizer ermöglicht es jedem Benutzer unterschiedliche Rechte zu verteilen und somit einen individuellen Zugriff auf unterschiedliche Seiten zu gewährleisten. Des weiteren ist es möglich einen Benutzer vom Portal zu blockieren. Login Jeder Benutzer, welcher auf das System zugreifen will, muss sich zuerst am System authentifizieren. Sobald ein Benutzer auf das System zugreift, bekommt dieser vom Server eine sogenannte SessionID zugewiesen um den Benutzer eindeutig identifizieren zu können. Mit einer gespeicherten SessionID im Cookie und einer weiteren SessionID in der Datenbank wird kontrolliert, ob der Benutzer sich schon angemeldet hat. Dies ermöglicht es dem Benutzer ohne eine erneute Angabe der Benutzerdaten sich am System zu authentifizieren. Der Login kontrolliert, ob alle Felder ausgefüllt sind, wenn nicht wird dem Benutzer eine Fehlermeldung angezeigt. Wenn alle Felder korrekt eingegeben wurden, wird zuerst in der Datenbank kontrolliert ob der Benutzer vorhanden ist, wenn er vorhanden ist wird das Passwort mit dem in der Datenbank verglichen. Stimmen diese überein, werden die Benutzerdaten aus der Datenbank geladen und der Anwender wird weitergeleitet. Balter Martin, Kuschny Daniel, Müller Markus Seite 46 / 100

47 Abbildung 9-21 Ablauf des Benutzer-Login Balter Martin, Kuschny Daniel, Müller Markus Seite 47 / 100

48 Ablauf des Logins mit einem abgespeicherten Cookie Zuerst wird kontrolliert ob der Benutzer die Cookies HBV_BenutzerName und HBV_SessionId besitzt. Im HBV_BenutzerName wird der Benutzername beim letzten Login abgespeichert. Im HBV_SessionId wird die SessionID der letzten erfolgreichen Sitzung gespeichert. Diese SessionID befindet sich ebenfalls in der Datenbank. Ist das Cookie vorhanden wird aus den Cookies der Benutzername und die SessionID der letzten erfolgreichen Sitzung geladen und kontrolliert ob der Benutzername und die SessionID des Cookies mit den Daten in der Datenbank übereinstimmen. Sind die Werte valide wird der Benutzer initialisiert, die neue SessionID wird im Cookie und in der Datenbank abgespeichert. Danach wird noch kontrolliert, ob der Benutzer auf eine bestimmte Seite wollte und dann wird er auf diese oder auf das Dashboard weitergeleitet. Wenn die Cookies nicht vorhanden sind oder der Cookie-Inhalt nicht mit den Werten aus der Datenbank übereinstimmen, muss sich der Benutzer händisch anmelden. Beim händischen Anmelden wird kontrolliert ob Benutzername und Passwort richtig eingegeben wurden (sonst erscheint eine Fehlermeldung). Sind die Angaben korrekt, wird kontrolliert ob die Angaben des Benutzer mit denen in der Datenbank übereinstimmen. Sind diese korrekt, wird der Benutzer initialisiert. Der Benutzername und die neue SessionID wird im Cookie abgespeichert, sowie die neue SessionID in der Datenbank. Dies ermöglicht dem Benutzer, dass er sich beim erneuten Betreten des Portal nicht mehr händisch anmelden muss. Logout Beim Logout werden die Benutzer-Daten zurückgesetzt und es werden die Informationen aus dem Cookie entfernt, sodass der Benutzer sich nicht automatisch wieder über die SessionID anmeldet. Benutzerverwaltung Um Benutzer hinzufügen, bearbeiten oder löschen zu können, wurde die Benutzerverwaltung entwickelt. Balter Martin, Kuschny Daniel, Müller Markus Seite 48 / 100

49 Bearbeiten eines Benutzers Abbildung 9-22 Oberfläche der Benutzerverwaltung Um einen Benutzer bearbeiten zu können, muss man ihn zuerst mit dem Namen im Suchfeld finden. Die anderen Daten wie BenutzerID oder die SessionID werden, wenn der Benutzer gefunden wurde, automatisch angezeigt. Nun hat man die Möglichkeit die Benutzer-Daten zu ändern. Beim Ändern des Passwortes muss man die eingegebenen Informationen mit einer erneuten Eingabe bestätigen, sodass die Eingabe validiert werden kann. Sobald der Benutzer verändert wurde, können durch einen Klick auf die Speichern Schaltfläche die Informationen in der Datenbank gesichert werden. Balter Martin, Kuschny Daniel, Müller Markus Seite 49 / 100

50 Hinzufügen eines Benutzers Um einen Benutzer hinzuzufügen, muss man zuerst einen Benutzernamen und ein Passwort für diesen eingeben. Danach kann man auf Neuer User klicken und es erscheinen die Rollen im unteren Bereich. Die Rollen kann man nun auswählen und sie für den Benutzer abspeichern. Löschen eines Benutzers Um einen Benutzer zu löschen, muss man diesen zuerst mittels der Eingabe des Benutzernamens selektieren. Nachdem der Benutzer in der Datenbank gefunden wurde und sich eine BenutzerID im zugehörigen Feld befindet, kann man durch die Betätigung der User Löschen Schaltfläche der Benutzer mit allen Rollen aus der Datenbank gelöscht werden. Balter Martin, Kuschny Daniel, Müller Markus Seite 50 / 100

51 Dashboard Abbildung 9-23 Dashboard Ansicht Das Dashboard bietet jedem Benutzer eine individuelle Ansicht seiner verfügbaren Aktionen. Diese Ansicht wird anhand der Rollen generiert, welche dem Benutzer zugewiesen sind. So wird sichergestellt, dass kein Benutzer Aktionen angezeigt bekommt, für welche er nicht die Rechte zugewiesen bekommen hat. Die Aktionen werden mittels Grafiken dargestellt, welche im Modul definiert wurden. Diese Grafiken werden mittels Überschriften mit dem Modulnamen unterteilt, um die Aktionen zuordnen zu können. Fehlerseiten Die Fehlerseite ist eine Seite, die dem Benutzer wichtige Informationen über seinen Status übermittelt. Auf diesen Seiten werden Meldungen angezeigt, wenn der Benutzer beispielsweise keine Rechte hat, die gewünschte Seite zu betreten. Weiteres wird diese Seite angezeigt, wenn der Benutzer noch nicht eingeloggt ist. Wenn der Benutzer auf Weiter klickt, kommt er zum Login, kann sich anmelden und wird auf die gewünschte Seite verlinkt, wenn er die benötigten Rechte besitzt. Balter Martin, Kuschny Daniel, Müller Markus Seite 51 / 100

52 Abbildung 9-24 Fehlerseite Balter Martin, Kuschny Daniel, Müller Markus Seite 52 / 100

53 HeartBeat Analyzer Abbildung 9-25 Schichten des HeartBeat Analyzers Wie bereits erwähnt, sind die Sichten des HeartBeat Analyzers als dynamische Suchmasken aufgebaut. Im oberen Bereich (siehe Abbildung 9-26 rot markierter Bereich) ) findet sich die Suchmaske, welche dynamisch durch Konfigurationsdateien anpassbar ist. Im unteren Bereich (siehe Abbildung 9-26 grün markierter Bereich) ) finden sich die Suchergebnisse. Abbildung 9-26 Aufbau der HbaViews Balter Martin, Kuschny Daniel, Müller Markus Seite 53 / 100

54 Klassenbasis Im Rahmen der Entwicklung des HeartBeat Analyzer wurde ein Basis Framework erstellt welches die Grundlage für die Analysefunktionen bildet. FilterCriteria Abbildung 9-27 FilterCriteria Klasse Abbildung 9-28 FilterCriteria in der Oberfläche Die FilterCriteria Klasse ist die Basisklasse für die Erstellung neuer Filterdefinitionen. Die Filterkriterien bieten die Basis für eine Reihe von Informationen, welche für die Handhabung im System benötigt werden. Wird ein neues Filterkriterium definiert, müssen alle diese Informationen konkretisiert werden. Für das Generieren der Datenbankabfragen n müssen neben dem zugehörigen Spaltennamen in der Datenbank, auch Validierungsfunktionen für den eingegebenen Wert angegeben werden. Die Methode processfiltervalue bietet dem Filterkriterium die Möglichkeit, sich selbst in der Datenbankabfrage zu registrieren. eren. Dazu wird ein FilterQueryParser übergeben. Balter Martin, Kuschny Daniel, Müller Markus Seite 54 / 100

55 FilterQueryParser Abbildung 9-29 Klassendiagramm des FilterQueryParser Der FilterQueryParser ist für die Zusammenstellung der Datenbankabfrage sowie deren Werte zuständig. Durch eine Iteration der einzelnen FilterCriteria Objekte ist es möglich, alle gültigen Filterkriterien in die Datenbankabfrage mit aufzunehmen. Dazu bietet der FilterQueryParser eine Reihe von Methoden, welche es ermöglichen spezifizierte Abfragebereiche zu erstellen: Entspricht der eingegebene Wert dem Wert in der Datenbank? Ist der eingegebene Wert größer als jener, welcher in der Datenbank steht? Ist der eingegebene Wert kleiner als jener, welcher in der Datenbank steht? Befindet sich der Wert in der Datenbank in einem definierten Zeitbereich? Die Werte, welche für die Datenbankabfrage eingesetzt werden, werden in einer Liste, für die spätere Verwendung abgelegt. Beispiel einer Suchabfrage Abbildung 9-30 Beispiel einer Suchabfrage Mit diesem Beispiel wird ersichtlich, wie aus einer Eingabe der Suchfelder eine Datenbankabfrage generiert wird. Alle Eingaben werden mit UND verknüpft um zu gewährleisten, dass alle Bedingungen erfüllt werden. Da für eine Texteingabe (Beispiel: Servername) ) eine Platzhaltersuche möglich ist, wird der Operator LIKE eingefügt. Für die Datumseingabe wird ein Zeitbereich definiert indem durch Größer- und Kleinerzeichen der eingegebene Bereich abgegrenzt wird. Balter Martin, Kuschny Daniel, Müller Markus Seite 55 / 100

56 HbaViewBeans Die HeartBeatAnalyzer Beans, kurz HbaViewBeans, bilden die Basis für die Benutzeroberfläche. Sie stellen alle Methoden zur Verfügung, welche Daten für die Oberflächen verarbeiten und anbieten. Eine der Hauptaufgaben der HbaViewBeans ist es, die Filterkriterien für die Oberfläche anzubieten. Der genaue Ablauf für das Laden und Aufbereiten der Filterkriterien wird im folgenden Kapitel Allgemeine Funktionen beschrieben. Eine weitere Hauptaufgabe besteht darin, die eigentliche Suche durchzuführen. Die Methode dosearch ermöglicht es, eine Suche mit den aktuell eingegebenen Werten durchzuführen. Das daraus entstehende Suchergebnis wird darauf hin aufbereitet und steht über die Methode getsearchresult zur Verfügung. Weiters verwaltet diese Klasse das Darstellen der Popups. Neben den Methoden zum Anzeigen und Schließen der Popups, stellt die Klasse auch die Informationsobjekte für den Inhalt zur Verfügung. Abbildung 9-31 Klassendiagramm HbaViewBeanBase Balter Martin, Kuschny Daniel, Müller Markus Seite 56 / 100

57 Allgemeine Funktionen Suchmaske Abbildung 9-32 Suchmaske Die Suchmaske wird dynamisch anhand der geladenen Filterkriterien generiert. Dies ermöglicht eine einfache Erweiterung des Systems durch simples Hinzufügen neuer Filterdefinitionen. Der folgende Ablaufplan beschreibt, wie die Suchmaske generiert wird: Abbildung bildung 9-33 Ablauf der Suchmaskengenerierung Balter Martin, Kuschny Daniel, Müller Markus Seite 57 / 100

58 Die Generierung der Suchmaske gliedert sich in drei Teilbereiche, von welchen zwei nur ein einziges Mal pro Benutzer durchgeführt werden. Der erste Teilbereich ist das Laden der Filterdefinitionen. Zu Beginn werden die Filterdefinitionen aus der XML-Konfiguration geladen. Darauf werden alle Definitionen durchlaufen. Da in der XML-Konfiguration nur der Name der zu ladenden Definition steht, muss anhand dieses Namens eine Instanz erzeugt werden. Darum wird als erster Schritt die Klassendefinition über Reflection geladen. Darauf wird die Konstruktordefinition geladen, welche für das Erzeugen der Instanz benötigt wird. Wurden von allen Definitionen eine Instanz erzeugt, werden in Folge die Container für die Ausgabe generiert. Diese Aufbereitung bildet den zweiten Teilbereich. Zunächst wird die Spaltenanzahl aus der Konfiguration geladen. Darauf werden Container erzeugt, welche jeweils so viele Filter beinhalten, wie in der Konfiguration als Spaltenanzahl definiert ist. Der dritte Teilbereich, die Darstellung der Oberfläche, wird bei jedem Aufruf der Oberfläche durchgeführt. Die Filterdefinitionen werden durch eine weitere Iteration nacheinander der Oberfläche hinzugefügt. Dazu wird in der Oberfläche eine neue Tabellenspalte erzeugt, in welche eine Beschriftung der folgenden Komponente eingefügt wird. Diese Beschriftung signalisiert zusätzlich, ob das Feld ein Pflichtfeld ist. Je nach Typ des Filterkriteriums wird eine Komponente erzeugt. Es wird zwischen zwei Typen unterschieden: Texteingabe Bei der Texteingabe wird ein einfaches Textfeld erzeugt. Dieses Textfeld erlaubt spezielle Eingaben. Durch Leerzeichen getrennt können die Benutzer mehrere Begriffe eingeben, welche im Suchergebnis vorkommen können. Neben genauen Übereinstimmungen der Suchbegriffe werden auch Wildcards unterstützt. Durch ein * - Symbol markiert können an dieser Stelle beliebige Textpassagen vorkommen. Beispielwerte: Eingabe BI_Server01 LS* *_Server01_* BI_Server01 LS* Beschreibung Der Wert muss 1:1 dem angegebenen Text entsprechen, dass ein Datensatz in das Suchergebnis aufgenommen wird. Der Wert muss mit LS beginnen und kann mit einer beliebigen Zeichenfolge enden. Der Wert kann mit einem beliebigen Text beginnen und enden, lediglich der Text _Server01_ muss im Gesamttext vorkommen. Die bisher genannten Formate können beliebig miteinander kombiniert werden. Durch Leerzeichen getrennt muss nur eines der aufgelisteten Formate zutreffen. Balter Martin, Kuschny Daniel, Müller Markus Seite 58 / 100

59 Datumseingabe Die Datumseingabe ermöglicht dem Benutzer eine komfortable Datums- und Zeitangabe bis auf die Millisekundenebene. Dazu wurde ein Textfeld entwickelt, welches beim Klick auf die daneben dargestellte Schaltfläche ( ), ein Popup darstellt, in welches die Werte eingefügt werden können: Abbildung 9-34 Erweiterte Datumseingabemaske Der Cursor springt nach der Vervollständigung eines Textfeldes automatisch in das nächste Textfeld. Dies erspart dem Benutzer das manuelle wechseln der Textfelder und ermöglicht dadurch eine schnelle Eingabe. Mit dem Drücken der Entertaste kann das Datum im richtigen Format an das Textfeld übergeben werden. Zusätzlich gibt es in der Oberfläche eine Jetzt Jetzt Schaltfläche, welche den aktuellen Zeitpunkt in das Textfeld übernimmt. Um die direkte Eingabe der Werte in das Textfeld zu vereinfachen, werden eine Reihe von Formaten unterstützt: Eingabe :06:18, :06:18 13:06:18,300 Resultat :06:18, :06:18,000 Heute 13:06:18,300 Beschreibung Dies ist eine vollständige Eingabe mit allen Informationen. Diese wird direkt übernommen. Optional kann die Millisekundenangabe entfernt werden. Diese wird darauf automatisch mit 0 Millisekunden ersetzt. Eine weitere Variante ist jene, in welcher kein Datum angegeben wird. Diese Eingabe wird ersetzt mit der eingegebenen Uhrzeit und dem aktuellen Datum. Balter Martin, Kuschny Daniel, Müller Markus Seite 59 / 100

60 Eingabe Resultat Beschreibung 13:06:18 Heute 13:06:18,000 Wie auch bei der Zeiteingabe mit Datum ist es möglich, die Millisekundenangabe wegzulassen. Diese wird mit 0 Millisekunden ersetzt. 0 0 Wird eine 0 (Zahl) eingegeben, wird diese Zahl in keine Datumsangabe umgewandelt. Bei der Suchabfrage wird diese Angabe als aktueller Zeitpunkt interpretiert. Dies ermöglicht bei mehrfacher Durchführung der Abfrage, dass immer der aktuelle Zeitpunkt verwendet wird. Ganzzahl Ganzzahl Diese Angabe ist speziell für die Von-Bis-Angabe der MonitorAnalyse und LogAnalyse entwickelt worden. Die Interpretation dieser Eingaben wird in der Filterkriterienspezifikation ausgeführt. Diese Komponenten werden automatisch an die zugehörigen FilterCriteria-Instanzen gebunden. Wird ein neuer Wert in der Oberfläche eingetragen, so wird dieser Wert im Hintergrund automatisch an den Server geschickt, auf welchem der Wert im FilterCriteria abgelegt wird. Balter Martin, Kuschny Daniel, Müller Markus Seite 60 / 100

61 Abbildung 9-35 Schematische Darstellung der Wertübergabe Nach der Ausgabe der Komponenten wird ein Infosymbol eingefügt. Bei diesem Symbol werden Kurzinformationen dargestellt, welche Hilfetexte zum Filterkriterium beinhalten: Abbildung 9-36 Darstellung von Zusatzinformationen Filterkriterien Speicherung Jeder Benutzer des HeartBeat Analyzers hat die Möglichkeit, abgesetzte Suchen abzuspeichern und diese in individuellen Kategorien zu verwalten. Diese Funktion ermöglicht es dem Benutzer bereits verwendete Suchvorgänge auszuwählen und somit auf das Suchergebnis zu gelangen ohne die Filterkriterien neu spezifizieren zu müssen. Balter Martin, Kuschny Daniel, Müller Markus Seite 61 / 100

62 Abbildung 9-37 Filterlink Anzeige In der Abbildung 9-37 Filterlink Anzeige werden alle gespeicherten Links angezeigt. Hier befinden sich drei Spalten welche den Namen des Link und ein Feld mit Aktionen beinhaltet, in welchem der Benutzer die Möglichkeit hat, den Link zu löschen. Die Kategorien werden als Überschriften dargestellt um eine übersichtliche Ansicht zu erhalten. Abbildung 9-38 Filterlinkverwaltung In der Abbildung 9-38 Filterlinkverwaltung, hat der Benutzer die Möglichkeit den gewünschten Link zu speichern. Zusätzlich kann er diesem Link einen Namen, sowie eine Kategorie zuweisen. Im Drop- Down-Menü Kategorie werden alle bereits erstellen Kategorien angezeigt. Um eine weitere Kategorie zu erstellen, muss der Benutzer die Ansicht ändern. Dies wird durch einen Tab im gleichen Popup ermöglicht. Balter Martin, Kuschny Daniel, Müller Markus Seite 62 / 100

63 Abbildung 9-39 Kategorieverwaltung Um eine neue Kategorie zu erstellen, muss der Benutzer einen Namen für die zu erstellende Kategorie eintragen und anschließend auf den Button Kategorie anlegen klicken. Um eine bereits vorhandene Kategorie zu bearbeiten, kann der Benutzer die gewünschte Kategorie auswählen und ihr einen neuen Namen zuweisen. In dieser Ansicht besteht auch die Möglichkeit die vorhandene Kategorie zu löschen. Balter Martin, Kuschny Daniel, Müller Markus Seite 63 / 100

64 Suchergebnisse Durchführen einer Suchabfrage Abbildung 9-40 Ablauf einer Suchabfrage Nach dem Klick auf die Suchen-Schaltfläche, wird die Methode handlesearchbuttonclick des aktuellen HbaViewBeans aufgerufen. Hier wird zunächst überprüft ob eine MonitorID gesetzt ist. Da es möglich sein soll ausschließlich mit MonitorIDs zu suchen, werden die Pflichtfelder deaktiviert, sofern diese gesetzt sind. Darauf wird das Formular auf seine Validität überprüft. Dies wird dadurch erzielt, dass alle Filterkriterien durchlaufen werden und auf einen validen Wert überprüft wird. Ist einer der Werte invalid, wird das ganze Formular als invalid markiert, eine Fehlermeldung erzeugt und abgebrochen, andernfalls kann die Suche gestartet werden. Balter Martin, Kuschny Daniel, Müller Markus Seite 64 / 100

65 Zunächst wird die Datenbankverbindung aufgebaut und auf Basis dieser Verbindung ein FilterQueryParser erzeugt. Der FilterQueryParser übernimmt nun das Erstellen der Datenbankabfrage. Alle Filterkriterien rien werden durchlaufen, um die Datenbankabfrage zu erzeugen. Ist das Filterkriterium valide, wird das Filterkriterium in die Datenbankabfrage mit aufgenommen. Dies wird dadurch erzielt, dass dem FilterCriteria der aktuelle FilterQueryParser übergeben wird. Die durch den FilterQueryParser zur Verfügung gestellten Methoden, ermöglichen die benötigten Teilbereiche der Datenbankabfrage mit aufzunehmen, sowie die dazugehörigen Werte zu definieren. Nachdem die Datenbankabfrage generiert wurde, wird ein PreparedStatement erzeugt welchem die Werte des FilterQueryParser s zugewiesen werden. Nachdem die Datenbankabfrage abgesetzt wurde, werden alle Suchergebnisse in Transferobjekte geladen. Diese ermöglichen eine Abstraktion der Datenbankeinträge für die weitere Verwendung in der Oberfläche. Darstellung der Suchergebnisse Abbildung 9-41 Darstellung der Suchergebnisse Die Darstellung der Suchergebnisse bieten eine Reihe von Zusatzfunktionen, welche die Auswertung vereinfachen. Um die Suchergebnisse besser zuordnen zu können, werden die Zellen des Servernamens anhand der gegebenen Werte eingefärbt: Abbildung 9-42 Markierte Suchergebnisse Weiters hat der Anwender die Möglichkeit die Suchergebnisse zu sortieren. Abhängig von der Auswertung ermöglicht dies dem Anwender ähnliche Werte zu gruppieren. So kann beispielsweise von der Standardsortierung nach Zeit zur Sortierung nach Servernamen gewechselt echselt werden. Balter Martin, Kuschny Daniel, Müller Markus Seite 65 / 100

66 Abbildung 9-43 Sortierung der Suchergebnisse nach Servernamen Neben den Werten finden sich Symbole, welche die weitere Einschränkung der Suchergebnisse vereinfacht. Mit einem Klick auf das Symbol neben einem Wert, wird dieser in das zugehörige Filterkriterium aufgenommen. Mit einem Klick auf das Symbol neben LS_dka80 (Spalte Server) wird dieser Wert in das Filterkriterium für den Server übernommen: Abbildung 9-44 Schematischer Ablauf der Wertübernahme Balter Martin, Kuschny Daniel, Müller Markus Seite 66 / 100

67 In der letzten Spalte der Suchergebnisse befindet sich eine zusätzliche Aktionsspalte. In dieser Spalte finden sich zwei Schaltflächen. Die erste Schaltfläche ( ) ermöglicht eine Navigation zwischen den beiden Hauptansichten des HeartBeat Analyzer. Eine detaillierte Beschreibung dieser Funktion wird im Punkt MonitorAnalyse erläutert. Die zweite Schaltfläche ( ) öffnet ein Popup, welches Detailinformationen zum Eintrag darstellt und einen Versand zur Verfügung stellt. Detailansicht Die Detailansicht dient zur detaillierten Darstellung des ausgewählten Log-Eintrages. Durch das Klicken auf den rechten Button im Feld Aktionen wird ein Popup geöffnet, in dem sich die Detailansicht befindet. Abbildung 9-45 Detailansicht Button In dieser Detailansicht werden nochmals alle Informationen zu dem ausgewählten Log- Eintrag dynamisch geladen und strukturiert dargestellt. Abbildung 9-46 Detailansicht Balter Martin, Kuschny Daniel, Müller Markus Seite 67 / 100

68 Versand Im Popup Detailansicht, befindet sich ein weiterer Tab, in dem sich ein -Formular befindet. In diesem Formular ist es möglich einen Empfänger sowie einen Betreff und ebenfalls eine kleine Nachricht für den Empfänger zu schreiben. In das Kommentarfeld werden dynamisch die bereits geladenen Informationen des ausgewählten Log-Eintrags eingefüllt. Somit ist es möglich den Fehler an einen anderen Mitarbeiter zu senden, um eine möglichst schnelle Behebung des Problems zu erzielen. Die Authentifizierung erfolgt durch eine Konfigurationsdatei in dem sich alle Benutzerdaten befinden, um eine erfolgreich zu versenden. In der Datei MailConfig.xml wird nun der Benutzername, das Passwort, der Mail Server, der SMTP- Port, sowie der Mail Sender angegeben. Abbildung Formular Balter Martin, Kuschny Daniel, Müller Markus Seite 68 / 100

69 MonitorAnalyse Filterkriterienbeschreibung Für die MonitorAnalyse stellen folgende Spalten Filterkriterien zur Verfügung: Servername Da unterschiedliche Server auf dieselbe Datenbank und Tabellen zugreifen steht die Spalte CSERVERNAME zur Verfügung. Das Servername Filterkriterium ermöglich eine Einschränkung der Suchergebnisse ebnisse auf diese Spalte. Dieses Filterkriterium ist vom Typ Texteingabe. Von und Bis Im Punkt Datumseingabe wurde bereits erwähnt, in welchen Formaten Datumseingaben getätigt werden können. In den folgenden Absätzen wird erläutert, wie diese Datumseingabe abe verwendet werden kann, um mit zwei Datumsfeldern einen Zeitbereich eingrenzen zu können. Das Von-Filterkriterium in Kombination mit dem Bis-Filterkriterium ermöglicht eine Einschränkung der Suchergebnisse auf die Spalte DLOG der Monitoring-Tabelle.. Mittels diesen Filterkriterien ist es möglich einen Zeitbereich anzugeben, in welchem sich die Suchergebnisse befinden müssen. Diese Filterkriterien sind vom Typ Datumseingabe. Die Spezialeingabe von Millisekunden in diese Eingabefelder ermöglicht eine Zeitdifferenzangabe ifferenzangabe zwischen den beiden Filterkriterien. Nur eine der beiden Eingabefelder darf eine Millisekundenangabe beinhalten um eine korrekte Arbeitsweise zu gewährleisten. Variante 1: Wird im Von-Filterkriterium eine konkrete Datumseingabe vorgenommen, kann im Bis-Filterkriterium eine Millisekundenangabe gemacht werden. Um den gültigen Zeitbereich zu ermitteln, wird zum Wert des Von-Filterkriterium die Anzahl Millisekunden hinzugezählt und dadurch ein Zeitbereich eingegrenzt. Abbildung 9-48 Zeitbereichsberechnung Variante 1 Balter Martin, Kuschny Daniel, Müller Markus Seite 69 / 100

70 Variante 2: Die zweite Variante ist beinahe dieselbe wie Variante 1. Jedoch werden hier die Werte vertauscht. Im Bis-Datum muss eine konkrete Datumseingabe vorgenommen werden. Die Anzahl Millisekunden, welche im Von-Filterkriterium definiert sind, werden vom Bis-Datum abgezogen: Abbildung 9-49 Zeitbereichsberechnung Variante 2 MandantID Die MandantID ermöglicht eine Einschränkung auf den Kunden, welcher die Funktion aufgerufen hat. Dieses Filterkriterium ist vom Typ Texteingabe. BenutzerID Ein Mandant kann mehrere Zugänge für das System besitzen. Jener Benutzer, welcher die Aktion durchgeführt hat, kann durch dieses Filterkriterium eingeschränkt werden. Dieses Filterkriterium ist vom Typ Texteingabe. Funktion Dies ist die eigentliche Funktion, welche im System aufgerufen wurde. Durch dieses Filterkriterium können die durchgeführten Aktionen in Bereiche eingegrenzt werden. Dieses Filterkriterium ist vom Typ Texteingabe. SessionID Da sich ein Benutzer mehrmals eingeloggt haben kann, kann durch die SessionID festgestellt werden welche Funktionsaufrufe zu welcher Sitzung des Benutzers gehört. So können beispielsweise alle Schritte aufgelistet werden, welche ein Benutzer innerhalb einer Sitzung durchgeführt hat. Somit lassen sich etwaige Fehler zurückverfolgen. Dieses Filterkriterium ist vom Typ Texteingabe. Balter Martin, Kuschny Daniel, Müller Markus Seite 70 / 100

71 Globale und Lokale MonitorID Die globalen und lokalen MonitorIDs ermöglichen eine Gruppierung aller zusammenhängender Diagnostik-Informationen. Sollte sich ein Benutzer auf dem Hauptsystem, dem logistics-server, anmelden, so bekommt dieser eine SessionID zugewiesen. Es kann jedoch sein, dass im Laufe der Sitzung eine Aktion auf einem der anderen Systeme durchgeführt werden muss. Dazu loggt sich der Benutzer auf dem anderen System, beispielsweise dem pricing-server, ein und bekommt eine neue SessionID auf diesem System. Damit diese Aktionen auch gruppiert werden können, wurde die globale MonitorID eingeführt. Diese wird global über alle Systeme zugewiesen. Die lokale MonitorID ermöglicht eine Verknüpfung zwischen der MonitorAnalyse und der LogAnalyse. Mittels dieser ID werden die Einträge der LogAnalyse den Einträgen der MonitorAnalyse zugeordnet. Abbildung 9-50 Beispiel einer MonitorID Verwendung Der Benutzer führt eine Aktion auf dem logistics-server aus. Im Hintergrund löst diese Aktion eine Reihe von weiteren Aktionen aus welche auch über mehrere Applikationsserver, wie in diesem Beispiel den billing-server und den pricing-server, hinweg laufen können. Um diese Aktionen zu gruppieren, wurde die globale MonitorID a38fa-ba7-01 erzeugt, welche an die anderen Server weitergegeben wird, sobald eine Aktion auf dem anderen Server aufgerufen wird. Diese wird für alle Aktionen (Funktion1(), Funktion2(), Funktion3()) in der Datenbank gespeichert. Balter Martin, Kuschny Daniel, Müller Markus Seite 71 / 100

72 Für die Funktionsaufrufe werden Log-Informationen erzeugt, welche zusätzliche Daten über die Aktion des Benutzers beinhalten. Diese werden über die lokale MonitorID an den Funktionsaufruf gebunden. So wurden für den Funktionsaufruf Funktion1() zwei Infoobjekte in den Log-Daten erzeugt. LogAnalyse Filterkriterienbeschreibung Folgende Filterkriterien sind dieselben wie in der MonitorAnalyse: Servername Von und Bis MandantID BenutzerID SessionID Globale und Lokale MonitorID Diese Filterkriterien sind speziell für die LogAnalyse entwickelt worden: Priorität Dieses Filterkriterium ermöglicht eine Einschränkung auf den Typ des Log Eintrags. Wie bereits erwähnt, werden die Log-Einträge in unterschiedliche Kategorien unterteilt: Debug Informationen (DEBUG) Diese Informationen stellen Systeminformationen des System dar. Sie sind ausschließlich während der Testphase verfügbar. Zusatzinformationen (INFO) Informationen welche für eine Auswertung relevant sein könnten, werden unter dem Typ Zusatzinformationen abgelegt. Warnungen (ALERT) Sollte ein Benutzer eine Aktion durchführen welche in späterer Folge einen Fehler auslösen könnte, beispielsweise wenn eine Lieferadresse nicht ausgefüllt wird, kann es in späterer Folge zu einem Fehler beim Erfassen einer Lieferung kommen. Fehler (ERROR) Sollte eine Aktion durchgeführt werden, welche einen Fehler auslöst, wird dafür ein Log-Eintrag in der Datenbank abgelegt. Diese Fehler sind jene, die vom Benutzer in den Applikationen durch fehlerhaftes Anwenden, oder ein fehlerhaftes System ausgelöst werden. Balter Martin, Kuschny Daniel, Müller Markus Seite 72 / 100

73 Kritischer Systemfehler (FATAL) Kritische Systemfehler können dafür sorgen, dass das System nicht mehr funktioniert. Beispielsweise ein Fehler beim Zugriff auf die Datenbank wird als fataler Fehler eingetragen. Mittels diesem Filterkriterium kann bei der Fehleranalyse eingegrenzt werden welche etwaige Fehler oder Warnungen dazu geführt haben, dass ein Kunde seine gewünschten Aktionen nicht durchführen konnte. Kategorie Mit dem Kategorie Filterkriterium kann der Anwender eingrenzen in welchen Bereichen die Aktionen durchgeführt wurden. Als Wert ist hier die Klasse angegeben, in welcher der Eintrag geschrieben wurde. Balter Martin, Kuschny Daniel, Müller Markus Seite 73 / 100

74 9.6.3 HBD HeartBeat Diamond Allgemein Der HeartBeat Diamond, kurz HBD, ist eine Desktop-Applikation, pplikation, die auf einem externen Display bei inet-logistics alle Aktivitäten der Server visuell darstellt. Dieses Display wird an der zentralen Sammlungsstelle der Mitarbeiter von inet-logistics, dem Dorfplatz, installiert und ermöglicht den Mitarbeitern eine optisch-attraktive Darstellung der Serveraktivitäten. Sollte während einer Pause oder einer Besprechung eine wichtiges Ereignis wie beispielsweise ein Error auftreten, so sieht der Mitarbeiter dies auf dem Display und kann somit schneller handeln und den Fehler schneller beheben. Umsetzung Für die visuelle Darstellung des HBD wird ein Open-Soure- -Programm namens gltail verwendet. Mithilfe dieses Programmes ist es möglich, Log-Dateien zu überwachen und dies visuell darzustellen. Ebenso können Ereignisse, wie beispielsweise ein Login, auf dem System dargestellt werden. Für die Darstellung auf dem Display verwendet gltail die Grafikbibliothek OpenGL.. Abbildung 9-51 HeartBeat Diamond Log-Daten Auswertung Balter Martin, Kuschny Daniel, Müller Markus Seite 74 / 100

75 Oberfläche Auf der rechten und linken Seite des Programms befinden sich die wichtigsten 15 Module aus der JBMONMOD Tabelle. Dieser Bereich wird Column genannt (türkiser Bereich). In der Column befinden sich Blöcke (roter Bereich). Sie symbolisieren die unterschiedlichen Module, die es bei inet-logistics gibt. In den Blöcken werden die unterschiedlichen Funktionen (blauer Bereich) sortiert und dargestellt. Wenn eine Funktion aufgerufen wird, erscheint sie in einem Block pro Aufruf einer Funktion und es wird ein Bubble (oranger Bereich) erzeugt, dieser symbolisiert den Funktionsaufruf und fällt aus der Funktion heraus. Die Größe der Bubbles ist abhängig von der Ausführzeit der Funktion. Je mehr Zeit eine Funktion auf dem Server in Anspruch genommen hat, desto größer ist der Bubble. Wenn sich nur noch große Bubbles auf dem Bildschirm befinden, kann man erkennen, dass etwas mit dem Server nicht stimmt und sofort reagieren. Wenn im HeartBeat Diamond die Leertaste gedrückt wird, fangen die Bubbles an zu springen. Wird eine Funktion eines Moduls aufgerufen, erscheint für ihn ein Bubble. Die Funktionen werden anhand der Anzahl ihrer Aufrufe geordnet. Aufgrund der Bildschirmauflösung, können nicht alle Funktionen dargestellt werden somit werden nur die wichtigsten zehn Funktionen angezeigt. Der violette Bereich markiert Activities. Sie werden bei einem bestimmten Log-Eintrag erzeugt, wie zum Beispiel bei einem Login oder Warnungen. Balter Martin, Kuschny Daniel, Müller Markus Seite 75 / 100