Neue URL

Die neusten Blogposts findest du nun im isolutions Aktiv Blog auf der neuen isolutions Homepage. Die alten Blogposts sind weiter über http://blogger.sharepoint.ch erreichbar. http://blog.sharepoint.ch zeigt auf die neue Website.

Office und SharePoint 2013 Preview verfügbar

Heute hat Microsoft (bzw. Steve Ballmer himself) die Katze aus dem Sack gelassen und den Preview von Office 2013 und SharePoint 2013 zur Verfügung gestellt. Wir konnten im Rahmen eines Kundenprojekts schon länger am Closed-Beta-Programm teilnehmen, durfen aber nicht darüber sprechen.

Auf den ersten Blick sticht das aufgeräumte User Interface ins Auge. Die Search Site, die MySite oder auch das Project Site Template sehen nicht nur sexy aus sondern bieten auch eine Menge nützliche Funktionen.

Dahinter hat sich auch einiges geändert: Apps halten Einzug in SharePoint und Office (siehe Marketplace). Dabei muss sich der Programmierer immer stärker auf JavaScript, Client Side Object Model und REST beschränken.

In den nächsten Tagen folgen weitere Erfahrungsberichte und Einblicke in SharePoint und Office 2013.

PDF Dateien ab SharePoint nicht herunterladen sondern öffnen

Standardmässig werden PDF Dateien von SharePoint heruntergeladen. Mit Adobe Acrobat X lassen sich die Dateien aber bearbeiten und wieder auf dem SharePoint speichern. Für PDF Dateien stehen die Funktionen “Check Out”, “Check In” und “Edit Document” zur Verfügung.

Hierzu sind aber einige Einstellungen notwendig:

• Bekanntlich muss in der Datei 14/TEMPLATE/XML/DOCICON.XML das PDF Icon registriert werden. Wichtig ist aber das Attribut OpenControl. Damit die PDF Dateien korrekt im Adobe Acrobat X geöffnet werden können, muss diese auf AdobeAcrobat.OpenDocuments gesetzt werden.
  <Mapping Key=”pdf” Value=”pdfIcon.gif” Text=”Adobe Pro” OpenControl=”AdobeAcrobat.OpenDocuments“/>
• Ist die Default Sprache der Site nicht englisch, so muss mindestens das Cumulative Update Feburuary 2012 installiert sein. Dieses Update behebt ein Problem mit fehlenden Spalten auf der Document Library.
• Das Browser File Handling muss auf “Permissive” gesetzt werden
  • Central Administration öffnen
  • Application Management > Manage Web Applications
  • Web Application auswählen und auf “General Settings” klicken
  • Unter “Browser File Handling" die Einstellung von “Strict” (Default) auf “Permissive” ändern
  • OK klicken
• Es kann sein, dass diese Einstellung auf bestehenden Document Libraries nichts bewirkt. Denn neben der globalen Einstellung hat auch jede Document Library eine eigene Einstellung für das Browser File Handling. Craig Lussier hat dazu ein PowerShell Script erstellt, welche diese Einstellung abfragt und neu setzt.

Sharepoint 2010 - Document ID Feature

Das Document ID Service Feature ist im Zusammenhang mit Dokumentenmanagement eine coole Sache. Für den Entwickler bietet es jedoch einige Tücken. Daher nachfolgend ein paar Tipps/Erfahrungen:

Feature aktivieren / Reassign Document IDs

Nach dem Aktivieren des Sitecollection Features „Document ID Service“ erscheint in den Document ID Settings die Meldung „Configuration of the Document ID feature is scheduled to be completed by an automated process.“.

 

Dieselbe Meldung erscheint auch, nachdem der Document ID Prefix geändert wurde. Diese Änderungen werden durch die beiden Jobs „Document ID enable/disable job“ und „Document ID assignment job“ ausgeführt. Die Meldung erscheint solange, bis die beiden Jobs ausgeführt wurden. Diese Jobs werden nur einmal im Tag ausgeführt. Selbstverständlich kann man sie wie gewohnt auch manuell über die CA starten. Dabei muss man jedoch folgendes beachten:

• Bei grossen SiteCollections wird das Aktivieren erst 30 Minuten später ausgeführt. D.h. wird das „Document ID Service” Feature aktiviert und unmittelbar anschliessend die beiden Jobs gestartet, wird man keine Änderung feststellen. Nach dem Aktivieren des Features muss man mind. 30 Minuten warten, bevor man die Jobs manuell startet. Die Grenzen für eine grosse SiteCollection liegen bei 1 web/site, 40 lists/web und 20 doclibs/web. Das bedeutet, bei Publishing Sites wird man dieses Problem immer haben, da sie standardmässig über 3 Webs verfügen.
• Die Reihenfolge wie die Jobs ausgeführt werden spielt eine Rolle. Führt man die Jobs manuell aus, muss immer zuerst der Job „Document ID enable/disable job“ ausgeführt werden.
• Wenn nur der Prefix geändert wird und die Option „Reset all Document IDs…“ gewählt wurde, muss ebenfalls der Job „Document ID enable/disable job“ gestartet werden damit die Änderungen wirksam werden. Wird nur der Job „Document ID assignment job“ ausgeführt, werden die IDs nicht geändert.
• Prefix Änderungen können nur bei eingecheckten Dokumenten gemacht werden. Ausgecheckte Dokumente werden nach dem Reassign immer noch die alte ID haben.
• Die Document IDs sind nur innerhalb der SiteCollection eindeutig. Um SiteCollection übergreifend eindeutige IDs zu haben, müssen die Prefixe entsprechend manuell gepflegt werden.

Probleme mit den DocumentID-Links

Verlinkung auf Dokument-Properties

Es kann vorkommen, dass sich beim Klick auf den DocumentID-Link nicht wie erwartet das Dokument öffnet, sondern dass die Dokument-Properties angezeigt werden. Ich hatte dieses Problem mit Bildern.

Die Dateitypen, welche sich so verhielten, wurden von der Suche nicht indexiert. Nachdem ich diese zu den Crawled File Types hinzugefügt und einen Full Crawl gestartet hatte, funktionierte der DocumentID-Link bei neuen Dateien. Bei bereits vorhandenen Dokumenten funktionieren die Links danach leider immer noch nicht.

Dokument wird heruntergeladen

Bei einigen Dokumenten wurde beim Klick auf die DocumentID, das Dokument in das Temporary Internet Files Verzeichnis heruntergeladen. Dadurch geht die Verbindung zum Sharepoint verloren, d.h. das Dokument kann nicht ausgecheckt werden und müsste nach dem Bearbeiten wieder manuell hochgeladen werden.

Wird die Datei jedoch über den Link, welcher dem Namen hinterlegt ist geöffnet, verhält es sich wie erwartet.

Der folgende Registry-Eintrag führte zur Lösung dieses Problems:

[HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/vnd.ms-powerpoint.presentation.12] "Extension"=".pptx"

Weitere Infos dazu gibt es hier: http://support.microsoft.com/kb/2661910

Document IDs nicht eindeutig

Werden Sites mit Templates erstellt, welche mit der Funktion „Save as Template“ erstellt worden sind, kann es vorkommen, dass in der neuen Site dieselben Document IDs vergeben werden. Dies ist ein bekannter Bug und wurde durch das Februar 2012 CU-Update behoben (http://support.microsoft.com/kb/2661910).

SharePoint 15

SharePoint 15 ist angekündigt: http://flic.kr/p/bw7wEU.
isolutions ist bereits jetzt mit einem Kundenprojekt in der Schweiz live dabei (Technical Adoption Programm).
Weitere Infos gibts hier sobald gestattet.

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.

InfoPath: Form Library oder Liste mit Customized Form?

In folgenden Fällen sollte eine Liste mit customized Form verwendet werden:

• Wenn schnell, einfach und mit kleinem Aufwand gearbeitet werden soll


• Wenn das Formular offline mit SharePoint Workspace zur Verfügung stehen soll


• Wenn die SharePoint-Liste basierend auf Personen oder Gruppen gefiltert werden sollen. (nur ihre eigenen Elemente sehen)


• Wenn die Built-in Display und Edit-Ansichten verwendet werden sollen

In folgenden Fällen muss eine Formularbibliothek verwendet werden:

• bei wiederholenden Daten (Repeating Table, oder Section)


• komplexe Schemen


• Das Formular muss digital signiert sein


• wenn Code verwendet wird im Formular


• Wenn das Formular nicht auf SharePoint verwendet wird


• Wenn das Formular schön ausgedruckt werden soll

InfoPath: Personenfelder Mappen

Personenfelder aus dem InfoPath können tatsächlich nicht direkt auf Personenfelder im SharePoint gemappt werden. Hoffentlich kommt das in einer späteren Version. Im Moment kann es nur durch einen Workflow (oder Eventhandler) gelöst werden. Es muss wie folgt vorgegangen werden:

1. Account-ID des Personenfeldes auf ein Textfeld im SharePoint mappen (DisplayName ist nicht eindeutig).


2. Workflow im Designer erstellen, der beim Erstellen eines Formulars startet.


3. Workflow überprüft ob das Textfeld leer ist.


4. Wenn das Feld nicht leer ist schreibt er die AccountID aus dem Textfeld in ein PeopleFeld aus dem SharePoint. Da die Account-ID eindeutig ist, kann sie in jedem Fall aufgelöst werden und es gibt keinen Fehler. (Wird der Displayname verwendet gibt es hier einen Fehler, sofern es mehrere gleiche Displaynamen gibt).


5. In der Ansicht oder Auswertungen kann das Personenfeld von SharePoint verwendet werden, das Textfeld wird für den Endbenutzer nicht benötigt und muss nicht angezeigt werden.

Hinweis: Das Personenfeld ist natürlich erst ausgefüllt wenn der Workflow gestartet ist. Gleich nach dem Abspeichern ist das Feld also noch ein paar Sekunden leer.

InfoPath: Erster Wert aus SharePoint-Liste als Default in Dropdown-Feld

Problem
Ein Dropdown wird mit Werten aus einer SharePoint-Liste gefüllt. Der erste Wert soll dabei defaultmässig ausgewählt sein.

Lösung
Um den ersten Wert aus einer SharePoint-Liste als Default in einem Dropdownfeld zu setzen muss wie folgt vorgegangen werden:

1. 
   
   Default-Wert des Dropdown bearbeiten


2. 
   
   Formula öffnen und "Edith xPath" Häckchen aktivieren


3. 
   
   folgender Default-Wert eintragen: xdXDocument:GetDOM("Kunden")/dfs:myFields/dfs:dataFields/d:SharePointListItem_RW[1]/d:Title (Kunden durch den Namen der Datenverbindung ersetzen).

InfoPath: Dropdown zeigt nicht alle Werte aus SharePoint-Liste an

Problem
Ein Dropdownfeld soll mit Werten aus einer SharePoint-Liste abgefüllt werden. Die Liste beinhaltet aber so viele Einträge, dass nicht alle im InfoPath im Dropdown angezeigt werden.

Ursache
InfoPath verwendet für diese Abfrage das "Item Limit" der Default-Ansicht und liefert nur so viele Einträge zurück, wie dort eingestellt ist.

Lösung 1:
Das Item Limit in der Default-Ansicht höher einstellen, so dass alle Elemente in der Default-Ansicht ersichtlich sind.

Lösung 2:
Wenn das Item Limit nicht angepasst werden kann/soll, weil die Liste auch für anderes verwendet wird, gibt es eine Möglichkeit, die Daten via WebService ins Infopath zu holen.

1. Öffentliche Ansicht erstellen, die alle Elemente anzeigt.


2. Datenverbindung im InfoPath erstellen:


3. Neue Datenverbindung


4. Receive Data


5. XML Document


6. folgende URL verwenden:
   http://SERVERURL/_vti_bin/owssvr.dll?Cmd=Display&List={5BDB2F37-7239-4B23-B5C3-107E93C41FB0}&XMLDATA=TRUE&noredirect=true&View={D58966DE-F019-4F44-ADE5-F8CF4D4A957A}&SortField=LinkTitle&SortDir=Asc
   Dazu muss natürlich die Basis URL, die List-ID, und die ID der Ansicht angepasst werden. Optional kann am Ende die Sortierung der Daten angegeben werden.


7. Access the data from the specified location


8. Finish


9. Dem Dropdown die Daten aus der sekundären Datenverbindung zuweisen.
   

InfoPath: Personenfeld mit aktuellem Benutzer vergleichen

Manchmal ist es nützlich den aktuellen Benutzer mit einem Benutzer in einem Peoplefeld zu vergleichen. Zum Beispiel wenn nur ein bestimmter Benutzer ein Fomular gehemigen kann.

Die einfachste Variante ist ein Peoplefeld zu erstellen, in dem beim Öffnen des Formulars der aktuelle Benutzer reingeschrieben wird. (Das Feld kann angezeigt werden oder auch nicht).

Somit kann man einfach die beiden AccountID-Felder miteinander vergleichen und für benutzerdefinierte Regeln benutzen.



Problem Gross-Kleinschreibung
Es kann vorkommen, dass Benutzernamen im ersten Feld Grossgeschrieben und im zweiten Feld kleingeschrieben sind und daher beim Vergleich nicht übereinstimmen, obschon es sich um denselben Benutzer handelt.

Dieses Problem kann wie folgt gelöst werden:
Anstatt bei der Kondition in der Regel die beiden Felder direkt zu vergleichen, soll die Regel mit einer Expression erstellt werden. Dort kann die Funktion "translate()" benutzt werden. Damit können alle Grossbuchstaben in Kleinbuchstaben umgewandelt werden.

Die ursprüngliche Expression sieht beispielsweise so aus:

my:Vorgesetzter/pc:Person/pc:AccountId != my:CurrentUser/pc:Person/pc:AccountId

Die Expression, welche Gross- und Kleinschreibung ignoriert sieht dann so aus:


translate(my:Vorgesetzter/pc:Person/pc:AccountId, "ABCDEFGHIJKLMNOPQRSTUVWXYZ", "abcdefghijklmnopqrstuvwxyz") != translate(my:CurrentUser/pc:Person/pc:AccountId, "ABCDEFGHIJKLMNOPQRSTUVWXYZ", "abcdefghijklmnopqrstuvwxyz")