SharePoint in Office 365 – Site Collection übergreifend Daten anziehen

In den meisten SharePoint Projekten – sei es on-premise oder in der Cloud – kommt man früher oder später an den Punkt, an dem Daten über Site Collections hinweg angezogen werden sollen. Diese Grenzen sind in on-premise Lösungen mit dem Objektmodel (SPSite, SPWeb, SPList, usw.) relativ einfach zu umgehen. In der Cloud und mittels clientseitigen SharePoint Technologien (z.B. mit CSOM) hingegen kann dies auf den ersten Blick nicht ganz so einfach realisiert werden. Doch mit der ausgebauten REST-Api in SharePoint 2013 ist dies trotzdem auf einfache und effiziente Art und Weise möglich. In einem kleinen Beispiel möchte ich aufzeigen, wie mittels einfachem REST Call Websites Site Collection übergreifend angezogen werden können. (mehr …)

TypeScript SharePoint 2013 App

SharePoint-hosted Apps für SharePoint 2013 schreibt man bekanntlich vermehrt in JavaScript. Da für JavaScript Sprachkonstrukte wie Klasse, Interfaces, Vererbung oder Module nicht existieren, ist es für .NET Entwickler vielfach nicht ganz einfach JavaScript Anwendungen richtig zu schreiben. Um diese Probleme in der Frontend Entwicklung zu eliminieren, hat Microsoft die Programmiersprache TypeScript entwickelt. TypeScript stellt einen Compiler zur Verfügung, welcher TypeScript Code in JavaScript Code umwandelt. Ebenso existiert ein Visual Studio Plugin, welches dem Entwickler IDE Support für TypeScript gibt. Eine Anleitung für die Installation ist auf der offiziellen Website von TypeScript beschrieben.
(mehr …)

RazorEngine in SharePoint 2013 nutzen

Da SharePoint 2013 auf dem .NET Framework 4 (oder 4.5) läuft, kann nun auch die OpenSource Templating Engine Razor in SharePoint Projekte eingebunden werden. SharePoint an sich basiert zwar weiterhin auf den bewährten ASP.NET WebForms, doch können Custom WebParts oder Controls sehr einfach auf die RazorEngine zugreifen.

In diesem Blogpost soll ein einfaches WebPart erstellt werden, welches aus einer SharePoint Liste alle Titel der Elemente ausliest und ausgibt.

Ich erstelle also ein neues SharePoint 2013 Projekt in Visual Studio und füge via NuGet Manager die Razor Engine der Solution hinzu. Anschliessend müssen unbedingt die beiden Assemblies (RazorEngine.dll und System.Web.Razor.dll) im SharePoint Package als additional Assemblies für den GlobalAssemblyCache hinzugefügt werden.

nuget

 

Als nächstes erstelle ich ein neues WebPart in der Solution. Dem WebPart wird ein Property für das Razor Template hinzugefügt. In dieses WebPart Property kann man später sein Model als WebPart Property bearbeiten.

[WebBrowsable(true),
WebDisplayName("TemplateModel"),
WebDescription("TemplatModel Property"),
Personalizable(PersonalizationScope.Shared),
Category("Template")]
public string TemplateModel { get; set; }

Ebenso überschreibe ich die Render Methode, um darin die Parse Methode von der Razor Engine aufzurufen. In meiner Render Methode werden statische Werte geladen, aber auch alle Titel der Seiten in der Pages Library des aktuellen SPWebs geladen.

protected override void Render(HtmlTextWriter writer)
{
// irgendwelche statischen Werte
const string title = "Pages Titles";
var pagesList = SPContext.Current.Web.Lists["Pages"].Items;
var pages = (from SPListItem page in pagesList select page.Title).ToList();
// erstelle ein Model (hier als anonyme Klasse gelöst)
var model = new { Data = title, Pages = pages };
// Parse das Model wenn ein Model vorhanden ist oder geb eine Fehlermeldung aus
if(!string.IsNullOrEmpty(TemplateModel))
{
var parsedHtml = Razor.Parse(TemplateModel, model);
// und der Output wird gerendert
writer.Write(parsedHtml);
}
else
{
writer.Write("Definiere ein Model in den WebPart Properties");
}
}

Nachdem die Solution deployed wurde, kann das WebPart auf einer Page hinzugefügt und editiert werden. Hier wird nun mittels RazorTemplate auf das im Code mitgegebene Model zugegriffen.

editwebpart

 

Wird das WebPart anschliessend gespeichert, rendert es folgenden Output auf die Seite.

webpart

Dieses kleine Beispiel zeigt, wie einfach es ist, mittels RazorEngine WebParts für SharePoint 2013 zu entwickeln.

 

Einblick in die SharePoint 2013 Search Architektur

An der TechEd 2013 in Madrid erzählte Jan Inge Bergseth über Search Architektur, Sizing und Migration in SharePoint 2013. In diesem Blogpost möchte ich auf die Search Architektur eingehen und aufzeigen, welche Änderungen im Vergleich zur 2010er Version auftauchen.

Architektur

Bekannterweise wurde FAST in die neue SharePoint 2013 Search integriert. Dabei wurde, wie in der folgenden Grafik ersichtlich, der Indexing Mechanismus von FAST übernommen. Die Crawl Komponenten und die Content Processing Komponente (zusammen als Feeding Chain bezeichnet) sind identisch zu denjenigen aus den vorangehenden SharePoint Versionen. Neu hinzugekommen ist jedoch der Crawl Modus „Continous Crawl“, welcher es erlaubt, mehrere Incremental Crawls gleichzeitig zu starten. Genauere Erklärungen darüber sind im Internet zu finden.

Analytics Service

Im obigen Diagramm ist der Analytics Processing Service als Schnittstelle zwischen Search Index, WFE (Web Frontend Server) und der Content Processing Komponente zu sehen. Das bedeutet, dass sowohl die Interaktionen der User auf dem WFE als auch die Indexierung Einfluss auf den Analytics Processing Service haben. Deshalb wird auch von Search Analytics und Usage Analytics gesprochen. Der Search Teil kann dafür gebraucht werden, um Search Reports oder das allgemeine Search Verhalten zu analysieren. Der Usage Teil hat Einfluss auf Funktionalitäten von SharePoint selbst. Über eine Schnittstelle zum Service können zum Beispiel Items ermittelt werden, die von demselben Benutzer schon angeklickt, oder allgemein am meisten betrachtet wurden.

 

Scaling

Über das Scaling der SharePoint Search – wer bereits eine SP2013 Search aufgesetzt, getestet oder in Betrieb hat, weiss, dass diese anders skalliert als die 2010er Search – möchte ich nicht allzu viele Worte verlieren. Aber folgendes Cheat-Sheet möchte ich niemandem vorenthalten. Es zeigt auf, welche Komponente wie viel CPU und Memory aber auch wie viel Last auf Disk und Netzwerk benötigen und hilft somit, eine optimale Search Architektur aufzubauen.

 

SharePoint 2013 – Installation und System Requirements

Mit der neuen Version von SharePoint und dem Windows Server ändern sich für die Inbetriebnahme einige Dinge bei den Systemvoraussetzungen und minimal bei der Installation im Vergleich zu SharePoint 2010. In diesem Blogpost sollen diese Unterschiede aufgezeigt und verdeutlicht werden.

SharePoint 2013 läuft auf den folgenden beiden Betriebssytemen:

  • Windows Server 2008 R2 Service Pack 1 x64
  • Windows Server 2012

Die minimalen Hardware Requirements sind analog zu denjenigen, welche SharePoint 2010 benötigte. Das bedeutet, für einen Web- oder Application Server gelten folgende Richtwerte:

  • 64-bit, vier Cores Prozessor
  • 8 GB Ram pro Server in der SharePoint Farm
  • mindestens 80 GB Festplattenspeicher auf der Systemdisk

Der Datenbankserver braucht mindestens eine Installation des SQL Server 2008 R2 Service Pack 1 in der 64-bit Edition. Natürlich kann hier auch die neue SQL Server 2012 in der 64-bit Edition verwendet werden. Für den Datenbankserver gelten folgente Richtwerte an die Hardware Anforderungen:

  • 64-bit, 4 Cores für kleine Deployments, 8 Cores für mittlere Deployments
  • 8 GB Ram pro Server für kleine Deployments, 16 GB für mittlere
  • 80 GB Festplattenspeicher auf der Systemdisk

Die Installation von SharePoint 2013 verläuft analog zu derjenigen von SharePoint 2010.

Bei den Software Voraussetzungen für eine SharePoint 2013 Installation gibt es einige Änderungen. Die wichtigste ist, dass SharePoint 2013 neu auf dem .NET Framework 4.0 läuft.
Oftmals ein wichtiger Punkt bei SharePoint Projekten ist die „Browser Matrix“, also auf welchem Browser SharePoint für den Benutzer einwandfrei läuft. Für die SharePoint Version 2013 gilt folgende Matrix:
Wichtig dabei ist, dass die drei Internet Explorer Versionen (8, 9, 10) nur in der 32-bit Version unterstützt werden. In der 64-bit Version des Internet Exploreres, wie auch bei den weiteren unterstützten Browsern (wie Firefox, Chrome oder Safari), müssen mit Limitationen gerechnet werden.