SharePoint Designer 29.05.2009, 19:49 Uhr

Cleveres Tool mit Gefahrenpotential

Seit Anfang April 09 bietet Microsoft sein bis dahin kostenpflichtiges Web-Design-Werkzeug SharePoint Designer gratis zum Download an. Das für Power User gedachte Tool stellt, richtig eingesetzt, eine Reihe mächtiger Funktionen zum Bearbeiten und Weiterentwickeln von SharePoint Sites zur Verfügung. Ohne Vorkenntnisse und in den falschen Händen lässt sich mit dem Werkzeug allerdings auch Schaden anrichten oder der Versuch, eine Änderung durchzuführen, endet in einer Sackgasse. Wir liefern die wichtigsten Aspekte, die man vor dem Einsatz des Designers kennen sollte.
Autor: Urs BertschyWie Microsofts Web-Design-Tool Expression Web ist auch SharePoint Designer ein direkter Nachfolger des früher nicht überall beliebten FrontPage. Beide Tools haben allerdings nicht mehr allzu viel mit ihrem Vorgänger gemein und wurden stark überarbeitet. Aus Expression Web, das bereits in der Version 2.0 vorliegt, ist mittlerweile ein funktional reichhaltiges Web-Designtool mit einer durchdachten Benutzerführung geworden, das zudem mit einer soliden Standardunterstützung (CSS, XHTML etc.) aufwartet.SharePoint Designer, dessen Funktionalität weitgehend derjenigen von Expression Web 1.0 entspricht, wird von Microsoft als SharePoint-Design-Werkzeug für Power User positioniert. SharePoint Sites lassen sich via SharePoint-API direkt öffnen (auch über eine Remoteverbindung via HTTP). Der Benutzer erhält Zugriff auf alle in der entsprechenden Site gespeicherten SharePoint-Artefakte wie .Aspx-Seiten, Master Pages, CSS- und XSL-Stylesheets, Bilder etc. (Abbildung 1). SharePoint Sites lassen sich mit SharePoint Designer nahezu beliebig umgestalten. Dazu bietet das Tool einen Code- und einen WYSIWYG-Editor, Werkzeugkästen mit HTML-, ASP.NET und SharePoint-Controls, grafische Editierhilfen und CSS-Funktionen. Des Weiteren lassen sich auch einfache Administrationsaufgaben wie das Erstellen von neuen Listen oder Site-Backups durchführen.Workflow-FunktionenEin weiteres wichtiges Feature des Designers sind die Workflow-Funktionen, über die sich mit ein paar simplen Mausklicks Workflows inklusive Eingabeformularen und Verzweigungen erzeugen lassen. Zudem gibt es einige SharePoint-Features, für deren Nutzung explizit auf SharePoint Designer zurückgegriffen werden muss. Dazu zählt das durchaus praktische Data View Web Part (gelegentlich auch als Data Form Web Part bezeichnet), mit dessen Hilfe sich Daten aus unterschiedlichen Quellen (SharePoint-Listen, externe Datenbanken, Web Services, RSS-Feeds etc.) anzapfen und direkt in SharePoint Sites anzeigen und teilweise sogar editieren oder zurückschreiben lassen. Abbildung 1: SharePoint Designer bietet direkten Zugriff auf die verschiedenen Artefakte einer SharePoint-Site Die StolpersteineBereits die bisherige Aufzählung dürfte den Eindruck vermittelt haben, dass SharePoint Designer ein mächtiges Werkzeug für die Anpassung und Erweiterung von SharePoint Sites ist. Der Umkehrschluss ist leider, dass sich unsachgemäss genutzt oder in den sprichwörtlichen falschen Händen mit dem Werkzeug aber auch eine Menge Schaden anrichten lässt. Zudem gelangt man schnell einmal in eine Sackgasse, aus der man nur mühsam wieder herausfindet. Nachfolgend die wichtigsten Problemzonen.GhostingIn SharePoint werden die Web-Dateien einer Site in kombinierter Form auf dem Dateisystem und in der Datenbank gespeichert. So gibt es für jede Seite einer Site in der Datenbank einen Eintrag, der im Normalfall auf eine zentrale Datei im Filesystem verweist. In sämtlichen Sites, die von derselben Site Definition (mehr dazu in diesem DeveloperWorld-Artikel ) abstammen, wird immer auf dieselben Dateien verwiesen.Diese werden im SharePoint-Jargon als "uncustomized" bezeichnet. Werden nun via SharePoint Designer Änderung an einer Datei vorgenommen, wird diese anstelle des Verweises als eigene, angepasste Variante ("customized") direkt in der Datenbank gespeichert und damit von der zentralen Datei der Site Definition entkoppelt. Dieser Prozess nennt sich Unghosting.Der grosse Vorteil der "uncustomized" Webseiten ist aber, dass man diese an zentraler Stelle anpassen und damit gleich auf eine Vielzahl von Sites anwenden kann. Bei den durch das Unghosting entkoppelten Dateien verliert man diesen Vorteil, so dass man beispielsweise eine firmenweite Änderungen am Look&Feel der SharePoint-Umgebung bei jeder "customized" Seite von Hand nachtragen müsste. Diese Problematik wird seit WSS 3.0 und MOSS 2007 durch den Einsatz von Master Pages etwas entschärft, ist aber nach wie vor gegenwärtig. Ein weiterer Nachteil, der sich durch das Unghosting ergibt, ist die etwas niedrigere Performance, die sich durch den Abruf von "customized" Webseiten aus der Datenbank ergeben kann. In Umgebungen mit sehr hohem Traffic-Aufkommen kann es hier zu spürbaren Performance-Einbussen kommen. Abbildung 2: Mit SPD angepasste Webseiten werden von der zentralen Dateivorlage abgekoppelt und als "customized" Variante (am blauen Symbol mit dem Ausrufezeichen zu erkennen) in der Content-Datenbank gespeichert. DeploymentSharePoint Designer bietet keine direkte Unterstützung für das Deployment zwischen unterschiedlichen SharePoint-Umgebungen. Ein einfaches Verschieben von Anpassungen zwischen Development-, Test- und Produktionsumgebung (durch den Power User) ist nicht vorgesehen. Das bedeutet, dass man die eigenen Anpassungen direkt auf dem Produktionsserver vornehmen muss, was weder zu empfehlen, und wohl auch in vielen Unternehmen ein absolutes Tabu ist. Umgehen lässt sich dieses Problem, indem man SharePoint Designer quasi als Prototyping-Tool einsetzt. Dabei werden die gewünschten Anpassungen in einer Testumgebung vorgenommen. Die bearbeiteten Dateien werden anschliessend aus SharePoint Designer exportiert und an einen Entwickler übergeben, der diese in ein Feature resp. eine SharePoint Solution (WSP, mehr dazu in diesem Developer World-Artikel ) verpackt. Als SharePoint Solution lassen sich die gemachten Änderungen dann problemlos zwischen den einzelnen Umgebungen verschieben. Mit diesem Verfahren lässt sich übrigens auch gleich das im vorgängigen Abschnitt erwähnte Problem des Ghostings umgehen, weil sich die betroffenen Webdateien als "Uncustomized"-Versionen via Feature/Solution direkt auf dem Filesystem installieren lassen.Eingeschränkter WorkflowUnter mangelnden Deployment-Optionen leidet auch die an sich elegante Workflow-Funktion in SharePoint Designer. Einmal erstellte Workflows sind fix an die Liste einer Site gebunden und können weder global genutzt noch in eine andere Site oder SharePoint-Umgebung transportiert werden. Eine einfache Lösung für diese Einschränkung gibt es leider nicht: Wer universell einsetzbare Workflows benötigt, muss entweder auf ein Tool eines Drittherstellers wie etwa K2 BlackPoint [1] oder Nintex Workflow [2] urückgreifen oder diesen in Visual Studio auf Basis der Windows Workflow Foundation (WF) von Hand erstellen. Letzteres kann bei mittleren bis komplexen Workflows zu einem zeit- und kostenintensiven Unterfangen ausarten. Abbildung 3: Workflows lassen sich im Point&Click-Verfahren sehr schnell zusammenstellen, sind dann aber fix an eine Liste und Site gebunden. Ghosting beim Data View Web PartMit dem Data View Web Part, das sich wie erwähnt nur via SharePoint Designer nutzen lässt, können Daten aus externen Quellen sehr elegant und ohne eine Zeile Code schreiben zu müssen, auf SharePoint-Webseiten integrieren. Allerdings wird beim Speichern einer SharePoint-Seite mit eingesetztem Data View Web Part ebenfalls der Ghosting-Prozess mit den bereits genannten Nachteilen in Gang gesetzt. Dies lässt sich immerhin relativ leicht umgehen, indem man das Web Part zunächst auf einer Testseite mit SharePoint Designer einrichtet und über die Export-Funktion (via Titelleiste des Web Parts) dessen Konfigurationsfile auf der Festplatte speichert. Das erhaltene .webpart-File kann man anschliessend auf der gewünschten Seite wieder importieren und die Testseite löschen. Abbildung 4: Das Data View Web Part erlaubt es, Daten aus unterschiedlichen Quellen in einer Site darzustellenWann und wie einsetzen? Wie die Ausführungen zeigen, sollte SharePoint Designer nur mit der nötigen Vorsicht genutzt werden. Der Zugriff auf eine produktive SharePoint-Umgebung sollte, wenn überhaupt, nur geschulten Power Usern und auch nur auf entsprechend dafür vorgesehene Sites gewährt werden [3]. Trotz den erläuterten Risiken kann es in gewissen Szenarien Sinn machen, SharePoint Designer direkt in einer produktiven Umgebung anzuwenden. So ist das SharePoint-Tool im gehosteten Betrieb oft die einzige Option, um eigene Anpassungen vornehmen zu können. Auch bei einfacheren, dedizierten Lösungen, bei der nur einzelne oder wenige Sites (z.B. zu Collaborations-Zwecken) eingesetzt werden, kann SharePoint Designer für die Durchführung von eigenen Anpassungen und zum Aufsetzen eines Workflows die kostengünstigste Alternative sein. AutoreninfoUrs Bertschy ist Inhaber der auf Web- und SharePoint-Consulting/-Development spezialisierten Bertschy Informatik AG. Sie erreichen ihn via http://www.bertschy.ch.Interessante Links[1] http://www.k2.com/en/blackpoint.aspx[2] http://www.nintex.com/en-US/Products/Pages/Workflow2007.aspx [3] http://blogs.msdn.com/sharepointdesigner/archive/2008/11/25/locking-down-sharepoint-designer.aspx Peter Monadiemi


Das könnte Sie auch interessieren