SharePoint Community Camp 24.&25. April 2008

Heute auf dem Programm stand "Datenansichten mit SharePoint Designer" (Michael Greth), "Gestaltung und Anpassung von SharePoint Plattformen" (Fabian Moritz), SharePoint Workflows erstellen" (Daniel Wessels) und "Best Practices/Tipps für die Umsetzung von Web Content Management Systemen auf Basis von MOSS" (Fabian Moritz).

Im ersten Slot wurden die Möglichkeiten von Datenansichten aufgezeigt. Nachdem gestern die Dataviews genutzt wurden, um die Suchresultat anzupassen, wird heute der Fokus stärker auf die Verknüpfung von Daten gelegt. Auch lag hier der Schwerpunkt auf die Nutzung des SharePoint Designers, welcher gute Unterstützung für Nicht-Entwickler bietet, um Anpassungen selber durchzuführen. Über bedingte Formatierungen und individuelle Filterkriterien, können
so gute Übersichts- und Auswertungsviews erstellt werden.
Was eher zu kurz kam, sind die Nachteile vom SharePoint Designer. Es muss bewusst sein, dass die Anpassungen jeweils nur für diese Seite greifen, auf welcher die Anpassungen gemacht werden. Für wiederverwendbare Komponenten, was oft bei grösseren Unternehmen benötigt wird, sollte zwingende die Funktionalitäten über Features implementiert werden. Da sehe ich den SharePoint Designer eher als Tool fürs Prototyping, die Umsetzung dabei erfolgt von den Entwicklern im Visual Studio.

Der zweite Slot zeigte anhand verständlicher Demos, die verschiedenen Stufen der Anpassungen innerhalb von SharePoint. Über Administrator, Publisher bis hin zum Entwickler.
Zwar wurden die Gefahren der Tools erklärt, aber auch die Vorteile der Eigenentwicklung eher in den Hintergrund gerückt. Obwohl die Eigenentwicklung zeitaufwendiger ist, erhöht das die Kontrolle über den Code und erleichtert das Change Management und Bug Fixing enorm.

Der Nachmittag begann mit der Session "SharePoint Workflows".
Sehr detaillierte Demo, wie der im SharePoint Umfeld bekannte Ferienantrag mittels InfoPath und SharePoint Designer erstellt werden kann. Dabei wurde ein 3-stufiger Workflow erstellt (Antragsteller --> Vertreter --> Manager). Die Demo bestätigt, dass für einfache Workflows, wie Spesenabrechnungen, Ferienanträge etc. SharePoint durchaus sinnvoll eingesetzt werden kann. Aber es ist nicht zu vergessen, dass die Transaktionalität nicht unterstützt wird und so für Businesskritische Prozesse auf einen anderen Workflowhost ausgewichen werden muss.

Zum Abschluss wird noch auf das Web Content Management eingegangen.
In einer Kurzen Präsentation wird der Weg zum Web Content Management aufgezeigt. Von der Erstellung von Publishing Sites, Erstellen Masterpages mit Bilder und Styles bis hin zur Anwendung von Page Layouts. Gute Einführung ins Web Content Management. Das Fazit kam zum Schluss: Man hat viele Möglichkeiten, aber es gibt viele Anpassungen und Eigenentwicklungen zu machen, für eine komplette Webseite.
Am Schluss noch einige Beispiele von Webseiten auf Basis von MOSS, leider fehlte die von namics erstellte Seite von www.nestle.ch :-)

Für grosse Unternehmungen könnte es einen grossen Vorteil bedeuten, wenn man aus Worddokumente Webseiten erstellen könnte. In vielen Fällen nutzen die Autoren Word als das Authoring-System. So können die Dokumente einfach an externe Übersetzungsbüros gesendet oder offline weiter bearbeitet werden. Erst am Schluss wird der Inhalt ins Content Management System kopiert.

MOSS 2007 bietet eine Document Conversion an. Dieser ermöglicht das Erstellen von WebPages aus Word-, Infopath- und XML-Dokumente.
In diesem Beitrag soll aufgezeigt werden, wie und wo die Grundeinstellung für die Document Conversion sind und wie tauglich das Ganze ist.

Als erstes muss in der Central Administration unter
Central Administration > Application Management > Configure Document Conversions
die Document Conversion für die entsprechende Webapplikation aktiviert werden.

Der Loadbalancer muss zwingend eine andere Webapplication sein, sonst erscheint nur eine Fehlermeldung.

Nun steht die Funktion in allen Document Libraries in der Webapplication zur Verfügung.
Die Funktion wird über das Kontextmenu aufgerufen.

Wird die Funktion ausgeführt, merkt man, dass es selten der gewünschte Weg ist Inhalte zu publizieren.
Zwar werden Text mit Textformatierungen zu einer Page konvertiert (Die Page liegt übrigens auf derselben Site in der Pagegallerie)

Es werden aber keine Text unabhänigigen Formatierungen (Backgroundimages) oder auch keine Bilder konvertiert. Auf der Seite findet man zwar den Platzhalter, aber das Bild fehlt.
Grund liegt in der Natur von SharePoint, dass die Bilder als Ressourcen separat gespeichert werden. D.h. der Autor muss so oder so, auf dem SharePoint die Bilder hinterlegen.

Es wäre möglich mit Bilder im Word zu arbeiten. Dafür müssten die Bilder in MOSS vorhanden sein und das Bild als "Link to File" eingefügt werden. Dies ist aber für den Durchschnittsuser kein gangbarer Weg.

Es können auch verschieden PageLayouts verwendet werden, aber man kann nur ein Feld im Page Layout füllen.

Dies wird auf Basis des Content Types definiert.
Unter Site Actions> Site Settings> Modify All Site Settings > Site content types (im Block Galleries) kommt man auf folgende Ansicht:

Jetzt sind die Einstellung für die Document Conversion verfügbar.
Hier kann das zugehörige Page Layout und das Feld definiert werden, in welches die Inhalte eingefügt werden:

An eine geniale Funktion hat Microsoft aber gedacht. Die Verbindung zum Source Document bleibt vorhanden. so kann ich direkt aus der Seite das Source Document öffenen oder automatisch die Page auf Basis des Source Document updaten.

So ist es möglich, dass Autoren nur jeweils das Word bearbeitet wird und man auf der Page ein Update durchführen kann.

Fazit
Die Idee ist grundsätzlich zu begrüssen, leider steckt dies noch in den Kinderschuhen. Bilder werden nicht übernommen und auch Spalten werden nicht aufgelistet. Für Einspaltige und nur Textseiten kann es aber genutzt werden. Die Frage ist nur, ob es sich für den Autor nicht einfacher gestaltet über den Browser die Inhalte einzupflegen.
Das grösste Manquo aber weist die Document Conversion in der Kontrollierbarkeit aus. Ich habe keinen Mechanismus gefunden, wie Formatierungsrichtlinien (CD/CI-Vorgaben) eingehalten werden können. Über das Word könnten so beliebige Formatierungen auf die Seite geladen werden.

Dieser zweite Artikel im Bereich WCM zeigt die einzelnen Bausteine der Publishing Sites auf und beschreibt ihre Zusammenhänge.

Die oben aufgeführte Abbildung zeigt die Verknüpfungen und Abhängigkeiten der einzelnen Elemente beim Anlegen einer neuen Publishing Site.

Generell besteht eine SharePoint Site aus einem Site Template das über eine Site Definition erstellt wird. Eine solche Site Definition fügt sich aus zwei grundlegenden Elementen zusammen, der Masterpage, die für den Rahmen (Chrome), wie Logo, Navigation, und generelles Look & Feel der Seite zuständig ist und dem Page Layout, welches für den eigentlichen Content enthält.

Das Besondere an Publishing Sites, im Gegensatz zu den sonstigen Site Typen von SharePoint 2007, ist nun, dass die verwendeten Page Layouts nicht nur die üblichen WebParts enthalten können, sondern vielmehr kommen hier die so genannten Field Controls zum Einsatz, welche die Content Management Funktionalitäten realisieren.

Ein Field Control ist ein Art Platzhalter, der den editierbaren Content der Publishing Site darstellt. Solch ein Field Control hat daher zwei Aufgaben, zum einen den Content für die Besucher darstellen und zum anderen dient es für die Autoren im editierbaren Modus als Instrument für die Pflege des Contents. Ein Field Control ist letztendlich die Verwendung eines bestehenden, oder angelegten Field Types, auch Site Column genannt.

Das Site Column legt den Typ des in ihm gespeicherten Contents fest. Single Line of Text, oder Date and Time wäre zum Beispiel ein bereits bestehendes Site Column. SharePoint 2007 ermöglicht jedoch auch die Programmierung von eigenen Site Columns für spezielle Content-Typen wie die Einbettung von Filmen, oder die Darstellung von GPS-Koordinaten. Der Gedanke hinter den Site Columns ist die Umsetzung einer zentralen Pflege der Content-Typen, denn durch sie ist es möglich Site Columns zentral auf der Root-Ebene der Site Collection initial zu definieren. Bei späteren Anpassungen wird dann lediglich die zentrale Definition verändert, welche sich dann optional auf alle verwendeten Instanzen dieser Site Column auswirkt. Der darunter liegende Screenshot zeigt einen Ausschnitt aus der Site Column Gallery.

Das letzte übrig gebliebene Element ist der Content Type. Dieser stellt im Grunde genommen ein Container dar, in welchem die benötigten Site Columns enthalten sind. Beim Erstellen eines Page Layouts (Screenshot aus SharePoint Designer) wird schliesslich ein Content Type ausgewählt aus welchem dann der Pool aus Field Controls zur Verfügung steht mit denen das Page Layout bestückt werden kann.

Bemerkung zum Anlegen von Publishing Sites und Pages

Das Anlegen einer Site ist vergleichbar mit dem Erstellen eines Ordners. Er enthält zahlreiche Einstellungen und Konfigurationen für die darunter liegenden Ordner, oder enthaltenen Pages. Wird eine neue Seite angelegt, so wird automatisch eine Default Page kreiert, die somit die Startseite der Site darstellt. Wird eine neue Page auf Basis eine Publishing Site angelegt, so kann der User aus den definierten Publishing Page Layouts sein gewünschtes Template auswählen. Wird jedoch eine Publishing Site erstellt, so wird direkt der Default Content Type wie auch das Default Page Layout verwendet, so dass ein User mit entsprechenden Rechten über „Manage Content and Structure“ hergehen muss und sein gewünschtes Page Layout bei Bedarf nachträglich für die Default Page der Site anpassen muss. Es ist zwar möglich über die Definition der ONET.XML die Default Werte für den Content Type und das Page Layout der Site Definition zu modifizieren. Will man jedoch nicht für jedes mögliche Page Layout eine eigene Site Definition anlegen, so bleibt der zusätzliche Schritt der nachträglichen Anpassung des Page Layouts auf der Start-Site unablässlich.

Weitere Informationen

http://msdn2.microsoft.com/en-us/library/aa830818.aspx


http://msdn2.microsoft.com/en-us/library/aa830815.aspx


http://msdn2.microsoft.com/en-us/library/ms406043.aspx

Der folgende Artikel dient als Überblick zum Thema Web Content Managements (WCM) unter MOSS 2007. Weitere Artikel in dieser Serie rund um WCM werden in den kommenden Wochen die Möglichkeiten von WCM detaillierter aufzeigen und vervollständigen.

WCM ist Teil einer grösseren Enterprise Content Management (ECM) Strategie, die durch den Microsoft Office SharePoint Sever (MOSS) 2007 umgesetzt wird und auf der Grundlage der SharePoint Services (WSS) v3 aufbaut.

Bye MCMS - Hello WCM !

Vorab die etwas weniger gute Nachricht für alle von uns, die noch mit dem MCMS gross geworden sind – das Content Management Produkt in dieser Form gibt es in der neuen Version nicht mehr, dafür erhalten wir aber durch die Integration des CMS in MOSS 2007 auf der anderen Seite viele erfreuliche Neuerungen. Abgesehen von den Vorteilen der Verschmelzung von CMS und SharePoint, wie einheitlicher Auftritt beider Systeme, oder einer zentralen Umgebung für Administration und Entwicklung, profitiert WCM von den OOB-Features, die MOSS 2007 bereits mit sich bringt. Einige der Wichtigsten wären:

- Integrierte Suche
- Verwendung von WebParts, Document Libraries, Listen, RSS-Feeds, oder Business Data Catalog
- Versionierung mit Minor- und Majorabstufung
- Nutzung der Workflow Engine
- Item Security und Restore
- Security Trimming
- Link Fix-up

Aufbau einer WCM-Site

Nach dem Aktivieren des Publishing Features kann eine WCM-Site durch das Anlegen eines Publishing Site Templates aufgebaut werden. Prinzipiell verwendet diese Site, wie jeder andere Site-Typ in SharePoint, eine Masterpage, die mit Hilfe von CSS den „Chrome“ der Seite definiert und verantwortlich für das Rendering der folgenden Elemente ist:

- Top- und Left-Navigation
- Logos
- Search Fields
- Page editing Controls
- Logon Controls
- eventuelle Custom Controls

Auch die PageLayout.aspx wird wiederum verwendet um den Content-Bereich zu definieren. In ihr befindet sich eine Referenz auf die ausgewählte Masterpage. Der eigentliche Content wird jetzt jedoch nicht über WebParts eingepflegt, sondern über sogenannte Field Controls, die Inhaltselemente aus einer dafür vorgesehenen Document Library darstellen, die Bestandteil jeder einzelnen WCM-Site darstellt.

Field Controls und Content Types

Die jeweiligen Field Controls erhalten ihre Daten somit über entsprechend definierte Felder in der Document Library welche vorab über einen Content Type angelegt wurden. Der Content Type legt daher fest, welche Elemente grundsätzlich für ein Page Layout zur Verfügung stehen, wie ein Art Baukasten aus dem Bauklötze, hier Field Controls, zum jeweiligen Bau hinzugefügt werden. Es besteht die Möglichkeit Content Types auf verschiedenen Site-Levels anzugelegen und den enstprechenden Sites und Subsites zuzuweisen.

Werden die drei Field Controls (im Bild rot umrandet) in die Page Layout Seite integriert, würde dies in diesem Fall zu folgendem Ergebnis führen.

Ein Field Control besteht aus drei möglichen Zuständen, View Mode zur reinen Darstellung des Inhalts, Edit Mode zum Bearbeiten des Inhalts und Design Time zum Konfigurieren des Field Controls.

Neben den Field Controls und den Verwendung von manuell eingepflegtem Inhalt können natürlich aber auch WebParts integriert werden, um dynamische Daten darzustellen. Den Unterschied und den Einsatzbereich zwischen WebParts und Field Controls soll die untenstehende Tabelle verdeutlichen.

Nach der Inbetriebnahme von WCM stehen drei Standard Field Controls für HTML, Text und Links zur Verfügung. Sollen andere, wie zum Beispiel für die Präsentation von Flash, oder Filmen zum Einsatz kommen, können hierfür mit relativ geringem Aufwand proprietäre Custom Field Controls entwickelt werden.

Vergleich WCM MOSS 2007 und MCMS 2002

Analog zum früheren MCMS 2002 kann folgender Vergleich zum WCM herangezogen werden.

Anpassungs- und Erweiterungsmöglichkeiten

Abgesehen von dem Erstellen von Custom Field Controls können weitere umfangreiche Anpassungs- und Erweiterungsmöglichkeiten im Bereich WCM vorgenommen werden. So hat der Entwickler die Möglichkeit die Page Editing Bar zu erweitern, durch die Verwendung von CSS Dateien innerhalb des HTML Editors die Formatierung der Inhalte zu verändern, oder diesen Rich Text Editor über weitere Buttons zu erweitern um so eigene Funktionen ins System zu integrieren.

Erweiterung der Page Editing Bar:

Formatierung durch definierte CSS-Styles:

Erweiterung des HTML-Editors:

Smart-Client Authoring

Neben dem In-Context Authoring mit welchem das übliche Browser-basierte Editieren von Inhalten gemeint ist bietet WCM noch eine Variante an um Dokumente über das sogenannte Smart-Client Authoring in eine WCM Page zu konvertieren. Hierbei werden out-of-the-box Word.docx, XML und InfoPath Dokumente unterstützt, für alle anderen wäre es notwendig einen Custom Converter zu implementieren.