Installieren von SharePoint 2010 auf SQL Server 2012 – So klappt’s

Immer mehr Unternehmen setzen Microsoft SQL Server 2012 ein und fragen sich ob es möglich ist, diesen als Datenbank Server für Microsoft SharePoint 2010 einzusetzen.

Wer das ohne vorher nachzulesen ausprobiert, wird beim Konfigurieren der Farm auf Probleme stossen: Der Farm Configuration Wizard läuft nämlich nicht sauber durch. Er bricht mit einem Fehler ab: Stored Procedure sp_dboption kann nicht gefunden werden.

Was kann man nun tun?

  1. SharePoint 2010 Service Pack 1 installieren
  2. Farm Configuration Wizard erneut ausführen

Sobald der Service Pack für SharePoint installiert ist, läuft der Farm Configuration Wizard fehlerfrei durch.

Gokan Ozcifci hat auf seinem Blog „SharePoint Pirate“ eine sehr detaillierte Anleitung für die Installation von SharePoint 2010 auf SQL Server 2012 in englischer Sprache veröffentlicht. Das von ihm vorgeschlagene Vorgehen ist praktisch, wenn man bereits auf die oben genannten Probleme beim Ausführen des Farm Configuration Wizards gestossen ist.
http://www.gokanozcifci.be/subsite/how-to-install-sql-server-2012-for-sharepoint-2010.html

Ebenfalls brauchbar ist das Vorgehen für die Installation von sehr kleinen Serverfarmen. Für mittlere und grosse SharePoint Farmen halte ich das Vorgehen für weniger geeignet. Mit der steigenden Anzahl Server steigt auch der zusätzliche Zeitaufwand für das separate Installieren von SharePoint 2010 und des Service Packs. In diesem Fall würde ich ein Slipstreaming von SP1 ins SharePoint 2010 Setup vorziehen.

Eine gute Anleitung für das Slipstreaming von SharePoint 2010 SP1 findet ihr auf dem MSDN-Blog: http://blogs.msdn.com/b/ronalg/archive/2011/07/11/slipstream-sharepoint-2010-sp1-and-language-packs-w-sp1-into-rtm.aspx

Sobald der SharePoint Service Pack ins Setup integriert ist, entfällt der Zusatzaufwand zum Installieren des Service Packs und das Vorgehen zum Installieren der Farm ist wieder analog zu SharePoint 2010 auf SQL Server 2008.

SharePoint 2010 Service Pack 1 Ready

Auf Ende Juni wurde es angekündigt und heute Morgen lese ich, es ist wirklich da….
Service Pack 1 steht nun zur Verfügung.

Hier die offizielle Info:
http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=984

Welches sind die wichtigsten Neuerungen?
– Google Chrome wird unterstützt
– Site Recycle bin: Sites & Site Collections landen jetzt auch zuerst im Recycle bin
– Shallow Copy: Migrationsszenarien für Sites mit Remote Blog Storage
– StorMan.aspx ist zurück.

Hier noch ein Whitepaper mit genaueren Infos:
SharePoint 2010 SP1

European SharePoint Best Practices Conference – Day 3

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

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

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

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

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

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

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

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

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

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

Sharepoint 2010 Frontend Prototyping mit Terrific

Der Anpassungsaufwand von Sharepoint-Frontends ist meist ungenau schätzbar aufgrund Anzahl und Komplexität der eingesetzten Elemente (Webparts, Lists, Navigation etc.). Weitere Faktoren sind hohe Ansprüche an Design und Interaktion, hohe Browserkompatibilität und die geringe Zahl an Frontend-Entwicklern mit Sharepointkenntnissen.

Lösungs-Idee
Damit die Styleguideumsetzung sichergestellt und alle weiteren Ansprüche (Usability, Accessibility…etc) erfüllt werden können muss der Prototyp auf einer Sharepoint-Frontend-nahen Umgebung realisiert und getestet werden.
Die Umgebung wird zusammengestellt aus Code-Extrakten aller spezifizierten Sharepoint-Controls, -Webparts etc. In Terrific werden diese Code-Schnipsel dann nur noch in verschiedenen Pagelayouts aufgerufen und gestyled, getestet etc.
So werden bereits am Anfang Probleme klar und gleichzeitig entstehen Stylesheets und Scripts die später (fast) nur noch in die Solution integriert werden müssen.

So kann umgesetzt werden
Vorbereitend muss XAMPP + Terrific installiert und ein neues Projekt aufgesetzt werden. Alle in Sharepoint verwendeten Stylesheets und Scriptdateien werden ins Projekt kopiert.

Sobald fertig spezifiziert ist und der Styleguide erstellt wurde kann begonnen werden. Masterpages, Pagelayouts, Edit-Mode-Elemente, Webparts, Overlays und Custom-Komponenten werden entweder von Sharepoint kopiert oder gemäss Spezifikation erstellt und mit CSS und Script-Funktionalität versehen. Das Ergebnis sollte ein Paket sein, das fast problemlos in die Solution übernommen werden kann. Dank der Terrific-Architektur können MasterPages und PageLayouts ebenso wie in Sharepoint eingesetzt werden.

3286-blog_screenshot-thumb-500x245-3285.gif

Zusammenfassend
Der Einsatz dieser Lösung erfordert die Installation von XAMPP sowie ein paar Terrific-Kenntnisse. Die Zusammenstellung von Master-Page- und Pagelayout-Simulationen sowie der Einsatz von mehr oder weniger komplexen Modulen hängen von der Spezifikation ab. Danach kann der Prototyp aufgebaut, von beliebig vielen Usern erweitert, als Klick-Dummy verteilt werden, für Usability-, Accessibility- und CrossBrowser-Test benutzt werden sowie als Basis für weitere Designänderungen bereit stehen.

Die Idee vom wiederverwendbaren Prototyp ist somit ein Stück weiter realisiert worden und bietet bei Sharepoint-Projekten mit Custom-Frontend u.U. mehr Planungssicherheit in der nicht immer einfach zu schätzenden Frontend-Phase. Die Hürde „Sharepoint-Know für Frontend-Entwickler“ ist nun sehr tief oder fast nicht mehr vorhanden, nun kann jeder Sharepoint-Frontends stylen.

One world-Der Hybris Connector

<< Einführung in die Serie one world

Einleitung
In diesem Artikel soll aufgezeigt werden, wie ein custom Service durch die Vererbung einiger Basisklassen des SAF (Service Application Framework) in die SharePoint 2010 Serviceinfrastruktur integriert werden kann. Wie auch bereits in der Einleitung geschehen, wollen wir uns dabei am Beispeil des Hybris connector Service orientieren. Dieses Mal werden wir aber vermehrt auf die technische Umsetzung des Service eingehen und insbesondere aufzeigen, wie sich der Service mit dem SAF verbindet.

Der Aufbau des Service
Das Design eines custom SAF Service wird grundsätzlich durch die zu vererbenden Basisklassen des Frameworks bestimmt. Diese werden in den folgenden Darstellungen kurz besprochen. Die vererbten Klassen des SAF sind in den Abbildungen jeweils blau interlegt. Gelb hinterlegt sind die Klassen des connector Service.

2961-HybrisService.jpg

Die Klasse HybrisService steht für den Service selber und vererbt von SPIisWebService. Somit beinhaltet er eine Liste aller Service Applikationen und aller Service Application Proxies., die für diesen Service angelegt worden sind. Der Service selber kann sich in der Services-Liste der Farm ein- oder auch wieder austragen. Dazu kennt die Klasse einen Link für den ‚Create Service‘ Dialog. Weiter können durch die Implementierung von IServiceAdministration neue Applikationen und Proxies anlegen.

2976-HybrisServiceInstance.jpg

Die Klasse HybrisServiceInstance steht für eine Instanz des Service, die auf einem bestimmten Server in der Farm läuft.

2979-HybrisServiceProxy.jpg

Die Klasse HybrisServiceProxy etabliert die Verbindung zwischen dem Service und den ServiceApplicationProxies.

2964-HybrisServiceApplication.jpg

Die Klasse HybrisServiceApplication ist die eigentliche Service Applikation. In unserem Beispiel wird die Konfiguration des Service durch diese Klasse gespeichert und gelesen. Dadurch erreichen wir, dass der HybrisConnector-Service mehrfach in einer Farm laufen kann und sich dabei die jeweiligen Konfiguration unterscheiden können. Diese Klasse implementiert auch IHybrisWCFService, unseren Service Kontrakt.

2970-HybrisServiceApplicationProxy.jpg

Die Klasse HybrisServiceApplicationProxy wird für den Zugriff auf HybrisServiceApplication verwendet. Diese Klasse wird benützt, um im client code auf den Service zuzugreifen.

2960-HybrisServicApplicationHost.jpg

Die Klasse HybrisServicApplicationHost wird für das hosting des Service im IIS verwendet

2967-HybrisServiceApplicationHostFactory.jpg

Die Klasse HybrisServiceApplicationHostFactory wird für das Erstellen der s Servicehost verwendet.

2973-HybrisServiceImplementation.jpg

Schliesslich wollen wir noch einen kurzen Einblick in die Logik unseres Service geben. Die von den REST Services ausgelieferten Datenstrukturen werden jeweils durch eine einfach gehaltene Datacontainer-Klasse abgebildet. Wir wollen hier an einem Beispiel aufzeigen, wir die Daten von Hybris geladen werden: Die Klasse Catalogs beinhaltet eine Liste von Katalogen. Wie alle Datencontainer implementiert sie das Interface IDataItem, dass die properties URL und ID erzwingt. Da es sich bei Catalogs um den Einstiegspunkt in die Hybris Catalog-Struktur handelt, muss an dieser Stelle die Url gesetzt werden. Sie wird aus der Konfiguration des Service entnommen. Die Logik des Hybris-Aufrufs und die Verarbeitung des Xml-Streams wird in der Klasse XmlDataElement implementiert. Diese verlangt die Angabe eines generischen Typs T (hier Catalogs). Dieser Typ entspricht dem zu ladenden Datacontainer. Die Hilfsklasse HtmlBase schliesslich übernimmt die Kommunikation mit den REST Services. Der response stream wird geparsed und in die DataContainer Klasse abgefüllt. Im Falle der Catalogs handelt es sich dabei um eine Liste von weiteren REST Urls, die für den Bezug der Detailinformationen zu den einzelnen Katalogen aufgerufen werden können. Dazu wird für jeden Katalog ein XmlDataElement vom Typ Catalog erstellt und die REST Urls der einzelnen Kataloge werden übernommen. Die Katalogdaten können nun geladen werden.

Schlussfolgerung
Durch den Hybris Connector Service können wir von SharePoint-Customcode aus sehr einfach auf Hybris lesend zugreifen. Wir erhalten Instanzen von .Net Klassen zurück und brauchen uns weder um den Aufruf von Hybris noch um das Parsen des ausgelieferten xml zu kümmern. Weiter kann der Service auch business Logik implementieren. So können zum Beispiel durch eine Service-Methode gleich die Daten eines ganzen Katalogs mit allen Kategorien und Produkten zusammengesucht werden. Natürlich würde eine solche Service Methode bald mit Performance-Problemen zu kämpfen haben, weil dazu eine Vielzahl Hybris REST calls nötig sind. Man kann sich aber auch gut vorstellen, dass der Hybris Connector Service eine cache-Struktur aufbaut, um eine ausreichend schnelle Ausleiferung der Daten zu gewährleisten.

Links

Step by Step SharePoint Service Applications
EInführung in Application Services von Daniel Larson. Sehr hilfreich!