Namics SharePoint Weblog

Im 4. und letzten Teil meiner Serie über den SharePoint Connector for Confluence geht es nun im die Federated Search.

Folgende Voraussetzungen sind gegeben: Es muss ein SharePoint 2010 Server vorhanden sein (Standard oder Enterprise), da in SharePoint2010 Foundation keine Federated Search unterstützt wird. Auf der Confluence Seite muss das OpenSearch plugin installiert sein und so konfiguriert, dass es sich die Suchresultate mit SharePoint "shared".

Bei der Konfiguration auf der SharePoint Seite ist zu beachten, dass der "Location Type" auf OpenSearch konfiguriert ist. Das wichtigste hier ist auch wieder die Authentifizierung. Idealerweise, ist das ganze ja so oder so als SSO und AD integriert aufgesetzt. Ansonsten ist eine Konfiguration möglich, welche das hinterlegen eines Benutzers für alle Such Abfragen möglich macht, aber auch Forms Authentication, Anonymous und SSS (Secure Store Service) sind möglich. Wie immer ist hier die SSO / Ad Integration empfohlen, so dass auch gleich die Suchresultate aus Confluence Security trimmed sind.

Auch hier kann man von 2 Seiten die Installation vornehmen. Zur einen Seite, dass man von SharePoint aus Confluence Content findet und natürlich umgekehrt.

Confluence Resultate in der SharePoint Suche: Wie bereits erwähnt, wird hier der Weg via Federated Search gegangen. (Open Search). Das heisst, dass nicht der SharePoint Crawler den Confluence Content indexiert, sondern das Query wird bei der Suchabfrage dem Confluence Server übergeben und in der Resultate Seite von SharePoint dargestellt. Die Indexierung und der Index wird wie gewohnt auf dem Confluence Server vorgenommen. Dazu wird auf der Resultate Seite ein Federated Result WebPart platziert, welches dies dann übernimmt.

Die Resultate werden nun innerhalb dieses WebParts dargestellt. Es kann via XSLT das Design und die Darstellung angepasst werden und es kann auch ein Link dargestellt werden, wo mehr Resultate aus diesem Content erscheinen. (Öffnet die Result Page von Confluence).

Das ganze funktioniert auch aus dem Confluence Wiki, natürlich einfach mit umgekehrten Vorzeichen. Hier ist die Installation des Opensearch Plugins notwendig. Zusätzlich kann man das SharePoint Decorator Theme installieren, welche mir dann beim Suchfenster ermöglicht zu selektieren, welchen Content ich durchsuchen möchte. Danach kann ich wählen zwischen "SharePoint & Confluence" und "Confluence only".

Das Prinzip der Abfrage ist nun gleich wie wenn man aus SharePoint sucht, nur das diesmal natürlich auch Confluence das Query an den SharePoint Server gesandt wird und dann die Resultate auf der Confluence Resultat Seite dargestellt werden.

Grundsätzlich eine gute Sache. Das ganze basiert auf Open Search, das heisst, es ist nicht wirklich eine spezifische SharePoint / Confluence Angelegenheit. Ob dies so eingestzt werden soll und kann, hängt natürlich von vielen Faktoren ab. Ich persönlich würde jetzt vermutlich eher dahin tendieren, dass ich eine Search Engine für meine Firma bestimmen würde (In diesem Fall natürlich SharePoint) und würde dann für Confluence einen eigenen Scope einrichten und SharePoint auch gleich den Confluence Content indexieren lassen. Somit müsste man nur einen Index, Search Service etc. warten und pflegen. Aber wie gesagt, dies ist von vielen technischen, politischen Faktoren abhängig, und kann so natürlich nicht allgemein beantwortet werden.

In diesem Post geht es jetzt darum, wie ich mittels dem SharePoint Connector for Confluence nun Confluence Content in SharePoint abbilden kann. (Part II behandelt den SharePoint Content in Confulence).

Nach der erfolgreichen Installation und dem Deployment der Webparts, geht es ans Einrichten des Connectors.(Part I) Danach stehen mir auf SharePoint 3 Webparts zur Verfügung. (Eigentlich sind es nur 2, denn das "Confluence Federated Search Result" Webpart werde ich hier nicht beschreiben. Es wird nur auf Search Result Pages verwendet, und nur, wenn kein SSO eingerichtet ist.)

Bleiben also:

• Confluence Page

• Confluence Pages Tree View

Zuerst nehme ich mir das Confluence Page Webpart vor. Die Platzierung des WebParts funkioniert wie bei jedem anderen Webpart. Bei der Konfiguration kann ich nun durch den Confluence Page Tree Browsen und die Seite, welche ich anzeigen möchte, auswählen. Nun noch die Standard Settings wie Layout, Border etc. und fertig ist die "Integration". Uns so sieht es aus:

Ein Klick innerhalb der Confluence Seite auf einen weiterführenden Link, öffnet dann die den Link direkt in Confluence. Ich hätte hier irgendwie erwartet, das der SharePoint Context bestehen bleibt und einfach das "Page Viewer" WebPart mit dem neuen Content dargestellt wird. Es besteht auch die Möglichkeit, direkt im WebPart Menue "Edit Confluence Page" zu wählen. Dies öffnet dann in einem neuen Browserfenster die entsprechende Confluence Page direkt im Edit Modus. (hier wird SSO vorausgesetzt)

Das 2. Webpart ermöglicht mir, den "Navigations" Baum von Confluence Spaces anzuzeigen. Auch hier führt das Wählen eines Items im Navigationsbaum zu einem Öffnen direkt in Confluence.

Grundsätzlich habe ich die beiden WebParts nicht "speziell" gefunden. Sie eignen sich aber vorzüglich um z.B. auf einem Projekt Space in SharePoint auch das entsprechende Confluence Wiki darzustellen. Die ermöglicht die Vorteile eines Confluence Wikis zu nutzen, obwohl z.B die Dokumenten Ablage, der Kalender etc. des Projektes in SharePoint liegen. Das selbe gilt auch für das Tree Web Part. Insgeheim habe ich mir davon mehr erhofft. Schön wäre es natürlich, dass wenn ich dann im Wiki auf Confluence bin, ich den Context, woher ich gekommen bin, nicht verloren geht. Dies lässt sich natürlich auch einrichten, ist aber eher nicht so flexibel und bei Änderungen von Strukturen oder ähnlichem gilt es die Verknüpfungen in 2 Systemen zu pflegen.

Part IV wird der letzte Teil der Serie sein und kümmert sich um Federated Search aus beiden Systemen.

Wie bereits in Part I angedroht, werde ich nun die einzelnen Möglichkeiten vom SharePoint Connector for Confluence untersuchen. In diesem Post widme ich mich dem Thema SharePoint Inhalte in Confluence darstellen.

Der Confluence SharePoint Connector ermöglicht es, SharePoint Dokument Bibliotheken, Kalender, Links und Diskussionen im Confluence Wiki einzubinden. Als Benutzer erhalte ich folgende Möglichkeiten:

• Anzeige von SharePoint Dokumenten Bibliotheken, Kalendern, Links , und Diskussionen auf Confluence Wiki Seiten.
• Editieren von SharePoint Office Dokumenten direkt aus Confluence und rückspeichern in SharePoint

Das Thema SSO (Single Sign On) werde ich nicht in dieser Blog Serie aufgreifen, das Thema Suche erhält einen eigenen Part (Part IV)

In Confluence stehen nach der Aktivierung der Plug-Ins 2 Makros für die Einbindung des SharePoint Contents zur Verfügung:

• SharePoint List Makro
• SharePoint Link Makro

SharePoint List Makro

Das List Makro kommt immer zum Einsatz, wenn Dokumenten Bibliotheken, Kalendern, Links und Diskussionen eingebunden werden und in Listen Form dargestellt werden sollen. Die Aktivierung des Makros lässt sich via Makro Browser erledigen. Das Resultat ist jedoch "nur" ein Wiki Markup. Ich kann aber auch gleich das Markup verwenden, was geübten Wiki Benutzern wohl wesentlich einfacher von der Hand geht. Beispiel:

{sp-list:LIST NAME|LIST TYPE}

Ich gehen nun nicht auf jeden Listen Typ ein. Es lassen sich im List Type aber auch die einzelnen, anzuzeigenden Spalten definieren. Direkt auf eine Custom View kann man nicht zeigen, jedoch auf Custom Lists.

Unten ein Beispiel, wie dies im Wiki Markup aussieht: (Oberste Zeile ist eine Chart die nicht von SharePoint sondern aus Confluence kommt)

Was hier nun zur Einbindung kommt, ist eine Dokumenten Liste, ein Kalender und eine Task Liste. Für den User sieht dies dann so aus:

Die Dokumente lassen sich nun direkt mit einem Klick öffnen. Ist auf der Dokumenten Bibliothek "Check Out" erforderlich eingestellt, so übernimmt dies das entsprechende Office Programm und ich kann aus dem Office Client wie gewohnt ein- und auschecken.(Getestet mit der Office2010 Version) Beim Klick auf "View/Edit" öffnet sich die entsprechende SharePoint Page. Was ich hier vermisst habe ist der direkte Kontext (Drop Down auf Dokument) wie ich ihn von SharePoint her kenne. (Für Bearbeitung von Dokumenteneigenschaften, Senden an etc.)

Die 2.Liste ist eine Ansicht auf einen Kalender. Der Kalender wird in Listen Form dargestellt und lässt sich leider nicht "Grafisch" darstellen. Für eine Übersicht was die nächsten Termine sind, reicht dies aber allemal aus.

Die 3. Liste ist eine Task Liste. Hier gibt es nichts spezielles zu erwähnen, ausser vielleicht, dass sich beim Klick auf "AssignedTo" das SharePoint Profile des jeweiligen Benutzers öffnet. Eigentlich logisch, es handelt sich ja auch um einen SharePoint Task.

SharePoint Link Makro

Das Link Makro funktioniert von Ansatz her genau gleich wie das List Makro (Einbindung via Markup oder Makro Browser) Wie es der Name jedoch bereits sagt, geht es hier nun um Links. Es sind links auf einzelne Elemente, auf Dokumenten Bibliotheken, Links, Kalender, Tasks, Diskussionen und Custom Lists möglich.

Bei Links auf einzelne Elemente (z.B. ein Word Dokument) wird das Dokument direkt in der entsprechenden Office Applikation geöffnet. Office weiss woher das Dokument stammt, ob es ausgecheckt werden muss (kann) usw. Die Office Integration funktioniert also auch hier. Perfekt funktioniert diese Integration jedoch nur mit dem IE als Standard Browser. Alle anderen Links funktionieren wirklich wie Links, das heisst, dass es hier (z.B) ein Link auf einen Kalender, ein "Click Trough" gibt, sprich die SharePoint Seite öffnet sich mit dem entsprechenden Kalender.

Bei beiden Makros lassen Sich die SharePoint Funktionen wie Versionierung oder das Auslösen eines Workflows nutzen. (Der Content und die "Kontrolle" über die Dokumente und Workflows bleibt jederzeit in SharePoint)

Fazit: Die beiden Makros sind eine schöne Sache, um SharePoint Content in einem Confluence Wiki darzustellen. Vermisst habe ich gewisse Funktionalitäten, welche ich direkt von SharePoint kenne. Auch dass nicht alles im Firefox funktioniert hat, ist ärgerlich. Dies wiederum ist aber nicht auf die Markos oder Confluence zurückzuführen, sondern auf die Unterstützung der Office Integration von SharePoint und Firefox. Was ich auch nicht als optimal erachte ist, dass ich wissen muss, wie das anzuzeigende Element heisst (Und bei grösseren Umgebungen wo es liegt). Alles in allem aber eine tolle Sache, vor allem für Unternehmen die Ihre Dokumente Zentral in SharePoint ablegen und die Flexibilität eines Confluence Wikis nützen und einsetzen. Dabei lassen sich natürlich auch die Features der Web Apps, der Versionierung und des Check-In Check-Out Prozesses nutzen. Wenn mit Office 2010 Versionen gearbeitet wird, wird auch die gemeinsame, zeitgleiche Bearbeitung eines Dokumentes unterstützt. Zu erwähnen gilt natürlich auch, dass bei “korrekter” Anbindung nur dir Elemente dargestellt werden, auf welche ich auch berechtigt bin, diese zu sehen, resp. zu bearbeiten.

Im nächsten Post werde ich dann die Anzeige von Confluence Content auf SharePoint Pages beschreiben.

Confluence und SharePoint sind sehr beliebt und rege im Einsatz. Der Nachteil beim Einsatz beider Systeme im selben Unternehmen ist nun, dass die Daten separiert sind und die Kollaboration nur auf dem einen oder anderen System erfolgt. Beide zu verbinden bringt beide Welten näher zusammen.

Was verspricht der Connector ?

Mit dem Confluence SharePoint Connector ist es möglich, das einfach editierbare Wiki von Confluence mit dem Dokumenten Management und den Workflow Fähigkeiten von SharePoint zu kombinieren.

• Anzeige von SharePoint Dokumenten Bibiliotheken, Kalendern, Links , und Disskussionen auf Confluence Wiki Seiten. Editieren von SharePoint Office Dokumenten direkt aus Confluence und rückspeichern in SharePoint.
• Einbetten von Confluence Pages und  Confluence Page Trees in eine SharePoint Page. "Click through" von SharePoint zu Confluence.
• Single Sign-on zwischen Confluence und SharePoint.
• Gemeinsames Suchen von Confluence and SharePoint Inhalten, einheitlicher Satz an Ergebnissen

Klingt vielversprechend habe ich mir gedacht und somit folgende Test-Installation durchgeführt:

• Confluence 3.3 Evaluation
• SharePointConnector-1.2.0
• SharePoint 2010 Server

Installation

Bevor man sich mit der Installation in Zeug legt,  sollte man sich zuerst allerdings Gedanken machen über die Authentifizierungsmethode. Dies ist der komplexeste Teil bei der SharePoint - Confluence Integration und könnte alleine mehrere Blog Posts füllen. Ich habe der Einfachheit halber keine AD Integration (von Confluence) vorgenommen, sondern nutze einen fixen AD User um von Confluence auf SharePoint Inhalte zugreifen zu können. Um von SharePoint auf Confluence Inhalte zu gelangen, habe ich mich des SSS (Secure Store Service) von SharePoint bedient. Hier  hatte ich auch die grösste Mühe (resp.Zeit investiert) das ganze zum Laufen zu bringen. Schlussendlich lag dies aber nicht an SharePoint, sondern an meinen Kenntnissen von Confluence und der Konfiguration des Remote API (SOAP and XML-RPC).

Folgende Authentifizierungen sind nicht supported:

• Atlassian Crowd
• SiteMinder and other Single Sign-On Management Solutions (Microsoft SSO and Secure Store Service are supported)
• SharePoint Forms-Based Authentication

Anbei noch eine Grafik, welche die unterstützen Features anhand der SharePoint Version zeigen:

Auf Confluence werden 2 Plugins installiert.(confluence-permcheck-rpc-1.2.1 und sharepoint-plugin-1.2.0). Das ganze funktionierte auf Anhieb und reibungslos.

Nun geht’s an den SharePoint. Für die Installation auf SharePoint wird eine Setup_WebParts.exe geliefert, welche die Installation (Deployment von 2 wsp Files) automatisiert. Die Installation geht einfach und schnell von statten.

Grosse Schwierigkeiten hatte ich wie bereits erwähnt bei der Konfiguration des Zugriffs.

Nach längere Untersuchungszeit habe es aber dennoch hingekriegt.(Remote API) Nun geht es zur Untersuchung der eigentlichen Features, welche ich in den nächsten Posts beschreiben werde.

Washington. Microsoft World Partner Conference 2010. Rund 14'000 Teilnehmer aus über 100 Ländern.

Namics ist auch in diesem Jahr wieder der Einladung von Microsoft gefolgt, um die aktuellen Trends, Themen und Entwicklungen aus erster Hand zu erfahren.

Das Microsoft Geschäftsjahr verlief wie das aktuelle sonninge Wetter in Washington - strahlend. Steve Ballmer bedankt sich für die tolle Zusammenarbeit, sieht jedoch Wolken aufziehen, trotz der geplanten Launches für 2010/2011 muss es einen grundlegenden Wandel geben - zur Cloud. Das Thema der diesjährigen WPC ist leicht zu identifizieren - internetbasierte Services „Cloud Computing". Was wird unter Cloud Computing verstanden? Steve Ballmer erläuterte in seiner Keynote wenig konkretes, eher den bestehenden Nachholbedarf für Microsoft mehr auf virtualisierte und skalierbare Umgebungen zu setzen. Unterstützt durch Webservices und den bedarfsorientierten Einsatz aller Microsoft Produkte soll hier ein spürbarer Mehrwert für Kunden und Partner geschaffen werden. Steve Ballmer appeliert aber auch an die Verantwortung gegenüber den Kunden und deren Erwartungen hinsichtlich Sicherheit und „operativer Qualität" der Produkte und Dienstleistungen.Was ist aber das wirklich neue an dieser Story? Azure! Die seit Februar 2010 zur Verfügung stehende Entwicklerplattform basiert auf einer neuen Version des .NET Frameworks und SQL DB und bietet vielfältige Möglichkeiten für individuelles Applikationsdesign, sowie Datensynchronisation mit SharePoint an. Azure soll also der Tornado am Himmel werden und kräftig für „Wolken" sorgen.

Weiteres Thema ist Windows Phone. Auch hier taucht am Horizont Hoffnung für alle Freunde einer iPhone Alternative auf. Microsoft hat und wird viel in Devices, Software, Entwicklungsplattformen für businessorientiertes Mobile Computing investieren. Die Ergebnisse sollen Ende 2010 präsentiert werden.

Organisatorisch wurde noch ein Staffelstab übergeben, bzw. ein Rollentausch vollzogen. Jon Roskill leitet künftig die gesamte Microsoft Worldwide Partner Group und übernimmt diese Rolle von Allison Watson, die ihrerseits die ehemalige Position von Jon Roskill des Corporate Vice President der Business & Marketing Organization für die USA übernimmt.

Persönlicher Higlight war sicherlich der Auftritt des ehemaligen US Präsidenten Bill Clinton, der in seiner Keynote über die Zusammenhänge von gesellschaftlicher Verantwortung, Netzwerken und Technologieeinsatz sprach. Schwerpunkt war der Wirkungskreis der William J. Clinton Foundation für Haiti und die Unterstützung dieser Aktivitäten durch bspw. den Einsatz von Social Media und virtuellen Netzwerken.

Ein neues Feature von SharePoint 2010 gefällt mir sehr gut, weshalb ich es hier kurz beschreiben möchte: die Anpassung von Formularen mit InfoPath 2010. 

Bei der Erstellung von Formularen hatte man mit SharePoint 2007 folgende Möglichkeiten:

• Verwenden einer Standard-Liste mit entsprechender Standard newforms.aspx-Seite (die Formularseite)
• Editieren der oben genannten Seite mit dem SharePoint Designer (dies nur der Vollständigkeit halber...)
• Erstellen eines Formulars in InfoPath 2007 und Integration auf dem SharePoint
• Einbinden einer programmierten aspx-Seite

Nachteil dieser Lösungen: das Standardformular einer SharePoint Liste liess sich nicht verändern (ausser mit dem Designer) und der Aufwand mit InfoPath war vergleichsweise gross.

Mit SharePoint 2010 ändert sich dies, da das Formular für Standard-Listen direkt mit InfoPath 2010 designed werden können.

Damit hat der Benutzer die Möglichkeit, Formulare nach dem Erstellen der SharePoint-Liste nach seinen Bedürfnissen zu gestalten, Regeln zu integrieren und Validierung einzusetzen.

Um dies einzusetzen, gehen Sie wie folgt vor:

1. Legen Sie eine Liste mit den gewünschten Spalten an.

2. Im Reiter "List" wählen Sie "customize Form", um InfoPath 2010 zu öffnen

3. Editieren Sie das Formular nach Ihrem Belieben, fügen Sie Hilfstexte ein oder Ändern die Struktur der Felder.

4. Speichern Sie das Formular, fertig.

Nun haben Sie ein Formular, dass Sie z.B. in Ihrem  Intranet einsetzen können um Bestellungen entgegenzunehmen oder Trainingsangebote zur Buchung anzubieten.

Ein weiterer Vorteil dieses Ansatzes ist, dass Sie über die Listeneinstellungen steuern können, dass Benutzer nur ihre eigenen Elemente sehen. Mit InfoPath Forms Libraries war dies nicht möglich. 

Um die Verarbeitung der gesammelten Daten zu automatiseren, können Sie zusätzlich Workflows anbinden. Welche Möglichkeiten Ihnen hier zur Verfügung stehen, hat meine Kollegin Maya Feurer im vorherigen Post sehr schön beschrieben.

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.

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.

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.

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.

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.

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.

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

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.

Ist SharePoint 2010 das Tool, das in Unternehmen im Bereich Social Media eingesetzt werden sollte? Zu diesem Thema bekam ich heute eine Blogpostempfehlung, die ich gerne teilen möchte.

Rob Koplowitz von Forrester schreibt darin über die Fortschritte, die SharePoint 2010 in diesem Bereich gemacht hat und gibt Unternehmen Entscheidungshilfe, wann SharePoint 2010 das richtige Tool im Bereich Social Media für sie ist.

Sein Fazit kann man wie folgt zusammenfassen: SharePoint 2010 hat sich bei der MySite stark verbessert und bietet unter anderem mit Tagging und Activity Stream endlich Funktionalitäten, die wir von anderen Tools bereits länger kennen. Aber es fehlen zum Beispiel Microblogging-Features, die sich mittlerweise grosser Beliebtheit erfreuen. Die Gründe hierfür sind offensichtlich: aufgrund der langen Produktentwicklungszyklen von MS können die neuesten Features nicht in SharePoint integriert werden. 

Rob’s Empfehlung lautet daher: wer als Unternehmen “on the cutting edge” hinsichtlich Social Media sein möchte, sollte nicht allein auf SharePoint setzen. Hier empfiehlt sich die Integration von Produkten, deren Anbieter sich auf diese Nischen spezialisieren und sich häufig direkt an SharePoint hängen. So gibt es im Bereich Social Networking Anbieter wie Newsgator, Jive oder OpenText, deren Time-to-market kürzer ist ebenjene Funktionalitäten bieten, die SharePoint 2010 nicht oder nur rudimentär integriert.

Seine eigene Klientel teilt Rob Koplowitz in 3 Kategorien: 1. Unternehmen, die SharePoint Lizenzen haben und es einsetzen wie es kommt, da sie keinen grossen Wert auf neueste Technologien legen, 2. Unternehmen, die genau dies wollen und auf reine Social Technology setzen und 3. jene Unternehmen, die SharePoint mit Drittmitteln anreichern.

Ich würde diese Schlussfolgerung nicht nur auf Social Media anwenden. SharePoint deckt viele Bereiche ab und kann, sofern die (Enterprise) Lizenzen mal im Hause sind, querbeet im Bereich Business Intelligence über Enterprise Search bis hin zum Dokumentenmanagement eingesetzt werden. Mit SharePoint 2010 wurden einige Lücken geschlossen, Unternehmen werden jedoch weiterhin den Einsatz von Drittanbieter Produkten evaluieren müssen, um “on the cutting edge” in einem Bereich zu sein. Und hier ist vor allem eine klare Analyse und gutes Erwartungsmanagement Voraussetzung für einen erfolgreichen Einsatz.   

Team Sites von SharePoint 2010 haben eine neue Startseite erhalten: diese ist Wiki basiert und ermöglicht so ein einfaches und individuelles anpassen. Diese Startseite wurde als Feature einer Team Site integriert und lässt sich demzufolge einfach über den Feature-Mechanismus deaktivieren (womit dann der Funktionsumfang einer Team Site identisch einer Team Site der Vorgängerversion übereinstimmt).

Auf den Wiki-Seiten lassen sich neu auch direkt WebParts integrieren. Das lässt einem sehr schnell sehr viel Spielraum und es nicht mehr notwendig sich für alle möglichen Varianten Seitentypen auszudenken, die über die notwendigen WebPart-Zonen verfügen. In den Vorgängerversionen von SharePoint konnten WebParts nur in diesen vorgesehenen Zonen platziert werden. Als Endanwender gewinnt man also mehr Flexiblität und im normalen Kollaborationsgebrauch sind wohl weniger individuelle Entwicklungsarbeiten notwendig, da eben die Einschränkung der Zonen in den Wiki-Seiten entfällt.

Vorsicht vor unsichtbaren WebParts
Im Gebrauch dieser neuen Möglichkeiten ist mir nun aber ein Stolperstein aufgefallen, über den über kurz oder lang sicherlich jeder Anwender einmal fallen wird: unsichtbare WebParts. Es gibt einzelnen WebParts, die keine visuelle Darstellung im normalen Modus haben oder wenn sie nicht konfiguriert sind, keine Informationen anzeigen.

Ein Beispiel hierzu: Filter-WebParts. Es gibt in SharePoint verschiedene Filter-WebParts um bestimmte Inhalte auf einer Seite bequem Filter zu können. Diese Filter-WebParts sind sehr mächtig und ermöglichen eine schnelle und einfache Konfiguration solcher Filterungsmöglichkeiten. Standardmässig sind die Filter-WebParts beim Hinzufügen nicht konfiguriert und gleichzeitig so definiert, dass sie im normalen Modus nichts anzeigen. Nur im Edit-Modus sind sie als WebParts zu erkennen und können somit über die WebPart-Eigenschaften konfiguriert werden.

Das Problem beginnt jetzt aber erst: wenn ich eine Wiki-Seite bearbeite, dann bearbeite ich das Element aus einer Seitenbibliothek und nicht die effektive "Team Seite". Die Filter-WebParts erkennen diesen Edit-Modus nicht und zeigen aus diesem Grund beim Bearbeiten der Wiki-Seite genau dasselbe an, wie wenn ich nichts bearbeite: nämlich nichts. Ich sehe das WebPart, das ich gerade auf die Seite eingefügt habe nicht. Es ist aber existent. Ein Ausschalten des Features "Wiki-Startseite" beweist dies: wenn ich die Seite dann editiere, sehe ich das WebPart und kann es auch konfigurieren.... Da haben wohl einige Microsoft-Entwickler nicht zu Ende gedacht - fragt sich, wie so etwas eine Beta-Phase überstehen konnte.

Ein Trick hilft: nach dem Einfügen des Filter-WebParts edititieren Sie zuerst ein anderes WebPart auf derselben Seite (z.B. das Listen-WebPart, das Sie filtern wollen). Das setzt die gesamte Site in den höher gelagerten Edit-Modus und plötzlich erscheint das Filter-WebPart wie aus dem Nichts. Nun können Sie auch dieses WebPart über den normalen Weg konfigurieren. Wenn Sie das WebPart einmal konfiguriert haben, dann ist dieses ab sofort auch im einfachen Edit-Modus der Wiki-Seite direkt ansprechbar. Ein etwas kurioser Weg, aber er hilft :-)

Hier die Wiki-Seite im Edit-Modus (WebPart Documents wird bearbeitet):

Und hier dann die Wiki-Seite im normalen Modus, nachdem dann endlich das Filter-WebPart konfiguriert werden konnte:

Am 12.5.2010 wird offiziell Office 2010 (14) gelauncht. Dies nehme ich doch gleich zum Anlass, eine der neuen Funktionen oder Applikation, Die Office Web Apps mal unter die Lupe zu nehmen.

Was sind den die Office Web Apps ?
Einfach gesagt: Das Office im Web Browser.
Klingt gut. Ist es das auch ? Brauche ich noch den Office "Fat" Client ? Träume ich als IT-Verantwortlicher jetzt davon, keine Office Paketierung und Verteilung mehr machen zu müssen ? Kostet das überhaupt was ?

Fragen, die ich versuche zu beantworten. Aber erst einmal der Reihe nach.
Wie komme ich den zu den Office Web Apps ? Das hängt ein wenig davon ab, in welchem Umfeld ich mich bewege.
Als Privat- Person werde ich die Office Web Apps auf Windows Live (SkyDrive) und auf Facebook (Facebook Docs) finden.
Als Mitarbeiter werde ich die Office Web Apps dann finden, wenn mein Unternehmen SharePoint 2010 einsetzt und die Web Apps darauf auch zur Verfügung stellt.

Im Falle einer SharePoint Implementation sieht die Architektur ungefähr so aus:

Als Privat-Anwender kann ich mit Microsoft Office Web Apps in Windows Live kostenlos Dokumente erstellen, bearbeiten, speichern und freigeben. Sie können direkt im Browser über die Office-Benutzeroberfläche auf Dokumente zugreifen. Das bedeutet, dass Sie Dokumente virtuell an einer beliebigen Stelle auf Ihrem Computer oder Smartphone speichern und für andere online freigeben und gemeinsam bearbeiten können.
So sieht Powerpoint im "Slide" Modus aus auf Facebook Docs:

Mit Office Web Apps erweitern Sie Ihren Browser (Internet Explorer, Safari, Firefox) um die Funktionen von Microsoft Word, Excel, PowerPoint und OneNote. Wenn Sie Office Web Apps verwenden, können Sie in der vertrauten Umgebung von Microsoft Office arbeiten und neue Dokumente bearbeiten und erstellen.
Office Web Apps gibt es für Word, Excel, PowerPoint und OneNote

Das Look and Feel von Office Web Apps erinnert in der Tat stark an Office 2010, nur dass eben weniger Menü-Reiter am oberen Bildschirmrand von Office Web Apps zur Auswahl stehen und die gesamte Office-Anwendung im Browser läuft. Mehrere User können zeitgleich ein Dokument in Office Web Apps bearbeiten, rechts unten zeigt die Statuszeile die Zahl und - bei Mouse-over - die Namen der bearbeitenden Personen an. Änderungen an einem Dokument werden in Echtzeit wiedergegeben. Die Dokumente lassen offline auf dem PC oder auf dem Server von Microsoft abspeichern.
Office Web Apps auf Basis von SharePoint 2010 kann auch von Smartphones aus genutzt werden. Als Handy-Browser werden laut Microsoft der Internet Explorer Mobile von Windows Mobile 5 bis 6.5 und Apple Safari 4 (iPhone 3G und iPhone 3GS) unterstützt. Außerdem ist Office Web Apps kompatibel zum Blackberry OS ab Version 4 und zu Symbian-Smartphones mit S60-Oberfläche sowie zu Opera Mobile ab Version 8.65.
Word Web App:

Mit Office Web Apps erhalten wir die Freiheit, überall zu arbeiten - egal, wo wir uns aufhalten. Bedingung ist, dass ich eine Internetverbindung habe, danach kann ich einfach auf Dokumente zugreifen, diese bearbeiten und freigeben und online auf Windows Live/SharePoint speichern, sodass Sie jederzeit mit Ihrem PC oder Smartphone darauf zugreifen können. Mit Office 2010 können Sie Ihre Dokumente direkt im Internet speichern und ebenso einfach öffnen.

Mit den Web Apps wird es erleichtert ein Dokument für andere freizugeben und es mit anderen zu bearbeiten, die einen Browser verwenden (Internet Explorer, Safari, Firefox). Das ist auch in Echtzeit mit Excel möglich. Die Versionskontrolle ist ganz einfach. Deshalb können Sie Ihr Dokument ohne Bedenken freigeben und bei Bedarf zu einer früheren Version zurückkehren.

Benötige ich jetzt die Client Version noch ?
Jein. Die Office Web Apps sind online "Geschwister" zu den sehr stark verbreiteten Desktop Applikationen. Die Office Desktop Applikation werden für die Office Web Apps nicht benötigt. Manches Anwendungs Szenario wird wohl beide Varianten beinhalten. Die Office Web Apps für schnelles, einfaches editieren und "sharen", die Desktop Applikation für die volle Funktionalität und "komplexeres" Editieren

Brauche ich nun noch die Software Verteilung ?
Diese Frage lässt sich leider, wie die vorangegangene nicht einfach so beantworten. Ich denke, dass die Paketierung immernoch notwendig ist, jedoch wird es nicht mehr notwendig sein, jeden Arbeitsplatz mit der Vollversion zu bestücken. Ich gehen davon aus, dass in den meisten Anwendungszenarien und den darin benötigten Funktionen die Web Apps vollkommen ausreichen.

Und was kostet mich das ?
Für Privat Anwender sind die Office Web Apps gratis auf Windows Live verfügbar. Hier ist eine Windows Live ID erforderlich. Für die Benutzung von Docs auf Facebook ist ein Facebook Account notwendig
Für Business Kunden ist eine Volume License von Office 2010 notwendig. Darin enthalten sind die Lizenzen für die Office Web Apps.

Fazit:Die Office Web Apps sind eine wirklich tolle Sache. Der Funktionsumfang wird für die meisten Benutzer ausreichend sein. Von Revolution zu sprechen währe jedoch sicher übertrieben, jedoch eine Evolution von SharePoint / Office in die richtige Richtung ist es allemal.