Microsoft SharePoint® Lösungspaket zur Visualisierung von Geostandorten

Inhaltsverzeichnis

1 Projektbeschreibung
1.1 Einführung
1.2 Projektanstoß
1.3 Projektumfeld

2 Planungsphase
2.1 Projektplan
2.2 IST-Analyse
2.3 Kostenplan
2.4 Soll-Konzept
2.4.1 Funktionalitäten
2.4.2 Sicherheit
2.4.3 Integration in bestehende Intranetanwendung

3 Entwurfsphase
3.1 Software-Architektur und eingesetzte Technologien
3.2 Bestandteile des Lösungspakets
3.2.1 Webparts
3.2.2 Maps-Adressliste und Content-Type
3.2.3 Setupkomponente

4 Implementierungsphase
4.1 Installation und Konfiguration der Entwicklungsumgebung
4.2 Strukturierung Visual Studio Projekt Solution
4.3 Entwicklung der Webparts
4.4 Maps Adressliste und Content-Type
4.5 Zusätzlicher Quellcode

5 Testphase

6 Projektbewertung
6.1 Zielerreichung
6.2 Soll/Ist-Abgleich Projektphasen
6.3 Qualitätssicherung
6.4 Änderungen gegenüber Projektantrag

7 Fazit und Ausblick

8 Literaturverzeichnis

9 Anhang

1 Projektbeschreibung

1.1 Einführung

Der Kunde (richtiger Kundename darf namentlich nicht genannt werden) ist ein erfolgreiches Unternehmen im Gesundheitsgewerbe mit mehreren Standorten in der Region Norddeutsch- land. Der Kunde betreut Therapiepatienten im Rehabilitations- und Präventionsbereich.

Zu den Aufgaben der Verwaltungsabteilung gehören u. a. die Planung und Durchführung von Abhol- und Bringdiensten für Patienten, die die jeweiligen Therapiestandorte eigenständig nicht erreichen können.

Aufgrund der Vielzahl von Patienten, deren Abholorte eine große räumliche Ausdehnung zueinander besitzen, sollen die Fahrtrouten mit einem unternehmensweit einsetzbaren System optimiert werden.

1.2 Projektanstoß

Im vergangenen Jahr hat der Kunde eine Kollaborationsplattform auf Basis von Microsoft Windows SharePoint® Services 3.0 im Unternehmen etabliert. Die Webanwendung dieser Plattform bietet berechtigten Mitarbeitern Zugriff auf gemeinsam genutzte Ressourcen wie Dokumente, News- und Kalendereinträge sowie Adressinformationen. Der Wunsch nach Einbindung der bereits vorhandenen Adressinformationen in eine Lösung zur Visualisierung von Patientenstandorten ist ein wichtiger Schritt der Optimierung von Arbeitsprozessen und damit eine Reduzierung von Kosten.

In einer ersten Realisierungsphase, die im Rahmen dieser Projektarbeit abgedeckt wird möchte der Kunde die Standorte der Patienten auf einer Geokarte visualisieren.

1.3 Projektumfeld

Das Projekt wird in der Abteilung „Software-Engineering“ der Firma EVES Information Technology AG durchgeführt. Es ist ein Projekt in enger Zusammenarbeit mit dem Kunden.

Projektleiter und Ausführender ist Alexander Röhrig, Auszubildender im Beruf Fachinformati- ker - Fachrichtung Anwendungsentwicklung. Projektverantwortlicher ist der Ausbildungsleiter Martin Bravin.

Die Abarbeitung der Testfälle wurde durch Herrn Damian Burghardt unterstützt.

2 Planungsphase

Die Planungsphase enthält Projektplan, Ist Analyse und Soll-Konzept (Pflichtenheft).

2.1 Projektplan

Die folgende Auflistung stellt das Gesamtprojekt mit den Aufwänden der einzelnen Teilschritte dar. Der Gesamtaufwand beträgt 70 h.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Soll-Aufwände für die Teilphasen des Projekts

Die Teilaufgaben des Gesamtprojekts wurden in Microsoft Project 2007 übertragen (siehe Anhang A Projektplan).

2.2 IST-Analyse

Prozess der Planung von Fahrtrouten

Der Planungsprozess wurde in einem halbstündigen Gespräch gemeinsam mit dem verant- wortlichen Projektleiter des Kunden besprochen. Das Ergebnis des Gesprächs lautete wie folgt:

Der Kunde nutzt für die Erfassung von Adressinformationen eine proprietäre Softwarelösung (Therapieorganisation - THEORG), die u. a. auch die Verwaltung von Abrechnungsprozessen mit den Kostenträgern (Kranken- und Pflegekassen) übernimmt.

Die Patienten vereinbaren Termine für die Durchführung von rehabilitativen Maßnahmen, die in diese Software eingegeben werden.

Der Abholzeitpunkt muss von dem verantwortlichen Mitarbeiter ohne Kenntnis der genauen Patientenstandorte festgelegt werden.

Schlussfolgerung aus der IST-Analyse

Die Planung der Abholtermine erfolgt ausschließlich durch einen erfahrenen Mitarbeiter unter erheblichem Zeitaufwand.

2.3 Kostenplan

Die Kostenplanung beschreibt die Wirtschaftlichkeit der zu entwickelnden Software. Sie führt genauere Kostendetails auf.

Kosten-Stundensatz Entwicklung: 58,00 € Kosten- Stundensatz Kunde: 40,00 €

Abbildung in dieser Leseprobe nicht enthalten

Vergleich Kosten für die Planung von Patientenrouten

Abbildung in dieser Leseprobe nicht enthalten

Amortisierungsdauer

Entwicklungskosten : Ersparnis = Dauer 3596,00 € : 9600,00 € ≈ 4,5 Monate

Die Entwicklungskosten würden beim Einsatz der Software in etwa 4,5 Monaten gedeckt sein.

2.4 Soll-Konzept

Im Soll-Konzept werden die Anforderungen an das Projekt beschrieben. Es wird festgelegt ich welcher Form das Lösungspaket zu erstellen ist.

Im Folgenden werden die wesentlichen Punkte des Soll-Konzepts aufgezeigt. Die detaillierten Anforderungen sind in der Anlage B Pflichtenheft beschrieben.

2.4.1 Funktionalitäten

Auf die Geokarte soll aus dem Intranet (Windows SharePoint® Services Webanwendung) zugegriffen werden.

Die Adressinformationen für die Markerpunkte auf der Karte sollen in einer SharePoint Liste gespeichert werden.

2.4.2 Sicherheit

Der Zugriff auf die Adressinformationen unterliegt den allgemeinen Richtlinien für Datenschutz und Datensicherheit.

Es dürfen nur berechtigte Benutzer auf die Adressdaten zugreifen.

Das Lösungspaket soll im Sicherheitskontext des SharePoint® Systems für die jeweils angemeldete Windows-Benutzeridentität ausgeführt werden.

2.4.3 Integration in bestehende Intranetanwendung

Die Lösung soll sich vollautomatisch als ausführbare „exe“ Datei in die SharePointWebanwendung integrieren lassen, um dem Kunden eine anwenderfreundliche und kostensparende Installationsmöglichkeit zu bieten.

3 Entwurfsphase

In der Entwurfsphase wird festgelegt in welcher Weise die erforderlichen Komponenten implementiert und welche Entwicklungsstrategien verfolgt werden.

3.1 Software-Architektur und eingesetzte Technologien

Die Integration von Kartenfunktionaliät in eine bestehende WSS^[1]-Webanwendung erfordert eine genaue Planung der benötigten Komponenten, detailliertes Wissen über die Architektur, die Entwicklungskonzepte und eingesetzte Technologien sowie über die Möglichkeiten der Integration interaktiven Kartenmaterials.

Die Entwicklung auf Basis einer SharePoint Anwendung erfordert die Erstellung von .NET Framework basiertem Quellcode in der Programmiersprache C# sowie die Entwicklung von XML^[2]-Schemadefinitionen für SharePoint Listen. Die Integration der Geokarte wird über eine Maplet-Server API^[3] in JavaScript realisiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Integration der Geokarte in eine Intranetanwendung auf Basis von Windows SharePoint Ser- vices

3.2 Bestandteile des Lösungspakets

Das Lösungspaket soll als voll funktionsfähige Anwendungserweiterung^[4] in einer beliebigen Webanwendung eines SharePoint Systems (Version 3.0) integrierbar sein.

Nach der Installation und Aktivierung des Lösungspakets werden folgende Funktionalitäten laut Soll-Konzept in der Webanwendung bereitgestellt:

- Ein SharePoint-Webpart mit einer Google Karte und einer Bing^[5] Karte
- eine Maps-Adressliste für die Speicherung der adressbezogenen Standortinformationen aus dem THEORG-Programm
- Ein Adresslisten-Inhaltstyp, der an die Adressliste geknüpft ist und folgende Listenfelder besitzt: Name (Patientenname), Straße, Postleitzahl, Ort
- Eine Setup-Komponente, die das Lösungspaket auf dem SharePoint System instal- liert

3.2.1 Webparts

Die Webparts stellen einen HTML/JavaScript-Container für die Darstellung der Karte in der Windows SharePoint Services Webanwendung dar.^[6]

Die Webparts werden mit der .NET Technologie entwickelt, der erstellte Code wird vom SharePoint System serverseitig ausgeführt und an den Webbrowser gesendet.

Bei der Entwicklung steht der komplette Funktionsumfang des Microsoft .NET Frameworks Version 3.5 zur Verfügung. Somit ist eine kostengünstige, robuste und vom Hersteller unterstützte Entwicklung und Betrieb möglich.

Karten APIs

Die Anbieter Google und Bing stellen eigene APIs zur Einbindung von interaktivem Kartenmaterial auf Webseiten zur Verfügung.

Die Funktionalität beider Kartensysteme ist weitestgehend identisch und umfasst u. a. folgende Funktionalitäten:

- Interaktive 2D-Darstellung von Straßen- und Geländeinformationen
- Zoom-In und Zoom-Out Funktion
- Darstellung von Markern bzw. Pins (Markerpunkte auf der Karte) auf Grundlage von Längen und Breitengraden oder Adressinformationen (reverse Geokodierung)
- Interaktive 3D Darstellung (z. b. Streetviews) nach zusätzlicher Installation eines Browser-Plugins

Die Nutzung der Google Maps API erfordert die Registrierung eines API-Schlüssels, was momentan noch kostenfrei^[7] möglich ist und damit keine weiteren Folgekosten für den Kunden verursacht.

Beide Anbieter bieten eine JavaScript-basierte Lösung an, die sich in bestehende Webanwendungen integrieren lässt.

Da mehrere Kartentypen unterstützt werden sollen, muss von einer abstrakten WebpartBasisklasse abgeleitet werden, um einen höheren Programmieraufwand zu vermeiden und die Wartbarkeit des Codes zu erhöhen.

Die abstrakte Basisklasse „MapsWebpart“ leitet von Micro-

soft.SharePoint.WebPartPages.WebPart ab und soll gemeinsame Kartenoptionen wie z. B.

Höhe und Breite der Karten über ein Interface bereitstellen. Die abgeleiteten Klassen besit- zen erweiterte kartenspezifische Eigenschaften, wie die Anzeigemöglichkeit verschiedener Kartensteuerelementen. Die Implementierung dieser Eigenschaften wird über eigene Inter- faces (~MapsWebpartProperties) erzwungen (siehe dazu auch Anhang E Vererbungsmodell für die Webpartklassen).

3.2.2 Maps-Adressliste und Content-Type

Die Maps-Adressliste ist eine SharePoint Liste, die durch eine separate Software mit den Adressdaten aus dem THEORG-System befüllt wird.

Die Entwicklung dieser Lösung ist nicht Bestandteil der Projektarbeit.

Um eine höchstmögliche Flexibilität für den Endanwender zu ermöglichen ist die Änderung des Adressdatenbestands in der Liste auch nach dem Import mit dem THEORG-System möglich.

Die Adressdaten müssen für die Visualisierung in der Karte in einem bestimmten Format vorliegen und vor der Speicherung validiert werden. Dafür wird ein SharePoint Content-Type (Inhaltstyp) für die Adressliste erstellt, der festlegt welche Feldwerte in welchem Datenformat in der Liste speicherbar sind.

- Name des Patienten (Textfeld, max. Länge 255 Zeichen)
- Strasse (Textfeld, max. Länge 255 Zeichen)
- PLZ (Textfeld, max. Länge 5 Zeichen)
- Ort (Textfeld, max. Länge 255 Zeichen)

Der Content-Typ stellt außerdem sicher, dass in den Formularen („Neue Adresse hinzufügen“ und „Adresse bearbeiten“) Eingabefelder für die Daten bereitgestellt werden. Diese Entscheidung trägt auch zur Robustheit der gesamten Lösung bei.

3.2.3 Setupkomponente

Die Setupkomponente besteht aus der Anwendung SharePoint Solution Installer^[8], einer XML^[9]-Konfigurationsdatei sowie der im WSP-Format^[10] gepackte Code, der die MapsAdressliste, den Content-Type sowie der Webparts enthält.

Durch die Setupkomponente wird sichergestellt, dass alle Funktionalitäten auf dem SharePoint Zielsystem bereitgestellt werden.

Der WSP-Builder^[11] (nicht Bestandteil des Lösungspakets) ist ein Visual Studio Add-IN und ermöglicht die Kompilierung des Quellcodes eines Visual Studio Projekts in eine WSP- Datei^[12].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Erzeugung und Installation des Lösungspakets

4 Implementierungsphase

4.1 Installation und Konfiguration der Entwicklungsumgebung

Die Erstellung des Projekt-Quellcodes erfordert eine entsprechend konfigurierte Entwicklungsumgebung.

Für die Installation der Entwicklungsumgebung wird ein virtualisiertes Windows 2003 Server System als Hostsystem aller Entwicklungskomponenten verwendet.

Eine vorkonfigurierte Entwicklungsumgebung (laut Anhang F Komponenten der Entwicklungsumgebung) wurde von der Abteilung IT & Mobile Solutions der Firma EVES-IT bereitgestellt und wird daher hier nicht weiter beschrieben.

4.2 Strukturierung Visual Studio Projekt Solution

Für die Erstellung des Lösungspakets wurde ein neues Visual Studio Projekt auf Basis einer WSP-Builder Projektvorlage erstellt (siehe dazu auch Anhang E Visual Studio Projektstruktur). Die Projektvorlage ermöglicht ein Anpassung bereits vordefinierter Projektdateien und damit einen schnellen Entwicklungszyklus.

Ordnerstruktur

Die Struktur der angelegten Ordner entspricht dem Filesystem der Windows SharePoint Services Webanwendung. Bei der Installation des Lösungspakets auf dem WSS-Server werden die erstellten Dateien (XML-Schemadefinitionen und JavaScripte) automatisch in die entsprechenden Ordner gespeichert. Die Struktur stellt somit ein Mapping für die Verzeichnisstruktur der Windows SharePoint Services Webanwendung dar und ist für die Integration des Lösungspakets unbedingt erforderlich.

4.3 Entwicklung der Webparts

Durch Überschreiben der virtuellen Funktion „CreateChildControls“ der Webpart-Basisklasse „MapsWebpart“ kann HTML/JavaScript-Code bereitgestellt werden, der später auf der SharePoint Webanwendung als Karte angezeigt wird.

Der JavaScript-Code wird dynamisch über ein Objektmodell (siehe Anhang E Modell für die Interaktion der .NET Klassen zur Zusammenstellung des JavaScript Codes) zusammenge- stellt. Wesentlich sind hierbei die Verbindungsklasse „Adresshandler^[13]“, die Adressen aus der SharePoint Adressliste holt und diese Adressdaten dem „JSHandler^[14]“ bereitstellt. Der „JSHandler“ bereitet die Daten als JavaScript auf und übergibt eine Anfrage an die jeweilige Karten-API. Die Karten-API kann dann die Karte mit Markerpunkten für jede Adresse zu- rückgeben.

Durch dieses modulare Konzept der Kapselung der Basisfunktionalitäten konnte eine sehr gute Wartbarkeit, Nachvollziehbarkeit und Testability des Quellcodes auch für andere Entwickler erreicht werden. Zudem ist es möglich über die entsprechende Sichtbarkeit von Klassen und Funktionen eine Wiederverwendbarkeit für Erweiterungen zu erreichen.

4.4 Maps Adressliste und Content-Type

Das SharePoint System benötigt eine XML-Schemadefinition für die Abbildung einer SharePoint Liste in der Webanwendung. Der Quellcode dieser Schemadefinition beinhaltet die wichtigsten Einstellungen für die Liste, u. a. Name, ID und Inhaltstypen.

Der XML-Code unterliegt einem von Microsoft geforderten Schema und wird bereits von der Entwicklungsumgebung während der Designzeit validiert. Somit ist bereits jetzt sichergestellt, dass kein fehlerhafter Quellcode produziert wird.

XML-Schemadefinition für Adressliste

Die Schemadefinition der Adressliste gibt an, in welcher Form die Adressliste auf dem Sha-

rePoint System bereitgestellt wird (siehe dazu auch Anhang

Schemadefinition für die Maps-Adressliste).

XML-Schemadefinition für Content-Type

Die Erstellung des Content-Types erfolgt ebenfalls auf Basis einer XML-Schemadefinition.

Die Schemadefinition enthält über das XML-Element „FieldRef“ alle Einstellungen über die Adressfelder, die in der Maps-Adressliste benötigt werden.

Das Attribut „ID“ des „Content-Type“ Elements wird in der Maps Adressliste referenziert. Damit wird eine Zuordnung des Content-Types zur Adressliste sichergestellt.

4.5 Zusätzlicher Quellcode

Für die Aktivierung, bzw. Deaktivierung des Lösungspakets in der Windows SharePoint Ser- vices Webanwendung wurde noch zusätzlicher Quellcode (FeatureReceiver-Code) benötigt.

Der Code übernimmt folgende Funktionalitäten, die die Integrität des Lösungspakets in der Webanwendung sicherstellen:

- Aktivierungsfunktionen

Es müssen alle Bestandteile des Lösungspakets einzeln aktiviert werden, damit das Gesamtpaket in den aktiven Zustand gesetzt wird.

Es wird überprüft, ob die SharePoint Anwendung alle benötigten Voraussetzungen (Konfigurationseinstellungen, abhängige Features) bereitstellt, bevor das Lösungspaket aktiviert werden kann.

- Listenfunktionen

Erstellung der Listeninstanz der Maps Adressliste nach Aktivierung des MapsLösungspakets sowie einen Link in der SharePoint Navigationsleiste

- Deaktivierungsfunktionen

Deaktivierung bzw. Entfernen aller Bestandteile (Navigationslink und Listeninstanz der Maps-Adressliste, Entfernen der Webparts und des Content-Types) nach Deaktivierung des Lösungspakets

5 Testphase

In der Testphase wurden sowohl die Integrationsfähigkeit sowie die Funktionalität des Lösungspakets getestet.

Alle Testfälle^[15] wurden von Alexander Röhrig erstellt und von einer zweiten eingewiesenen Person durchgeführt. Diese Methode hat sich in vergangenen Projekten bewährt und ist ein allgemeiner Standard für Softwareentwicklungsprojekte.

Die Testfälle wurden in einem Testprotokoll aufgeführt und sind jeweils pro Testdurchlauf vollständig abgearbeitet wurden bis kein Fehler in der Anwendung mehr auftrat.

6 Projektbewertung

Die Projektbewertung beschreibt, ob Zielvorgaben und Zeitplanungen eingehalten wurden.

6.1 Zielerreichung

Nach der erfolgreichen Einführung des Lösungspakets konnte die Reduzierung des Arbeitsaufwandes für die Planung von Patientenrouten durch den Kunden bestätigt werden.

Der Kunde hatte nach der Planungsphase den Wunsch nach der Einbindung eines zweiten Kartenanbieters geäußert. Dadurch ergaben sich geringfügig höhere Entwicklungsaufwände, die durch das Konzept der Ableitung einer abstrakten MapsWebpart-Klasse für beide Kar- tenanbieter im Rahmen der geforderten Projektdauer ausgeglichen werden konnten.

6.2 Soll/Ist-Abgleich Projektphasen

Der im Antrag vorgestellte Zeitplan mit einem Gesamtaufwand von 70 Stunden wurde einge- halten. Der höhere Aufwand durch die nachträglich geforderte Kartenerweiterung konnte durch weniger Aufwand im Bereich des Testings und der Planung ausgeglichen werden.

Tabelle 2: Soll/Ist-Vergleich der Projektaufwände

Abbildung in dieser Leseprobe nicht enthalten

6.3 Qualitätssicherung

Der erstellte Quellcode wurde zeitgleich mit der Erstellung mit Kommentaren versehen. Die Integrität der XML-Schemadefinitionen wurde durch zusätzliche Funktionstests auf Webanwendungsebene sichergestellt. Das SharePoint System erlaubt keinen fehlerhaften XMLCode. Fehler im Quellcode wurden vom SharePoint System in Form von Exceptions in der Webanwendung und im Eventlog des Servers angezeigt.

Bei der Installation des Lösungspakets überprüft der Sharepoint Solution Installer ebenfalls den bereitgestellten Quellcode. Somit konnte die Installationsfähigkeit des Pakets vor der Auslieferung einwandfrei sichergestellt werden.

[...]

---

^[1] Windows SharePoint Services

^[2] Extensible Markup Language

^[3] Application Programming Interface

^[4] vergleichbar mit dem Begriff Plugin oder Extension

^[5] Microsoft Corporation

^[6] Webpart: in C.NET entwickelter Container für HTML-Quellcode der serverseitig gerendert wird

^[7] Registrierung Google-Maps Api-Schlüssel unter http://code.google.com/apis/maps/signup.html

^[8] Microsoft, http://sharepointinstaller.codeplex.com/

^[9] Extensible Markup Language

^[10] WSP-Format ist ähnlich zip-Format und vom Hersteller empfohlen

^[11] Free Software Foundation, Inc., http://wspbuilder.codeplex.com/, (Open-Source-Projekt)

^[12] WSP - Windows SharePoint Solution Package

^[13] Adresshandler - Verbindungsklasse zwischen Adressliste und Webpartklassen

^[14] JSHandler -.NET Klasse zum dynamischen Erzeugen von JavaScript Code

^[15] siehe Anlage C Testprotokolle