European SharePoint Best Practices Conference – Day 3

3324-IMG_0480-thumb-500x375-3323.jpg

Gestern war bereits der letzte Tag der Konferenz. Die drei Tage waren geprägt von spannenden Tracks, tollen Speakern und auch ein wenig Sightseeing. Wie an den vorhergehenden Tagen habe ich wieder Developer Tracks verfolgt.

It depends …
Im Bezug auf Best Practices war eine der am häufigsten gehörten Aussagen „It depends …“. Oft gibt es nicht nur eine richtige Lösung. Abhängig von den Anforderungen des Kunden kann diese ganz unterschiedlich aussehen. Werden z.B. sehr viele Lese-Zugriffe erwartet, macht es Sinn, die Anzahl der Web Server zu erhöhen. Liegt die Hauptlast bei den Services (z.B. Search), braucht es zusätzliche Application Server und wenn sehr viel schreibend zugegriffen wird, müssen die SQL IOPS erhöht werden. Ähnliche Überlegungen müssen auch bei anderen Architektur- bzw. Design-Entscheidungen berücksichtigt werden.

SharePoint worst practices – Failed SharePoint Deployments
Ein sehr spannender Vortrag wurde von Joel Oleson gehalten. Ein grosses Risiko sieht er darin, dass durch die vielseitige Konfigurierbarkeit von SharePoint auf allen Ebenen die Entwicklungs- und vorallem Test-Umgebungen oft stark von der Produktiven Instanz abweichen. Wird eine Solution neu deployed, kann dies auf der Test-Instanz problemlos funktionieren und beim Einspielen auf die Produktive Umgebung plötzlich Probleme verursachen. Aus diesem Grund sollten die Test-Inhalte, sofern möglich, in regelmässigen Abständen mit den Produktiven Inhalten abgeglichen werden.

Aufgrund der Komplexität von SharePoint wird davon abgeraten, den Betrieb und das Deployment als „One-Man-Band“ zu betreiben. Die Aufgaben sollen auf verschieden Rollen (und natürlich auch Personen) verteilt werden.

Das Fazit am Ende des Tracks war: Man soll keine Angst vor Fehlern haben. Fehler passieren und es gibt garantiert eine Menge Leute, die die gleichen Fehler auch schon gemacht haben. Man soll die Community nutzen und von der Erfahrung der Anderen profitieren.

SharePoint Ribbon Customization Deep Dive
Paul Schaeflein hat an der Konferenz einen guten Einblick in das Customizing der Ribbons gegeben. Da die Entwicklung extrem javascriptlastig ist, ist dies vorallem für unsere Frontend Engineers mit Sicherheit ein sehr spannendes Thema.

3326-IMG_0482-thumb-500x375-3325.jpg

Das Ribbon bietet viele neue Möglichkeiten und kann die Usability für den Benutzer erheblich erhöhen. Falsch eingesetzt kann aber auch das Gegenteil erreicht werden. OOB Controls dürfen nie aus dem Ribbon entfernet werden, da ansonsten die einheitliche Darstellung gegenüber der restlichen SharePoint Umgebung nicht mehr gewährleistet werden kann. Wird das Ribbon erweitert, sollen IMMER eigene Group Templates erstellt werden. Um die Upgradefähigkeit zu gewährleisten, dürfen nicht die OOB Group Templates verwendet werden. Diese können aber kopiert werden.

Fazit
Die SharePoint Best Practices Konferenz in London war sehr spannend und ich konnte eine Menge Inputs mitnehmen. Oft hätte ich mir gewünscht, ich könnte gleichzeitig in mehr als einer Session sitzen. Ich werde mir bestimmt noch den einen oder anderen Track ab CD anschauen und werde wohl auch zum regelmässigen Besucher der Blogs von einigen der Speaker.

European SharePoint Best Practices Conference – Day 2

3298-IMG_0485-thumb-500x375-3297.jpg

Just because you could does not mean you should
Diese Aussage zieht sich als roter Faden durch die ganze Konferenz. Die Speaker weisen immer wieder darauf hin, dass nicht immer bis an die Grenzen von SharePoint gegangen werden soll. Wenn man etwas tut, soll man sich vorher überlegen, was die Konsequenzen daraus sind und welchen Einfluss dies auf die Performance oder auch auf die Upgrade-Fähigkeit der Solution hat.

Auch ich habe mich am zweiten Tag auf die Entwickler-Tracks fokusiert und habe viele Eindrücke sammeln dürfen. Hier eine Auswahl davon:

Debugging and troubleshooting SharePoint 2010 Applications
Einer der Schwerpunkte von Claudio Brotto’s Vortrag lag auf den neuen Logging Möglichkeiten von SharePoint 2010 und wie diese auch für Custom Code genutzt werden können, indem eigene Kategorien erstellt werden. Ausserdem stellte er Tools wie den ULS Log Viewer vor, die eine grosse Hilfe sind, wenn es darum geht, einen spezifischen Eintrag in der Flut von Log-Messages zu finden. Er empfiehlt ausserdem den Einsatz von PowerShell, das ebenfalls viele Möglichkeiten zur Analyse von Log-Files bietet.
Um eine einzelne Seite zu Analysieren, ist das neue Developer Dashboard sehr hilfreich. Im Vortrag wurde vermittelt, man das Dashboard zur Analyse von eigenen Komponenten nutzen kann.

Creating Sites, Site Definitions, Web Templates and custom Code
Ich habe bereits am ersten Konferenz-Tag einen Vortrag von Mirjam Van Olst besucht und war sehr begeistert. Am zweiten Tag sprach sie darüber, wie eigene Site Definitions und Web Templates erstellt werden, wo was eingesetzt werden kann bzw. soll und wo die Vor- und Nachteile liegen.
Web Templates wurden in SharePoint 2010 neu eingeführt. Es wird empfohlen, wenn immer möglich Web Templates einzusetzen, da diese sich im Gegensatz zu Site Definitions jederzeit verändern lassen. Dies hängt damit zusammen, dass die Seite nach dem erstellen immer auf die unterliegende Site Definition verweist. Web Templates können Farm- oder Site-Scoped definiert werden, in Sandboxed Solutions können aus naheliegenden Gründen aber nur Site-Scoped Web Templates verwendet werden. Site Definitions werden dort nicht unterstützt.
Ein weiteres Thema waren Site Provisioning Providers, die nun deprecated sind. Es wurde aufgezeigt, wie diese in SharePoint 2010 ersetzt werden können und was dabei beachtet werden muss.

Fine Tuning SharePoint 2010 Performance and optimization
Der letzte Track des Tages wurde von Eric Shupps and Rob Foster gehalten. Eric Shupps vertrat dabei die Developer, wärend Rob Foster aus Sicht eines IT-Professionals sprach. Entsprechend wurden nicht nur Coding-Issues sondern auch verschiedene Architektur-Entscheidungen angesprochen. Unter anderem wurde die maximale Grösse einer Content Database angesprochen. Supported sind bis zu 200 GB. Hier gilt aber, wie bereits oben erwähnt: nur weil es möglich ist, soll man das nicht unbedingt ausnutzen. Ein sinnvolles Limit sind 100GB – es muss immer bedacht werden, wie lange es im Notfall dauert, die Datenbank wieder herzustellen.
Eine der Kernaussagen für Developer war: es soll so viel als möglich gecached werden.
Gerade bei grossen Listen kann es einen grossen Unterschied machen, wie auf die Items zugegriffen wird. Generell kann gesagt werden, dass Search die schnellste Möglichkeit ist. Dies hat aber den Nachteil, dass nicht ListItems zurück geliefert werden. Ebenfalls schnell ist ein Zugriff via CAML bzw. LINQ. REST ist langsamer, aber immer noch schneller als ein WebService Aufruf.

Nintex Workflows: Eine alternative zu SharePoint Designer und Visual Studio

Workflows werden in Regel verwendet um Business Prozesse abzubilden. SharePoint stellt für Standard-Prozesse einige vordefinierte Workflows zur Verfügung, wie zum Beispiel für Dokumentenfreigabe oder -feedback. Sobald die wirklichen Prozesse allerdings davon abweichen, reicht dies nicht mehr aus. Für solche Fälle stellt Microsoft zwei Tools zur Verfügung:

  • Einfache Workflows, die nur an wenigen Stellen benötigt werden, können mit dem SharePoint Designer ohne Programmierung erstellt werden. Allerdings muss der Workflow auf jeder Liste bzw. Library einzeln erstellt werden (stimmt nicht für den Designer 2010).
  • Für komplexe oder oft verwendete Workflows steht Visual Studio zur Verfügung. Dies bedingt allerdings, dass ein Programmierer zur Verfügung steht. Je nach Anforderung wird das Erstellen von Visual Studio Workflows schnell sehr aufwendig und für Anpassungen müssen neue Deployments gemacht werden, sofern der Workflow nicht konfigurierbar programmiert wird.

Nintex hat ihr Produkt zwischen diesen beiden Ansätzen positioniert. Mit dem Produkt können selbst komplexe Workflows ohne Programmierung erstellt werden. Das Tool ist im Gegensatz zum SharePoint Designer direkt in SharePoint integriert. Es wird keine zusätzliche Software auf dem Client Rechner benötigt.

1936-NintexVSVisualStudio-thumb-500x334-1935.gif

Stärken und Schwächen der verschiedenen Tools

SharePoint Designer Workflows

Stärken:

  • Workflows können durch Benutzer mit entsprechender Berechtigung selbständig erstellt werden
  • Keine zusätzlichen Kosten

Schwächen:

  • SharePoint Designer muss beim Benutzer installiert werden
  • Keine State-Machine-Unterstützung (1)
  • Mangelnde Benutzerfreudlichkeit, komplex in der Bedienung
  • Workflows können nicht exportiert und nicht mehrfach verwendet werden

Nintex Workflows

Stärken:

  • Intuitive Benutzeroberfläche
  • Direkte Integration in SharePoint
  • Activities für viele Anforderungen stehen OOB zur Verfügung
  • State-Machine-Unterstützung
  • Visualisierte Workflow History
  • Reporting
  • Speichern und exportieren von Templates
  • Persönliche Snippets Bibliothek für wiederkehrende Actions-Abfolgen

Schwächen:

  • Bei Mehrfachverwendung muss der Workflow jeweils kopiert werden
  • Lizenzkosten
  • SQL Server Express wird nicht unterstützt

Visulal Studio Workflows

Stärken:

  • Grenzen setzt einzig die Windows Workflow Foundation (WF) von Microsoft.
  • Feature/DLL Deployment
  • Beliebig oft wiederverwendbar
  • Besseres Controlling, da nicht von Benutzern veränderbar

Schwächen:

  • Nur bedingt konfigurierbar durch die SharePoint Administratoren
  • Programmierkenntnisse erforderlich
  • Komplex und aufwendig in der Erstellung

Wann und warum soll welches Produkt eingesetzt werden?

SharePoint Designer Workflows sollten eingesetzt werden, wenn nur wenige, sehr einfache Prozesse abgebildet werden müssen, die nur auf wenigen Listen oder Libraries verwendet werden. Die Erfahrung zeigt, dass Workflows immer komplexer werden als zu Beginn angedacht.

Nintex Workflows 2007 sollte verwendet werden, wenn die Anforderung besteht, dass Workflows von Power Usern erstellt werden können müssen, die Prozesse komplex sind oder State Machine Funktionalität benötigen. Aufgrund der besseren Benutzerführung kann der Einsatz von Nintex auch Sinn machen, wenn viele einfache Prozesse abgebildet werden müssen.

Visual Studio Workflows werden eingesetzt, wenn die Prozesse sehr komplex sind und daher speziell ausprogrammiert werden müssen oder wenn ein Prozess SiteCollection übergreifend an vielen verschiedenen Stellen abgebildet werden muss. Dies kann bereits bei einfachen Prozessen zutreffen.

Nintex Workflows im Detail

Integration in SharePoint
Nintex Workflows sind als Erweiterung von SharePoint konzipiert und komplett integriert. Einstellungen wie Email-Settings, erlaubte Workflow Actions oder Konstanten können global in der Central Administration vorgenommen werden. Viele Einstellungen können in den Site Settings auf SiteCollection und Site Ebene überschrieben werden.

Genau wie SharePoint Designer Workflows, werden auch Nintex Workflows pro Liste bzw. Library erstellt. Allerdings wird kein eigenes Tool benötigt, um Workflows zu erstellen. Workflows können direkt über das Settings Menu der Liste/Library verwaltet werden.

1939-ListSettings-thumb-500x248-1938.gif

Safe Looping
Wenn Workflows durch autorisierte Benutzer erstellt werden können, besteht immer ein gewisses Risiko, dass Endlos-Loops erzeugt werden und diese den Server in die Knie zwingen. Nintex löst dies mit der Option „Enforce safe looping“. Wenn diese Option aktiv ist, wir nach jedem Durchgang eine Pause eingeschaltet. Die Länge der Pause ist abhängig von den Timer Job Einstellungen. In der Regel sind dies fünf Minuten. Dies gilt auch für Status-Wechsel in einem State-Machine Workflow.

Workflow Designer
Das Herzstück des Tools ist natürlich der Workflow Designer. Workflows können wahlweise auf Basis eines vorhandenen Templates oder „from scratch“ erstellt werden. Das Tool enthält bereits Templates für verschiedene Standard-Prozesse, es können aber auch eigene Templates erstellt werden. Die Templates dienen als Grundlage und können den Anforderungen entsprechend angepasst werden.

Die breite Auswahl von Workflow Actions sollte in den meisten Fällen ausreichen, um den gewünschten Prozess abzubilden. Zur Auswahl stehen z.B. Approval, Benachrichtigung, diverse List- und Item-Manipulationen oder Active Directory Provisioning Funktionalitäten. Ausserdem gibt es Actions wie Loop und Switch, die den Verlauf des Workflows beeinflussen können. Falls doch einmal eine Funktionalität fehlt, steht eine SDK zur Verfügung, die es einem Programmierer erlaubt, eigene Workflow Actions zu erstellen.

1942-WorkflowBeispiel-thumb-500x356-1941.gif

Die Bedienung ist denkbar einfach. Actions können per „Drag and Drop“ an die gewünschte Stelle gezogen oder über die rechte Maustaste direkt ausgewählt und eingefügt werden. Die Konfiguration erfolgt jeweils direkt auf der Action.

1945-WorkflowBeispiel2-thumb-500x355-1944.gif

Konfigurationsanpassungen an Workflow Actions können jederzeit gespeichert werden, auch wenn nicht alle benötigten Informationen vorhanden sind. Unvollständig konfigurierte Actions werden optisch durch ein Warn-Symbol gekennzeichnet. „OnMouseOver“ wird ausserdem eine Warnung mit detaillierten Informationen angezeigt.

1948-ActionNichtKonfiguriert-thumb-500x233-1947.gif

Neben der funktionalen Konfiguration können auch die Labels der Actions angepasst werden. Dies erhöht die Lesbarkeit und ist insbesondere bei zukünftigen Anpassungen und einer möglichen Fehlersuche eine grosse Hilfe.

Templates und Snippets
Leider können auch Nintex Workflows nicht wiederverwendet werden. Stattdessen wird der Template Mechanismus angeboten. Ein fertiger Workflow kann als Template abgelegt und anschliessend innerhalb der SiteCollection als Vorlage verwendet werden. Ein grosser Nachteil dieser Methode ist allerdings, dass es sich dabei um Kopien des Workflows und nicht um echte Wiederverwendbarkeit handelt. Allfällige Änderungen müssen für jeden Workflow separat vorgenommen werden.

Snippets werden verwendet um immer wieder benötigte Abfolgen von Actions zu speichern. Die Snippets werden in der Toolbox auf der linken Seite unter „My Snippets“ angezeigt. Sie sind im Gegensatz zu Templates persönlich und für andere Benutzer nicht sichtbar.

Workflow History
Ganz besonders beeindruckt bin ich von der Visualisierung der Workflow History. Dabei wird der Workflow im Designer Modus dargestellt. Die durchlaufenen Schritte und der hängige Task sind farblich hervorgehoben und zusätzlich mit den entsprechenden Workflow Informationen versehen. So ist z.B. sofort ersichtlich, wer einen Task freigegeben hat und auf wessen Input noch gewartet wird.

1951-WorkflowHistory1-thumb-500x351-1950.gif

Reporting
Im Tool enthalten ist auch ein recht ausführliches Reporting. Reports können wahlweise von allen Workflows oder einem bestimmten Workflow angeschaut werden.

1954-ReportCenter-thumb-500x262-1953.gif

Neben den Reports über die Workflows im allgemeinen stehen Statistiken zum Verhalten der Approver zur Verfügung, aus denen unter anderem ersichtlich ist, wie schnell ein Approver im Durchschnitt antwortet und ob dies jeweils innerhalb der Zeitlimite geschehen ist.

Insbesondere die Reports „Errored Workflows“, „Overdue Workflows“ und „Workflows in Progress“ halte ich für einen echten Mehrwert, da so schnell und einfach eine Übersicht gewonnen werden kann und Probleme frühzeitig erkannt werden.

Lazy Approval
Beim Lazy Approval handelt es sich um die Möglichkeit einen Approval Task via Email zu akzeptieren. Die dafür benötigten Keywords lassen sich frei definieren. Lazy Approval macht sicher nicht immer Sinn, kann aber eine durchaus interessante Option sein, wenn die fürs Approval benötigten Informationen per Email versendet werden können. Das Feature lässt sich granular ein- und ausschalten.

Ausblick
Vor einigen Wochen wurde SharePoint 2010 released. Die Benutzerfreundlichkeit der SharePoint Designer Workflows wurde insbesondere durch die Visio Integration klar verbessert. Ausserdem können nun auch SharePoint Designer Workflows exportiert werden. Leider steht auch in der 2010er Version keine State-Machine-Funktionalität zur Verfügung.

Die Veröffentlichung von Nintex Workflows 2010 erfolgt am 12. Juli 2010. Die angekündigten Features hören sich vielversprechend an. Besonders auf die Wiederverwendbarkeit der Workflows innerhalb der SiteCollection bin ich sehr gespannt, da dies eine der grössten noch bestehenden Schwachstellen des Produkts schliessen würde. Mehr Informationen zu Nintex Workflows 2010 finden Sie hier: http://www.nintex.com/en-US/Products/Pages/SPS2010Products.aspx

(1) State-Machine Workflows sind zustandsgesteuert. Der Workflow kann beliebig oft in den gleichen Zustand zurück kommen, bevor der Workflow abgeschlossen wird.

MOSS Benutzer-Statistiken

MOSS bietet Benutzer-Statistiken auf Site Collection und auf Site Ebene. Es sind allerdings kaum Konfigurationsmöglichkeiten vorhanden.

Benutzer-Statistik auf Site Collection Ebene
Die Reports zur Nutzung der Site Collection beziehen sich meist auf die letzten 30 Tage. Teilweise wird zusätzlich eine Grafik mit einer Übersicht über die letzten Monate zur Verfügung gestellt. Exakte Zahlen können in der Regel aber nicht aus der Grafik ausgelesen werden. Die Daten der einzelnen Reports können als Excel oder PDF exportiert werden. Aber auch hier kann kein Einfluss auf die Zeitperiode genommen werden.

950-requests2-thumb-500x314-946.gif

Benutzer-Statistik auf Site Ebene
Um detaillierte Informationen über eine spezifische Site zu erhalten, muss der Site Usage Report auf der entsprechenden Site aufgerufen werden. Es ist nicht möglich von einer zentralen Stelle aus direkt auf die Benutzer-Statistiken der einzelnen Sites zuzugreifen. Leider bietet die Site-Statistik keine Möglichkeit eines Vergleichs über mehrere Monate oder auch nur über den Vormonat, da die Statistik jeweils einen Monat ab dem Vortag berücksichtigt.

952-site_report-thumb-500x351-948.gif

Verständnis der Report Parameter
Die einzelnen Parameter innerhalb der Reports sind zum Teil nicht ganz selbsterklärend. Eine genaue Erklärung für jeden einzelnen Parameter kann hier gefunden werden: MOSS Usage Reports explained.

Fazit
Der MOSS Usage Report deckt die Grundbedürfnisse an eine Benutzer-Statistik ab, bietet darüber hinaus aber wenig. Sobald komplette Reports generiert werden müssen, Vergleiche über längere Zeiträume nötig sind oder detaillierte Informationen benötigt werden, sollte ein Drittprodukt anhand der konkreten Bedürfnisse evaluiert werden.