Liebe Leser,
Dass SharePoint immer auf dem aktuellen Patchlevel gehalten werden sollte (- 1 Monat, damit das Paket von MS notfalls noch zurückgezogen werden kann ;)) ist kein Geheimnis.
Allerdings kann es bei der Installation des August 2013 CU zu einem Fehler während der Installation kommen.
Das Problem:
Die Installation bricht mit der Meldung "Installation of this package failed." ab.
Durchsucht man dann die Logilfes (C:\Users\<Benutzer>\AppData\Local\Temp\opatchinstall.log), findet sich folgender Fehler:
CAQuietExec: Error 0x8007000d: CAQuietExec FailedCustomAction RegisterPerfmonManifest returned actual error code 1603 note this may not be 100% accurate if translation happened inside sandbox)
Das Problem hierbei ist, dass das CU somit teilweise installiert wird.
Der Workaround:
Falls dieser Fehler auftreten sollte, muss man das CU noch 2 weitere Male installieren (beim 2. Mal schlägt es auch fehl, beim 3. Mal klappt es - aus welchen Gründen auch immer) und danach den Configuration Wizard ausführen.
Die Lösung:
Für alle, die das August CU noch nicht installiert haben, hat Microsoft das September CU veröffentlicht, das alle Updates seit Service Pack 1 enthält.
Hier findet sich ein guter Artikel sowie der Downloadlink dazu: https://blogs.technet.microsoft.com/stefan_gossner/2015/09/08/september-2015-cu-for-sharepoint-2013-is-available-for-download/
Viel Erfolg bei der Installation der Updates ;)
Lg,
Chris
Dienstag, 20. Oktober 2015
Montag, 31. August 2015
SharePoint 2016 IT Preview - Erster Erfahrungsbericht
Werte Leser !
Nachdem letzte Woche die IT Preview von SharePoint 2016 veröffentlicht wurde (download hier), habe ich mich am Wochende einmal mit der Installation und Konfiguration der neuen Version beschäftigt.
Meine Erfahrungswerte möchte ich hier mit euch teilen.
Zunächst einmal ein paar Informationen zur Umgebung, die ich hierzu verwendet habe.
- Virtuelle Maschine unter VMWare Workstation
- Basis - Betriebssystem Windows Server 2012 R2
- SQL Server 2014 SP 1 (alle Versionen davor werden von SharePoint 2016 nicht mehr unterstützt)
- Domain Controller Rolle mit der Domäne mydom.local
- WebServer und Application Server Rolle auf Windows Server
- 150 GB Harddisk
- 10 GB Arbeitsspeicher (mehr ist empfohlen, ich wollte allerdings einen Blick auf die Performance
werfen und wissen, wie sich die Umgebung mit so knapp bemessenem Arbeitsspeicher verhält)
Nachdem das Basis-Betriebssystem, die Serverrollen, die Domäne und der SQL Server fertig installiert und konfiguriert waren, habe ich in altbewährter Manier mit der Installation der Prerequisites begonnen.
Nach einem zwischendurch erfolgten Reboot, war die Installation der Prerequisites somit auch schnell abgeschlossen. Was hier auffällt ist die Installation eines Microsoft Information Protection and Control Client in Version 2.1 -> Das könnte ein Indiz für die Data Loss Prevention Technik sein, die in SharePoint 2016 Einzug halten wird.
Jetzt wird genau wie in SharePoint 2013 das Setup ausgeführt und danach der Configuration Wizard ausgeführt.
Dieser sieht auf den 1. Blick auch noch aus wie bei SharePoint 2013, bis man zu nachfolgendem Fenster kommt.
Hier besteht nun die Möglichkeit, eine Serverrolle auszuwählen.
Grundsätzlich unterscheidet Microsoft bei SharePoint nun zwischen folgenden Serverrollen:
- Front-end: Alle Services, Service Applications und Komponenten, die die Benutzeranfragen
verarbeiten werden bei dieser Serverrolle installiert. Diese Serverrolle ist für high Performance
ausgelegt.
- Application: Alle Services, Service Applications und Komponenten für Backend-Requests werden
bei dieser Serverrolle installiert. Hier ist hoher Durchsatz das Ziel.
- Distributed Cache: Ein Server kann als dedizierter Distributed Cache Server eingesetzt werden.
Diese Server können optional auch dazu verwendet werden, mittels SharePoint Request Manager
das Load Balancing einer SharePoint Farm zu übernehmen.
- Search: Alle Services bezüglich der Suche werden bei dieser Serverrolle installiert.
- Custom: Hier kann vom Farm Administrator definiert werden, welche Services auf welchem Server
installiert und konfiguriert werden sollen.
- Single Server: Diese Konfiguration ist für die Umgebung verwendet worden. In dieser
Konfiguration werden alle Services und Komponenten auf einem Server bereitgestellt. ACHTUNG:
Bei dieser Konfiguration ist es NICHT möglich, weitere Server zur Farm hinzuzufügen.
Die restlichen Konfigurationsschritte wie z.B. Angabe des Ports für die Zentraladministration
erfolgen genau so wie in SharePoint 2013. Danach erhält man dann das Abschlussfenster.
Danach öffnet sich wie gewohnt der Internet Explorer, wo man dann die Services von einem Wizard konfigurieren lassen kann. Ich wähle hier immer die Option, die Services selbst zu konfigurieren.
Auf den 1. Blick wirkt die Oberfläche auch sehr stark wie SharePoint 2013 und die Erstellung der Managed Accounts, der Service Applications und ähnliches gestaltet sich auch sehr ähnlich zur Vorgängerversion.
Was bei den Services am Server auffällt ist, dass diese zum einen mit einer neuen Spalte "In Compliance" ausgestattet wurden und zum Anderen nach der Erstellung der Service Application bereits gestartet sind. Dies ist sehr angenehm, da man hier nach der Erstellung der Service Applications nicht noch auf die Services gehen und diese per Hand starten muss.
Ein weiters Detail, das ins Auge springt: Bei dem User Profile Service gibt es KEIN User Profile Synchronization Service mehr. Man findet bei der Konfiguration der Synchronisierung die Auswahlmöglichkeit "User Profile Synchronization" nicht mehr. Man kann lediglich zwischen "AD Import" und "Third Party Identity Manager" wählen - das heißt für mich, dass FIM gestorben ist, was vielen User Profile Service geplagten vermutlich ein Lächeln auf die Lippen zaubert. Die Frage die sich hier stellt ist, wie funktioniert dann das zurückschreiben nach Active Directory ? Dieser Punkt ist noch zu beantworten.
Eine weitere Neuerung ist, dass man die beim Config Wizard angegebene Rolle über die Zentraladministration ändern kann. Wie gut das funktioniert werde ich in Zukunft noch austesten.
Ich habe für einen 1. Testlauf 3 Web Applications und deren Root Site collections angelegt:
- Eine Portalseite (TeamSite Template)
- Ein Enterprise Search Center
- Einen MySite Host
Was auf Anhieb ins Auge sticht ist der schwarze Balken, wo früher ein blauer war. Die Oberfläche sieht sehr stark nach SharePoint Online / Office365 aus, was wiederum für eine engere Integration mit den Cloud Features spricht, damit das Benutzererlebnis möglichst einheitlich ist.
Generell ist der neue alte Look and Feel sehr ähnlich zu SharePoint 2013, aber eben mit einem Hauch mehr Cloud-Feeling. Ein gutes Beispiel dafür ist das Navigationsmenü im linken oberen Bereich, das Office365 Benutzern bereits bestens bekannt sein sollte.
Auch die Dokumentenbibliotheken sollten vom Look and Feel sehr ähnlich der Online-Variante sein.
Das Search Center und der MySite Host sind den Online Varianten auch sehr ähnlich und bringen vom Look and Feel derzeit wenig neues.
Ich werde in den nächsten Wochen und Monaten weiterhin die Details der Neuerungen in SharePoint 2016 in regelmäßigen Abständen hier einstellen und bin für jede Form von Feedback dankbar.
Bis zum nächsten Mal.
Lg,
Chris
Nachdem letzte Woche die IT Preview von SharePoint 2016 veröffentlicht wurde (download hier), habe ich mich am Wochende einmal mit der Installation und Konfiguration der neuen Version beschäftigt.
Meine Erfahrungswerte möchte ich hier mit euch teilen.
Zunächst einmal ein paar Informationen zur Umgebung, die ich hierzu verwendet habe.
- Virtuelle Maschine unter VMWare Workstation
- Basis - Betriebssystem Windows Server 2012 R2
- SQL Server 2014 SP 1 (alle Versionen davor werden von SharePoint 2016 nicht mehr unterstützt)
- Domain Controller Rolle mit der Domäne mydom.local
- WebServer und Application Server Rolle auf Windows Server
- 150 GB Harddisk
- 10 GB Arbeitsspeicher (mehr ist empfohlen, ich wollte allerdings einen Blick auf die Performance
werfen und wissen, wie sich die Umgebung mit so knapp bemessenem Arbeitsspeicher verhält)
Nachdem das Basis-Betriebssystem, die Serverrollen, die Domäne und der SQL Server fertig installiert und konfiguriert waren, habe ich in altbewährter Manier mit der Installation der Prerequisites begonnen.
Nach einem zwischendurch erfolgten Reboot, war die Installation der Prerequisites somit auch schnell abgeschlossen. Was hier auffällt ist die Installation eines Microsoft Information Protection and Control Client in Version 2.1 -> Das könnte ein Indiz für die Data Loss Prevention Technik sein, die in SharePoint 2016 Einzug halten wird.
Jetzt wird genau wie in SharePoint 2013 das Setup ausgeführt und danach der Configuration Wizard ausgeführt.
Dieser sieht auf den 1. Blick auch noch aus wie bei SharePoint 2013, bis man zu nachfolgendem Fenster kommt.
Hier besteht nun die Möglichkeit, eine Serverrolle auszuwählen.
Grundsätzlich unterscheidet Microsoft bei SharePoint nun zwischen folgenden Serverrollen:
- Front-end: Alle Services, Service Applications und Komponenten, die die Benutzeranfragen
verarbeiten werden bei dieser Serverrolle installiert. Diese Serverrolle ist für high Performance
ausgelegt.
- Application: Alle Services, Service Applications und Komponenten für Backend-Requests werden
bei dieser Serverrolle installiert. Hier ist hoher Durchsatz das Ziel.
- Distributed Cache: Ein Server kann als dedizierter Distributed Cache Server eingesetzt werden.
Diese Server können optional auch dazu verwendet werden, mittels SharePoint Request Manager
das Load Balancing einer SharePoint Farm zu übernehmen.
- Search: Alle Services bezüglich der Suche werden bei dieser Serverrolle installiert.
- Custom: Hier kann vom Farm Administrator definiert werden, welche Services auf welchem Server
installiert und konfiguriert werden sollen.
- Single Server: Diese Konfiguration ist für die Umgebung verwendet worden. In dieser
Konfiguration werden alle Services und Komponenten auf einem Server bereitgestellt. ACHTUNG:
Bei dieser Konfiguration ist es NICHT möglich, weitere Server zur Farm hinzuzufügen.
Die restlichen Konfigurationsschritte wie z.B. Angabe des Ports für die Zentraladministration
erfolgen genau so wie in SharePoint 2013. Danach erhält man dann das Abschlussfenster.
Danach öffnet sich wie gewohnt der Internet Explorer, wo man dann die Services von einem Wizard konfigurieren lassen kann. Ich wähle hier immer die Option, die Services selbst zu konfigurieren.
Auf den 1. Blick wirkt die Oberfläche auch sehr stark wie SharePoint 2013 und die Erstellung der Managed Accounts, der Service Applications und ähnliches gestaltet sich auch sehr ähnlich zur Vorgängerversion.
Was bei den Services am Server auffällt ist, dass diese zum einen mit einer neuen Spalte "In Compliance" ausgestattet wurden und zum Anderen nach der Erstellung der Service Application bereits gestartet sind. Dies ist sehr angenehm, da man hier nach der Erstellung der Service Applications nicht noch auf die Services gehen und diese per Hand starten muss.
Ein weiters Detail, das ins Auge springt: Bei dem User Profile Service gibt es KEIN User Profile Synchronization Service mehr. Man findet bei der Konfiguration der Synchronisierung die Auswahlmöglichkeit "User Profile Synchronization" nicht mehr. Man kann lediglich zwischen "AD Import" und "Third Party Identity Manager" wählen - das heißt für mich, dass FIM gestorben ist, was vielen User Profile Service geplagten vermutlich ein Lächeln auf die Lippen zaubert. Die Frage die sich hier stellt ist, wie funktioniert dann das zurückschreiben nach Active Directory ? Dieser Punkt ist noch zu beantworten.
Eine weitere Neuerung ist, dass man die beim Config Wizard angegebene Rolle über die Zentraladministration ändern kann. Wie gut das funktioniert werde ich in Zukunft noch austesten.
Ich habe für einen 1. Testlauf 3 Web Applications und deren Root Site collections angelegt:
- Eine Portalseite (TeamSite Template)
- Ein Enterprise Search Center
- Einen MySite Host
Was auf Anhieb ins Auge sticht ist der schwarze Balken, wo früher ein blauer war. Die Oberfläche sieht sehr stark nach SharePoint Online / Office365 aus, was wiederum für eine engere Integration mit den Cloud Features spricht, damit das Benutzererlebnis möglichst einheitlich ist.
Generell ist der neue alte Look and Feel sehr ähnlich zu SharePoint 2013, aber eben mit einem Hauch mehr Cloud-Feeling. Ein gutes Beispiel dafür ist das Navigationsmenü im linken oberen Bereich, das Office365 Benutzern bereits bestens bekannt sein sollte.
Auch die Dokumentenbibliotheken sollten vom Look and Feel sehr ähnlich der Online-Variante sein.
Das Search Center und der MySite Host sind den Online Varianten auch sehr ähnlich und bringen vom Look and Feel derzeit wenig neues.
Ich werde in den nächsten Wochen und Monaten weiterhin die Details der Neuerungen in SharePoint 2016 in regelmäßigen Abständen hier einstellen und bin für jede Form von Feedback dankbar.
Bis zum nächsten Mal.
Lg,
Chris
Donnerstag, 10. Januar 2013
SharePoint 2010 Secure Token Service funktioniert nach Update nicht mehr
Da ja heute MS Patchday ist werden auch die SharePoint Server upgedated.
Das Problem dabei ist, dass nach dem Update der Secure Token Service nicht mehr aktiviert werden kann. Dies hat zur Folge, dass sämtliche SharePoint Seiten nicht mehr erreichbar sind.
Die Meldung in den ULS Logs bzw. im EventViewer sieht wie folgt aus:
WebHost failed to process a request.
Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/40765957
Exception: System.ServiceModel.ServiceActivationException: The service '/SecurityTokenServiceApplication/securitytoken.svc' cannot be activated due to an exception during compilation. The exception message is: Method not found: 'System.String System.ServiceModel.Activation.Iis7Helper.ExtendedProtectionDotlessSpnNotEnabledThrowHelper(System.Object)'.. ---> System.MissingMethodException: Method not found: 'System.String System.ServiceModel.Activation.Iis7Helper.ExtendedProtectionDotlessSpnNotEnabledThrowHelper(System.Object)'.
Das Problem wird durch den KB2756920 verursacht.
Unter "Programs and Features" -> View installed Updates wird unter Microsoft Windows der KB aufgelistet. Mittels eines Rechtsklicks und Uninstall wird dieser entfernt.
Nach einem Reboot des Servers funktionieren die SharePoint Seiten dann wieder vollkommen normal.
Lg,
Chris
Das Problem dabei ist, dass nach dem Update der Secure Token Service nicht mehr aktiviert werden kann. Dies hat zur Folge, dass sämtliche SharePoint Seiten nicht mehr erreichbar sind.
Die Meldung in den ULS Logs bzw. im EventViewer sieht wie folgt aus:
WebHost failed to process a request.
Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/40765957
Exception: System.ServiceModel.ServiceActivationException: The service '/SecurityTokenServiceApplication/securitytoken.svc' cannot be activated due to an exception during compilation. The exception message is: Method not found: 'System.String System.ServiceModel.Activation.Iis7Helper.ExtendedProtectionDotlessSpnNotEnabledThrowHelper(System.Object)'.. ---> System.MissingMethodException: Method not found: 'System.String System.ServiceModel.Activation.Iis7Helper.ExtendedProtectionDotlessSpnNotEnabledThrowHelper(System.Object)'.
Das Problem wird durch den KB2756920 verursacht.
Unter "Programs and Features" -> View installed Updates wird unter Microsoft Windows der KB aufgelistet. Mittels eines Rechtsklicks und Uninstall wird dieser entfernt.
Nach einem Reboot des Servers funktionieren die SharePoint Seiten dann wieder vollkommen normal.
Lg,
Chris
Donnerstag, 14. Juni 2012
Erhöhung des Session Timeouts einer SharePoint Seite
Im täglichen Einsatz von SharePoint kann es häufig dazu kommen, dass man etwas auf einer SharePoint Site macht und diese danach für eine bestimmte Zeit offen lässt. Ist eine gewisse Zeit verstrichen und man möchte erneut etwas tun kommt es häufig dazu, dass man sich erneut anmelden muss, da die Session abgelaufen ist. Dies kann mitunter als unangenehm empfunden werden.
Die Lösung für dieses Problem findet sich in der Central Administration.
Über Application Management -> Manage Web Applications -> Web Application auswählen
und die General Settings kann man die Security Validation Expiration setzen.
Standardmäßig ist diese auf 30 Minuten gesetzt. Diese kann man hier erhöhen. Die Expiration auf "Never" zu setzen empfiehlt sich aus Sicherheitsgründen nicht.
Der Vorteil ist, dass man auf verschiedenen Web Applications unterschiedliche Durations setzen kann und so je nach Content die Sicherheit regeln kann.
Die Lösung für dieses Problem findet sich in der Central Administration.
Über Application Management -> Manage Web Applications -> Web Application auswählen
und die General Settings kann man die Security Validation Expiration setzen.
Standardmäßig ist diese auf 30 Minuten gesetzt. Diese kann man hier erhöhen. Die Expiration auf "Never" zu setzen empfiehlt sich aus Sicherheitsgründen nicht.
Der Vorteil ist, dass man auf verschiedenen Web Applications unterschiedliche Durations setzen kann und so je nach Content die Sicherheit regeln kann.
Montag, 12. März 2012
Fehler bei Auswahl der General Settings einer WebApplication in der Central Administration
Zeitweise kann es bei der Auswahl der Einstellungen einer WebApplication in der Central Administration zu dubiosem Verhalten von SharePoint kommen:
Wenn man auf die General Settings klickt, bekommt man die Fehlermeldung
"Error
Updates are currently disallowed on GET requests. To allow updates on a GET, set the 'AllowUnsafeUpdates' property on SPWeb."
In der StackTrace werden die "EnsureHttpThrottleSettings" referenziert.
Die Lösung für dieses Problem ist an und für sich recht trivial:
Mittels PowerShell lädt man sich die WebApplication, die das Problem verursacht. Danach ruft man die HttpThrottleSettings auf, was nichts anderes tut, als zu prüfen, ob die Einstellungen vorhanden sind und mittels Update() Kommando wird der Zustand gespeichert.
Das Script sieht folgendermaßen aus:
PS C:\> $webapp = get-SPWebApplication <WebApplicationName>
PS C:\> $webapp.HttpThrottleSettings
PS C:\> $webapp.Update()
Nach der Ausführung des Scripts und erneutem Klick auf die General Settings der WebApplication lassen sich diese problemlos aufrufen.
Wenn man auf die General Settings klickt, bekommt man die Fehlermeldung
"Error
Updates are currently disallowed on GET requests. To allow updates on a GET, set the 'AllowUnsafeUpdates' property on SPWeb."
In der StackTrace werden die "EnsureHttpThrottleSettings" referenziert.
Die Lösung für dieses Problem ist an und für sich recht trivial:
Mittels PowerShell lädt man sich die WebApplication, die das Problem verursacht. Danach ruft man die HttpThrottleSettings auf, was nichts anderes tut, als zu prüfen, ob die Einstellungen vorhanden sind und mittels Update() Kommando wird der Zustand gespeichert.
Das Script sieht folgendermaßen aus:
PS C:\> $webapp = get-SPWebApplication <WebApplicationName>
PS C:\> $webapp.HttpThrottleSettings
PS C:\> $webapp.Update()
Nach der Ausführung des Scripts und erneutem Klick auf die General Settings der WebApplication lassen sich diese problemlos aufrufen.
Montag, 27. Februar 2012
Neue Informationen und Zertifizierung zu Office365
65Da Cloud immer mehr ein Thema wird, gibt es heute einige Informationen zu den Neuigkeiten im Office 365 Bereich:
Um einen Ersten Überblick über das Office 365 for IT-Professionals Training zu bekommen, empfiehlt sich der Office 365 Jump Start.
Dieser Link umfasst Informationen darüber, welche Angebotspakete es bei Office365 gibt und auch ein paar Basics über Installation und Deployment werden erläutert.
Falls man sein Office365 Deployment um einige Funktionen erweitern möchte, empfiehlt sich das Office365 Developer Training Pack. Hierzu wird eine virtuelle Maschine benötigt, die den "on-premise" Server darstellt.
Hierfür empfiehlt sich die SharePoint 2010 Information Worker Virtual Machine.
Microsoft hat einen Deployment Guide for Office 365 veröffentlicht, der die Schritte erläutert, die bei einem Office365 Deployment durchzuführen sind.
Gemeinsam mit diesem Guide kann man das Office365 Deployment Readiness Assessment Tool benützen, welches eine Analyse des On-Premise Environments lierfert, um ein Deployment vorzubereiten.
Auch für zertifizierungswillige gibt es Neuigkeiten im Office365 Bereich:
Microsoft will ab 10. April 2012 2 Zertifizierungen im Office365 Bereich anbieten:
Die Erste Zertifizierung nennt sich Exam 70-321: Deploying Office 365. Diese Prüfung testet die Kandidaten hinsichtlich des Deployments von Office 365. Zusätzlich beinhaltet sind in dieser Prüfung auch Fragen bezüglich Microsoft Lync Online, Microsoft Exchange Online und Microsoft SharePoint Online.
Die Zweite Zertifizierung nennt sich Exam 70-323: Administering Office 365. Diese Prüfung testet die Kandidaten hinsichtlich der Administration von Office365 und beinhaltet ausserdem Supporting hybrid environments, Provisioning, Managing Users, Managing Service Features, Recovery, Troubleshooting User and Enterprise Connectivity Issues und Managing Licenses.
Ich denke, dass diese beiden Zertifizierungen für Office365 Fans durchaus interessant sind.
Wenn es Neuerungen in diesem Bereich gibt, werde ich sie selbstverständlich hier posten.
Um einen Ersten Überblick über das Office 365 for IT-Professionals Training zu bekommen, empfiehlt sich der Office 365 Jump Start.
Dieser Link umfasst Informationen darüber, welche Angebotspakete es bei Office365 gibt und auch ein paar Basics über Installation und Deployment werden erläutert.
Falls man sein Office365 Deployment um einige Funktionen erweitern möchte, empfiehlt sich das Office365 Developer Training Pack. Hierzu wird eine virtuelle Maschine benötigt, die den "on-premise" Server darstellt.
Hierfür empfiehlt sich die SharePoint 2010 Information Worker Virtual Machine.
Microsoft hat einen Deployment Guide for Office 365 veröffentlicht, der die Schritte erläutert, die bei einem Office365 Deployment durchzuführen sind.
Gemeinsam mit diesem Guide kann man das Office365 Deployment Readiness Assessment Tool benützen, welches eine Analyse des On-Premise Environments lierfert, um ein Deployment vorzubereiten.
Auch für zertifizierungswillige gibt es Neuigkeiten im Office365 Bereich:
Microsoft will ab 10. April 2012 2 Zertifizierungen im Office365 Bereich anbieten:
Die Erste Zertifizierung nennt sich Exam 70-321: Deploying Office 365. Diese Prüfung testet die Kandidaten hinsichtlich des Deployments von Office 365. Zusätzlich beinhaltet sind in dieser Prüfung auch Fragen bezüglich Microsoft Lync Online, Microsoft Exchange Online und Microsoft SharePoint Online.
Die Zweite Zertifizierung nennt sich Exam 70-323: Administering Office 365. Diese Prüfung testet die Kandidaten hinsichtlich der Administration von Office365 und beinhaltet ausserdem Supporting hybrid environments, Provisioning, Managing Users, Managing Service Features, Recovery, Troubleshooting User and Enterprise Connectivity Issues und Managing Licenses.
Ich denke, dass diese beiden Zertifizierungen für Office365 Fans durchaus interessant sind.
Wenn es Neuerungen in diesem Bereich gibt, werde ich sie selbstverständlich hier posten.
Dienstag, 17. Januar 2012
SharePoint 2010 + InfoPath 2010 + Excel Services + REST API
Bei der Realisierung eines Urlaubsantragssystems auf Basis von SharePoint 2010 kann es mitunter zu einigen Problemen kommen.
Einige Fragen, die vor der Realisierung beantwortet werden müssen sind folgende:
- Wo wird der Stand der Urlaubstage verwaltet
- Wie wird die Berechnung der verbrauchten Urlaubstage durchgeführt
- Wie sieht der Prozess für den Urlaubsantrag aus
- Tragen die Mitarbeiter die genommenen Urlaubstage händisch ein, oder soll dies automatisch
berechnet werden ?
All diese Fragen führten dazu, dass für das Formulardesign InfoPath 2010 verwendet wurde, um eine schöne Oberfläche für das Urlaubsantrags-Formular zu bekommen.
Das Formular hatte einige Steuerelemente wie z.B. People picker, Textboxen und Datumsfelder für das Datum des 1. und des letzten Urlaubstages.
Und genau bei diesem Punkt fängt das Problem der Urlaubstagsberechnung an.
InfoPath kann zwar die Differenz von 2 Datumswerten berechnen, was allerdings fehlt ist die Berechnung unter Berücksichtigung der Wochenenden und Feiertage.
Hier kommen die Excel Services ins Spiel. Excel besitzt nämlich die Funktion NETWORKDAYS, die die Arbeitstage zwischen zwei Datumswerten berechnet.
Wie bekommt man nun die Datumswerte des InfoPath Formulars in den Excel Sheet, der dann dort die Berechnung der Arbeitstage ausführt und diese dann an das Formular retourniert ?
Die Antwort lautet REST API. Die REST API macht genau das möglich. Im weiteren Verlauf dieses Posts werde ich auf die Umsetzung dieser Funktionalität unter Zuhilfenahme der verschiedenen Technologien im Detail eingehen.
Also beginnen wir zunächst mit dem Excel Sheet.
Hierfür erstellen wir einen neuen Excel Sheet und verwenden die ersten 2 Zellen in der Spalte A für unsere Inputs.
Ich habe die Felder in diesem Fall "StartDate" und "EndDate" genannt.
In der 1. Zelle in Spalte B soll dann unser berechneter Wert stehen.
Dazu fügen wir die Formel "=NETWORKDAYS(StartDate; EndDate) in diese Spalte.
Ein Test zeigt, dass die Formel funktioniert:
Ein wichtiger Faktor ist das Datumsformat. In meinem Fall war das Datumsformat English (UK).
Wichtig ist, dass dieses Format auf jeden Fall korrekt übergeben wird, sonst wird ein falscher Wert vom REST Service zurückgeliefert.
Um zu testen, ob REST funktioniert, wird dann folgende Url im Internet Explorer eingegeben:
http://<server>/<site>/_vti_bin/ExcelRest.aspx/<library>/<ExcelSheet>.xlsx/Model/Ranges('DateDiff')?Ranges('StartDate')=2012-01-13&Ranges('EndDate')=2012-01-17
DateDiff ist in unserem Fall die Zelle, die die Formel für die Berechnung enthält.
Haben wir alles richtig, gemacht, erscheint folgende Ausgabe im Internet Explorer:
Da das Format des Rückgabewertes zum jetzigen Zeitpunkt noch HTML ist und wir in InfoPath XML benötigen, fügen wir noch den Ausdruck $format=atom zu unserer Url hinzu, sodaß die Url dann folgendermaßen aussieht:
http://<server>/<site>/_vti_bin/ExcelRest.aspx/<library>/<ExcelSheet>.xlsx/Model/Ranges('DateDiff')?$format=atom&Ranges('StartDate')=2012-01-13&Ranges('EndDate')=2012-01-17
Da wie bereits erwähnt das Datumsformat sehr wichtig ist, stellen wir im InfoPath Formular gleich das richtige Datumsformat in dem Date Picker ein. Dies geschieht über die Properties des DatePickers und war in meinem Fall English (UK).
Nachdem das Design des InfoPath Formulars abgeschlossen ist, binden wir nun das REST Service in unser Formular mit ein.
Dazu fügen wir zuerst das REST Service als Datenquelle hinzu.
In das Url Feld fügen wir unsere Url von vorher (inklusive dem $format=atom Parameter) ein und bei "Automatic retreive" entfernen wir den Haken in der Checkbox.
Jetzt müssen die Datumswerte noch von den Feldwerten ersetzt werden.
Hierzu fügen wir für jedes Datumsfeld eine Regel hinzu.
Zunächst für das Startdatum:
Als Action ändern wir die REST Url:
Die Funktion substring-before(<feldname>, "T00:00:00") muss durchgeführt werden, da InfoPath diesen Zeitwert an den Datumswert anhängt und wir kein vernünftiges Ergebnis bekommen, wenn wir diesen Zeitstempel nicht entfernen.
Diese Rule wird auch für das EndDatum angelegt und die REST Url geändert:
Im nächsten Schritt wird für das EndDatum Feld noch eine Regel erstellt, die die neu erstellte REST Url an das REST Service sendet:
Als nächster Schritt wird das Ergebnis der Query - also die Anzahl der Urlaubstage - in einem Feld gespeichert:
Als Wert wird aus der Secondary Data Source das REST Service ausgewählt:
Damit ist die Funktionalität für die Berechnung der Urlaubstage implementiert.
Zusätzlich verwalte ich den aktuellen Urlaubsstand der Mitarbeiter noch in einer Liste und wenn der Urlaubsantrag approved wird, wird der Stand der Urlaubstage entsprechend korrigiert.
Einige Fragen, die vor der Realisierung beantwortet werden müssen sind folgende:
- Wo wird der Stand der Urlaubstage verwaltet
- Wie wird die Berechnung der verbrauchten Urlaubstage durchgeführt
- Wie sieht der Prozess für den Urlaubsantrag aus
- Tragen die Mitarbeiter die genommenen Urlaubstage händisch ein, oder soll dies automatisch
berechnet werden ?
All diese Fragen führten dazu, dass für das Formulardesign InfoPath 2010 verwendet wurde, um eine schöne Oberfläche für das Urlaubsantrags-Formular zu bekommen.
Das Formular hatte einige Steuerelemente wie z.B. People picker, Textboxen und Datumsfelder für das Datum des 1. und des letzten Urlaubstages.
Und genau bei diesem Punkt fängt das Problem der Urlaubstagsberechnung an.
InfoPath kann zwar die Differenz von 2 Datumswerten berechnen, was allerdings fehlt ist die Berechnung unter Berücksichtigung der Wochenenden und Feiertage.
Hier kommen die Excel Services ins Spiel. Excel besitzt nämlich die Funktion NETWORKDAYS, die die Arbeitstage zwischen zwei Datumswerten berechnet.
Wie bekommt man nun die Datumswerte des InfoPath Formulars in den Excel Sheet, der dann dort die Berechnung der Arbeitstage ausführt und diese dann an das Formular retourniert ?
Die Antwort lautet REST API. Die REST API macht genau das möglich. Im weiteren Verlauf dieses Posts werde ich auf die Umsetzung dieser Funktionalität unter Zuhilfenahme der verschiedenen Technologien im Detail eingehen.
Also beginnen wir zunächst mit dem Excel Sheet.
Hierfür erstellen wir einen neuen Excel Sheet und verwenden die ersten 2 Zellen in der Spalte A für unsere Inputs.
Ich habe die Felder in diesem Fall "StartDate" und "EndDate" genannt.
In der 1. Zelle in Spalte B soll dann unser berechneter Wert stehen.
Dazu fügen wir die Formel "=NETWORKDAYS(StartDate; EndDate) in diese Spalte.
Ein Test zeigt, dass die Formel funktioniert:
Jetzt kann der Excel Sheet in eine SharePoint Library via "Save & Send" gepublished werden. Wichtig hierbei ist, dass die beiden Felder StartDate und EndDate bei den Parametern angehakt werden, um diese Felder über die REST url dann verfügbar machen zu können.
Ein wichtiger Faktor ist das Datumsformat. In meinem Fall war das Datumsformat English (UK).
Wichtig ist, dass dieses Format auf jeden Fall korrekt übergeben wird, sonst wird ein falscher Wert vom REST Service zurückgeliefert.
Um zu testen, ob REST funktioniert, wird dann folgende Url im Internet Explorer eingegeben:
http://<server>/<site>/_vti_bin/ExcelRest.aspx/<library>/<ExcelSheet>.xlsx/Model/Ranges('DateDiff')?Ranges('StartDate')=2012-01-13&Ranges('EndDate')=2012-01-17
DateDiff ist in unserem Fall die Zelle, die die Formel für die Berechnung enthält.
Haben wir alles richtig, gemacht, erscheint folgende Ausgabe im Internet Explorer:
Da das Format des Rückgabewertes zum jetzigen Zeitpunkt noch HTML ist und wir in InfoPath XML benötigen, fügen wir noch den Ausdruck $format=atom zu unserer Url hinzu, sodaß die Url dann folgendermaßen aussieht:
http://<server>/<site>/_vti_bin/ExcelRest.aspx/<library>/<ExcelSheet>.xlsx/Model/Ranges('DateDiff')?$format=atom&Ranges('StartDate')=2012-01-13&Ranges('EndDate')=2012-01-17
Da wie bereits erwähnt das Datumsformat sehr wichtig ist, stellen wir im InfoPath Formular gleich das richtige Datumsformat in dem Date Picker ein. Dies geschieht über die Properties des DatePickers und war in meinem Fall English (UK).
Nachdem das Design des InfoPath Formulars abgeschlossen ist, binden wir nun das REST Service in unser Formular mit ein.
Dazu fügen wir zuerst das REST Service als Datenquelle hinzu.
In das Url Feld fügen wir unsere Url von vorher (inklusive dem $format=atom Parameter) ein und bei "Automatic retreive" entfernen wir den Haken in der Checkbox.
Jetzt müssen die Datumswerte noch von den Feldwerten ersetzt werden.
Hierzu fügen wir für jedes Datumsfeld eine Regel hinzu.
Zunächst für das Startdatum:
Als Action ändern wir die REST Url:
Die Funktion substring-before(<feldname>, "T00:00:00") muss durchgeführt werden, da InfoPath diesen Zeitwert an den Datumswert anhängt und wir kein vernünftiges Ergebnis bekommen, wenn wir diesen Zeitstempel nicht entfernen.
Diese Rule wird auch für das EndDatum angelegt und die REST Url geändert:
Im nächsten Schritt wird für das EndDatum Feld noch eine Regel erstellt, die die neu erstellte REST Url an das REST Service sendet:
Als nächster Schritt wird das Ergebnis der Query - also die Anzahl der Urlaubstage - in einem Feld gespeichert:
Als Wert wird aus der Secondary Data Source das REST Service ausgewählt:
Damit ist die Funktionalität für die Berechnung der Urlaubstage implementiert.
Zusätzlich verwalte ich den aktuellen Urlaubsstand der Mitarbeiter noch in einer Liste und wenn der Urlaubsantrag approved wird, wird der Stand der Urlaubstage entsprechend korrigiert.
Abonnieren
Posts (Atom)