Office 365: Microsoft übernimmt Führung beim Datenschutz

Datenschutz und Rechtsicherheit in der Cloud werden in der Schweiz viel und heiss diskutiert. Ich möchte Ihnen die neusten Entwicklungen bei Microsoft im Bereich Public Cloud Services nicht vorenthalten: http://blogs.technet.com/b/hritter/archive/2011/12/05/office365-microsoft-252-bernimmt-f-252-hrung-beim-datenschutz.aspx

Collaboration Days 2011 - Document Management à la carte

Auch die Slides zur Session über Document Management mit SharePoint 2010 der Collaboration Days 2011 sind nun online verfügbar.

Collaboration Days 2011 - Document Management à la carte

View more presentations from David Schneider

Schweizer Accessibility-Studie 2011

Die neueste Studie hat untersucht wie einfach zugänglich Schweizer Internetseiten des Gemeinwesens sind. Dabei wurden über 100 Schweizer Webseiten des Gemeinwesens (Bund, Kanton, Städte und Bundesnahe Organiationen wie z.B. die SBB) wurden auf die Barrierefreiheit hin überprüft.

Eine einfache Accessibility Checkliste wird ebenfalls zur Verfügung gestellt:

http://www.accessibility-checklist.ch/#de

Benötigen Sie für die Planung Ihrer Ressourcen zu viel Zeit?

Mit EasyPlanner planen Sie Ihre Ressourcen einfach und effizient!

EasyPlanner bedeutet Ressourcen- und Projektplanung auf einfachste Art und Weise. Das webbasierte Werkzeug visualisiert bestehende Belegungen von Personen oder anderen Ressourcen in frei wählbaren Zeiträumen. Ein nahtloser "Zoom" in den gewünschten Zeitraum sorgt dafür, dass Grob- und Feinplanungszenarien ineinander verschmelzen. Natürlich unterstützt EasyPlanner auch bei der Planung der vorhandenen Ressourcen und sorgt über eine starke Integration in Microsoft Outlook für den Abgleich mit Kalenderdaten und bereits existierenden Planungen. Dies führt zu einem neuartigen Planungserlebnis. Einfacher als je zuvor - EasyPlanner.

Alle Informationen zu EasyPlanner finden Sie auf www.easyplanner.ch

Den Produkteflyer finden Sie hier.

Bitte nehmen Sie sich einen Moment Zeit für unsere Video Präsentation und überzeugen Sie sich selbst von unserem neuen Produkt.

Office 365 / Community Moderation

Seit einiger Zeit vertrete ich isolutions als Moderator für SharePoint Online im deutschsprachigen Forum der Office 365 Community. Durch meine schnellen und unkomplizierten Hilfestellungen will ich anderen Firmen einen einfacheren Einstieg in SharePoint Online ermöglichen und den Wissens- und Erfahrungsaustausch in der Community fördern.

Die Community findet Ihr unter: http://community.office365.com

Aktuelle Tendenzen im Bereich Cloud Computing: http://www.ca.com/ch/de/news/Press-Releases/emea/2011/Studie-Cloud-Computing-lasst-den-CIO-ch-de.aspx

Interessieren Sie sich für die Microsoft Cloud Dienste? Planen Sie Ihre SharePoint Umgebung eventuell in der Cloud zu betrieben? Benötigen Sie Hilfe bei der Entscheidungsfindung? Kennen Sie die rechtlichen Aspekte eines Cloud Deployments? Welche Dienste bietet Microsoft in der Cloud?

Gerne beraten wir Sie als kompetenter Partner für SharePoint On Premise UND SharePoint Online!

Aktuell beschäftigen wir uns mit der Migration einer SharePoint Umgebung mit ca. 800 Nutzern von BPOS (Business Productivity Online Suite) nach Office 365. Durch unsere Erfahrungen vereinfachen wir auch Ihren den Weg in die Wolke.

Wir freuen uns auf Ihre Kontaktaufnahme.

Collaboration Days 2011– Damit die Tester schneller ran können…

Heute habe ich in Luzern an den Collaboration Days – der Schweizer SharePoint Konferenz – die Session mit dem Titel “Damit die Tester schneller ran können - Build und Deploy automatisieren” gehalten. Die Slides dazu findest du auf SlideShare: Collaboration Days 2011 – Damit die Tester schneller ran können.

Den Fokus habe ich auf die Paketierung sowie das automatische Deployment mit TFS Build und dem SharePoint/TFS Continuous Integration Starter Pack gelegt.

SharePoint Site Templates

Site Templates gehören praktisch zu jeder SharePoint Lösung. Sobald man zwei Sites mit derselben Struktur erstellt, kommt der Ruf nach Templates Microsoft hat verschiedene Möglichkeiten vorgesehen, mit denen man SharePoint Site Templates erstellen kann. Wie immer im SharePoint Business, hat jede Variante ihr Vor- und Nachteile. Nachfolgend möchte ich euch einen Überblick und ein paar Erfahrungen aus dem Projektgeschäft der isolutions AG mitgeben.

Zuerst definieren wir, was SharePoint Site Templates abdecken sollen.

• Complete: Das SharePoint Template deckt sämtliche Bereiche einer SharePoint Site ab. Neben Listen und Document Libraries werden nach die Views, die Web Parts, die Workflows und die Navigation übernommen.
• Clickable: Power User können Site Templates im Web zusammenklicken.
• Deployable: Site Templates können über verschiedene Site Collections und SharePoint Farms verteilt werden.
• MUI enabled: Die Mehrsprachigkeit von SharePoint funktioniert in den Site Templates.
• Publishing enabled: Die Publishing Features sind aktiviert.
• Updateable: Änderungen können auf bestehende Sites appliziert werden.
• Upgradable: Beim Upgrade auf die nächste SharePoint Version sollen die Templates weiterverwendet werden können.

Save As Template

Die Option “Save As Template” in den Site Actions erlaubt es einem Power User eine bestehende SharePoint Site als Template abzulegen. Dabei wird ein WSP Paket erstellt, welches als Sandbox Solution auf der aktuellen Site Collection deployt wird. Während die Site schnell erstellt ist, sind einige Anforderungen nicht abgedeckt.

Das Site Template enthält nicht alle Konfigurationen der Site. Gewisse Web Part Properties oder die Navigation werden nicht immer übernommen. Die Mehrsprachigkeit geht verloren und auf Publishing Site steht die Option nicht zur Verfügung. Auch gestaltet sich das Deployment auf mehrere Site Collection bzw. verschiedene SharePoint Farmen als schwierig.

Import WSP in VIsual Studio

Das von “Save as Template” generierte Template lässt sich in Visual Studio importieren und kann hier weiterbearbeitet werden. Leider kommen dabei eine Menge SharePoint Items mit, welche gar nicht verwendet werden. So sind z.B. alle Out of the Box Site Columns vorhanden. Weiter fehlt die Mehrsprachigkeit – die Ressourcen werden hardcoded eingefügt – und die Möglichkeit, Site mit Publishing Feature so zu importieren.

Bevor man das WSP weiterbearbeitet, müssen diese nicht genutzen Elemente bereinigt werden. Danach verfügt man aber über ein Paket, welches sich als Farm Solution deployen lässt und somit auf verschiedenen Site Collection und SharePoint Farmen deployt werden kann. Da das Überarbeiten des importierten WSPs viel Zeit in Anspruch nimmt, wird dieser Schritt meist nur einmal ausgeführt.

Site Definition

Mit Visual Studio kann eine eigene Site Definition erstellt werden. Dabei wird die Konfiguration der Site im ONET.XML abgebildet. Dieser Ansatz ist anspruchsvoll und verursacht Probleme beim Upgrade. Mittlerweile rät sogar Microsoft vom Erstellen von Custom Site Definition ab. Lasst uns diesen Rat befolgen.

Customizations als Features

Mit Features kann jede beliebige Einstellung einer Site verändert werden. Der Code wird nach der Erstellung der Site ausgeführt und verändert die Site nach den Vorgaben. Aufgeteilt in mehrere Features und aufgerufen mit verschiedenen Konfigurationen können damit viele Anforderungen abgedeckt werden. Damit die Users auf neu erstellen Sites die Features nicht manuell aktivieren muss, müssen die Features entweder auf bestehende Templates gestapelt werden oder aber die Sites mit einem eigenen Mechanismus erstellt werden.

Jede zusätzliche Einstellung erfordern aber Anpassungen am Code. Der Power User kann seine Änderungswünsche nicht selbst umsetzen. Dafür können – mit entsprechendem Code – bestehende Sites angepasst werden.

Web Templates

Mit SharePoint 2010 kamen auch die Web Templates. Leider ist diese Möglichkeit bis heute in der SharePoint Welt relativ unbekannt. Web Templates werden auch in Visual Studio erstellt und als WSP deployt. Ein Web Template leitet von einer Out of the Box Site Definition (z.B. Team Site) ab und definiert nur die Änderungen. Es bestehen aus einem Elements.xml, welches Name, Beschreibung und Ableitung enthält sowie einem minimalen ONET.XML mit dem “Configuration” Node. Darin wird angegeben, welche Listen und Document Libraries erstellt werden und welche Features geladen werden. Änderungen müssen also auch grösstenteils als Feature implementiert werden, dafür können neue Sites über den normalen “Create Site” Dialog erstellt werden.

Ein neues Web Template wird erstellt, in dem ein neues “Empty SharePoint Element” hinzugefügt wird.

Das Elements.xml enthält die Informationen, von welcher Site Definition abgeleitet wird und wie das neue Template heisst. Wichtig ist, dass das Attribute "Name” denselben Wert trägt wie das SharePoint Element (siehe oben).

Als Beispiel habe ich das ONET.XML der Team Site aus C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\SiteTemplates\sts\xml kopiert und alles bis auf das Configuration mit ID = 0 gelöscht.

Die Web Templates erfüllen auch nicht alle Bedinungen: User können sie nicht selbst ändern und sie sind nicht updatable. Dafür ist die Enterprise readiness gegeben: die Funktionen lassen sich als Features aufteilen, die Mehrsprachigkeit und die Publishing Features werden unterstützt und ein Upgrade auf SharePoint 15 scheint wahrscheinlich.

InfoPath: Mehrsprachigkeit in Formularen

Um mehrsprachige Formulare umzusetzen, gibt es im Wesentlichen drei verschiedene Möglichkeiten. Jede hat Vor- und Nachteile, die es im entsprechenden Anwendungsfall zu berücksichtigen gilt.

1. Mehrere verschiedene Inhaltstypen erstellen
Die erste und für die Erstellung einfachste Variante ist, ein Formular in einer Sprache zu publizieren. Anschliessend werden die Texte übersetzt und das Formular als zweiten Inhaltstyp publiziert (resp. für jede Sprache wird das Formular als neuer Inhaltstyp publiziert).

Vorteile:

• Einfache Erstellung.


• Der Benutzer muss im Formular selbst keine Sprache wählen.

Nachteile:

• Verschiedene Inhaltstypen (je nach dem komplizierter für Auswertungen)


• Kein allgmeiner Link zum Formular möglich (für jede Sprache ein separater Link, kann auch ein Vorteil sein).


• Aufwändig bei Änderungen, jede Änderung muss in jedem Formular gemacht werden. Datenfelder müssen alle jeweils neu erstellt werden.


• Mapping auf SharePoint-Spalten etwas kompliziert.


• Jeder Benutzer muss das Formular in der Sprache sehen, in der es ausgefüllt wurde.


• Aufwändiger für dazugehörige Workflows, da diese auf mehrere Inhaltstypen publiziert werden müssen.

2. Verschiedene Ansichten im Formular
Die Zweite Variante ist wahrscheinlich für die meisten Anwendungsfälle am besten geeignet. Hier wird nur ein Formular erstellt. Innerhalb des Formulars wird für jede Sprache eine separate Ansicht erstellt. Ausserdem wird eine Default-Ansicht erstellt, in der der Benutzer seine gewünschte Sprache auswählen kann (Für jede Sprache ein Button, beim Klick darauf wird die Ansicht gewechselt).

Vorteile

• Weniger Aufwändig bei Änderungen, da die Datenfelder in jeder Ansicht wiederverwendet werden.


• Jeder Benutzer kann das Formular in seiner gewünschten Sprache bearbeiten, egal in welcher Sprache dieses ausgefüllt wurde.


• Einfaches Mapping auf SharePoint-Spalten.


• Es wird nur ein Inhaltstyp benötigt.

Nachteile:

• Änderungen am Formular sind aufwändiger als bei der dritten Variante, da Textanpassungen in jeder Ansicht gemacht werden müssen.


• Der Benutzer muss beim Öffnen eines Formulars immer zuerst eine Sprache auswählen.

Allenfalls können die Button zur Sprachänderung auch auf jeder Ansicht abgebildet werden. Somit könnte das Formular in einer Default-Sprache geöffnet werden und die Benutzer können die Sprache bei Bedarf jederzeit ändern.

3. Sprachfelder in SharePoint-Liste pflegen
Die letzte Variante ist wahrscheinlich die elganteste Variante um Mehrsprachigkeit in Formularen abzubilden. Diese Variante benötigt ebenfalls nur einen Inhaltstyp und kommt sogar auch nur mit einer einzigen Ansicht für alle Sprachen zurecht. Änderungen am Formular sind daher einfach durchzuführen, allerdings ist die Erstellung des Formulars am aufwendigsten.

Die Texte, die im Formular verwendet werden, werden in einer SharePoint-Liste gepflegt. Im Formular gibt es für jede Sprache ein Radio-Button, das ausgewählt werden kann. Die Texte im Formular werden in Form-Felder geschrieben, die aufgrund der Auswahl im Radio-Button aus der SharePoint-Liste ausgelesen werden.

Ein paar Texte können so nicht abgebildet werden (z.B. Personenfelder). Diese müssen für jede Sprache auf dem Formular abgebildet werden (innerhalb von separaten Sections), die dann bei Nicht-Bedarf einfach ausgeblendet werden.

Vorteile:

• Nur ein Formular und eine Ansicht.


• Wartungsfreundlich. Kleinster Aufwand bei Änderungen


• Default-Sprache möglich (z.B. 80% der Benutzer müssen keine Sprachauswahl mehr machen, da sie mit der Default-Sprache arbeiten).


• Einfache Anpassungen an Texten können in der SharePoint-Liste gepflegt werden. => Keine Anpassungen am Formular notwendig.


• Jeder Benutzer kann das Formular in seiner gewünschten Sprache bearbeiten, egal in welcher Sprache dieses ausgefüllt wurde.


• Es wird nur ein Inhaltstyp benötigt.


• Einfaches Mapping auf SharePoint-Spalten.

Nachteile:

• Aufwändig in der Erstellung.

InfoPath: Benutzen von SharePoint Standard-Workflows für InfoPath Forms

Szenario:
Nach dem Speichern und schliessen eines Formulares soll der Approval Prozess gestartet werden, der an den Vorgesetzten des Erstellers geht. Der Vorgesetzte wird im Formular angegeben.

Problem:
Der Vorgesetzte kann nicht im Listenworkflow vorkonfiguriert werden, da dieser in jedem Workflow unterschiedlich ist. Nach dem Speichern des Formulars erscheint auch nicht automatisch das Workflow-Formular, in dem der Benutzer die Workflow-Empfänger konfigurieren kann.

Lösung:
Der Vorgesetzte wird bereits im InfoPath Formular als Peoplepicker-Feld angegeben. Das Feld "AccountID" des Vorgesetzten wird auf den Sharepoint gemappt. Anschliessend wird ein SharePoint-Designer Workflow erstellt der wie folgt aufgebaut ist:

Step 1
Vorgang 'Genehmigung' für 'Current Item' mit 'Current Item:Vorgesetzter' starten.
dann Workflow beenden.

Über den SharePoint-Designer Workflow lässt sich der Standard Approval Workflow starten und mit bereits vorhandenen Daten aus dem Formular konfigurieren.

Der Workflow muss so eingestellt werden, dass er bei einem neuen Element automatisch startet.

Automatische Nummerierung von Formularen

Bei vielen Formularprojekte tritt die Anforderung auf, dass Formulare automatisch durchnummeriert werden sollen. Diese Anforderung kann wie folgt abgedeckt werden:

1. Datenverbindung Einrichten zum Empfangen von Inhalten.
Die Datenverbindung zeigt auf die SharePoint-Bibliothek in welche die Formulare gespeichert werden. Die Daten müssen nicht automatisch beim Öffnen des Formulars abgerufen werden.
Wichtig ist hier, dass die Spalte ID ausgewählt ist.

2. Regeln beim Submitten definieren
Unmittelbar bevor das ausgefüllte Formular gespeichert wird, muss die Datenabfrage gemacht werden. Am besten wird dazu auf dem Speicher-Button eine Regel zum abfragen der Daten hinzugefügt.
Anschliessend wird die Laufnummer in ein dafür vorgesehenes Feld geschrieben.
Die Laufnummer wird wie folgt generiert: max(ID) + 1
Die Spalte ID stammt aus der externen Datenquelle, die in Schritt 1 erstellt wurde. Dadurch wird die höchste ID ausgelesen und eins dazugezählt. Jedes ausgefüllte Formular erhält dadurch eine Laufnummer.

Wichtig

• Das Generieren der Laufnummer muss unmittelbar vor dem Speichern geschehen. Wenn diese zu Beginn generiert wird, können mehrere Formulare dieselbe Laufnummer erhalten wenn mehrere Benutzer gleichzeitig am Formulare ausfüllen sind.
  


• Die Laufnummer darf nur generiert werden, wenn noch keine Laufnummer generiert wurde. Also nur beim erstmaligen Speichern des Formulars. Dies muss in der Regel berücksichtigt werden. Zum Beispiel mit der Condition:
  Laufnummer is blank.