COMPAREX AG
Microsoft Ignite SharePoint

Microsoft Ignite: So entwickeln Sie zukunftssichere Lösungen für SharePoint Online und On-Premise

Die Ignite, Microsofts RIESEN Tech-Event, ist das Mekka für Collaboration- und Network-Interessierte. Unser SharePoint Team ist nach Chicago gereist und berichtet für Sie von spannenden Fach-Sessions rund um die Themen SharePoint und Office 365. Daniel Koszior hat sich für Sie umgehört, wie man Lösungen für SharePoint On-Premise und SharePoint Online zukunftssicher entwickeln kann.

Ein Beitrag von Daniel Koszior, Software Architect Team Portals & Collaboration

„The Evolution of SharePoint“: Wie sollte die Entwicklung von SharePoint-Lösungen in Zukunft aussehen?

Microsoft hat mit der Evolution von Office 365 und SharePoint Online die bestehenden Konzepte für die Entwicklung von SharePoint-Lösungen nahezu vollständig umgekrempelt. Bei der traditionellen SharePoint Entwicklung wurde die Verwendung des Feature Frameworks auf Basis der Collaborative Application Markup Language (CAML) gepriesen und so wurde diese Technologie von jedem SharePoint Entwickler verwendet. Nun wird die Verwendung von Solutions und Features als großes "Don't" betrachtet. Das hat den Hintergrund, dass durch jedes Feature-Manifest eine Abhängigkeit zu einer XML-Datei in der entsprechenden Inhaltsdatenbank des Lösungsziels entsteht. Dadurch erhöht sich der Aufwand bei Migrationen und Updates. Sämtliche programmatischen Änderungen jedoch werden direkt in der Inhaltsdatenbank durchgeführt und haben keinerlei Abhängigkeiten zu Dateien außerhalb. Das ist im Hinblick auf Upgrade- und Migrationsszenarien großartig, denn die Inhaltsdatenbank kann ohne weiteres aktualisiert und in späteren Versionen von SharePoint weiterverwendet werden. Keinerlei Anpassungen an Lösungen und den darin enthaltenen Features sind nötig. Es existieren schlicht keine.

New kind of Dev: CSOM und JavaScript rule the (SharePoint) world

Wie kann man aber nun ohne Features und klassische Lösungspakete reproduzierbare Anpassungen vornehmen? Der Weg ist wie beim Branding von SharePoint und Office 365  clientseitig. Das SharePoint-App-Model ist hierfür geradezu prädestiniert. Insbesondere Provider-Hosted-Apps für SharePoint bieten die Möglichkeit, Funktionalität von außen zu SharePoint hinzuzufügen. Sie basieren auf einer SharePoint Website (App-Site) und einem extern gehosteten Web-Projekt (beispielsweise auf Windows Azure). Die App-Site bzw. ein App-Part innerhalb SharePoint kommuniziert mit der externen Website und ermöglicht so die Übergabe des SharePoint Kontexts inklusive benötigter Rechte. In der externen Website kann nun Programmcode im Kontext der SharePoint oder SharePoint Online Umgebung ausgeführt werden. Somit hat man dort eine Art Ankerpunkt für jegliche Modifikationen innerhalb der SharePoint Plattform, die das Client Side Object Model (CSOM) bietet. Dieses kann mit .NET Sprachen wie C# und VB.NET oder auch mit JavaScript verwendet werden. Der Funktionsumfang wächst kontinuierlich und bietet jetzt schon sehr viele Möglichkeiten der Manipulation.

Tipp: Falls Sie jetzt doch merken, dass Sie bei Ihrer geplanten SharePoint-Lösungsentwicklung auf externe Unterstützung setzen müssen, dann geben Sie Ihr Projekt unseren COMPAREX SharePoint-Experten in die Hand. Topaktuelles Wissen inklusive…

Mehr über unsere COMPAREX SharePoint Leistungen »

Custom Site Provisioning

Um angepasste Websites innerhalb von SharePoint und SharePoint Online zu erstellen, wurde bei der klassischen Entwicklung eine Site Definition oder ein Web-Template verwendet. Nun wird diese Vorgehensweise durch das Erstellen einer ähnlichen Standard-Websitevorlage und nachträglicher Manipulation per CSOM ersetzt. Derzeit entstehen hierfür Frameworks um diese Funktionen wiederverwendbar zu machen. Der Link "Neue Website" innerhalb der SharePoint Oberfläche wird per JavaScript Injektion (siehe Blog-Beitrag Branding) modifiziert um die Erstellung von der extern gehosteten App-Website aus zu starten.

Lists, Site Columns und ContentTypes

All diese SharePoint Objekte werden nun im Rahmen des Custom Site Provisioning per Programmcode erzeugt. Microsoft rät ab von der Verwendung von Custom List Definitions, weil auch hier eine Abhängigkeit zur Listendefinition (Schema.xml) entsteht. Nunmehr werden Instanzen von Standard-Listenvorlagen erzeugt und nachträglich mit Spalten und Inhaltstypen versehen. Diese werden natürlich ebenfalls per CSOM erzeugt.

Custom Field Types

Für besondere Funktionalitäten wie beispielsweise kaskadierbare Lookup-Felder wurden bisher Custom FieldTypes verwendet. Dies ist aber in SharePoint Online nicht möglich, weil hierbei XML-Dateien im SharePoint Verzeichnis global referenziert werden. Über bereits bestehende Funktionalitäten wie JSLink kann dies clientseitig per JavaScript realisiert werden. Benötigen solche Felder zusätzliche Konfigurationen, kann dies nicht mehr direkt im Feldschema gespeichert werden. Eine Möglichkeit wäre der Property Bag der Liste, in der eine solche Feldinstanz verwendet werden soll.

Timer Jobs

Klassische Timer Jobs können in SharePoint Online nicht mehr verwendet werden. Alternative Lösungen müssen hier Abhilfe schaffen. Beispielsweise kann auch auf einem extern gehosteten Server ein zeitgesteuerter Auftrag ausgeführt werden, der per CSOM auf SharePoint zugreift.

Event Receivers

Klassische SharePoint Event Receiver wurden ausschließlich über serverseitigen Programmcode ausgeführt. Dies hat das Ausrollen von eigenen Programmbibliotheken erfordert. Aus diesem Grund ist dies nicht mehr möglich, da eine solche Installation eigener Bibliotheken auf SharePoint Online nicht erlaubt ist. Farmweite Änderungen wie das Ausrollen von Bibliotheken würden sämtliche Kundenportale beeinflussen. Es herrschen Multi-Tenancy-Bedingungen. Um ähnliche Funktionalitäten zu erhalten, existieren Remote-Event Receiver, die durch einen Aufruf eines eigenen externen Webservices ausgelöst werden. Dieser Webservice wiederum verwendet CSOM um auf den Event zu reagieren. In der Natur der Sache liegt leider, dass nur noch asynchrone Events möglich sind. Auch die Erstellung eines Webservices ist komplex. Hier kann man nur hoffen, dass Microsoft eine elegantere Lösung finden wird.

In aller Kürze: Meine Empfehlung für Ihre nächste Entwicklung einer SharePoint-Lösung

Es gilt wie auch schon in meinem vorangegangenem Blog-Beitrag zum Branding von SharePoint und Office 365, dass sämtliche Anpassungen ausschließlich clientseitig geschehen sollten. Ich empfehle das Entwickeln von Frameworks, die das Customizing von SharePoint konfigurierbar vornehmen. Je nach Verwendungsart kann dies über Apps oder aber völlig andere autarke Mechanismen erreicht werden. Bei Migrationen von On-Premise SharePoint Installationen sollte nicht versucht werden, den bestehenden Full-Trust-Code zu übernehmen. Vielmehr sollte überlegt werden, wie die enthaltenen Funktionalitäten mit CSOM oder gar mit Standardmitteln abgebildet werden können. Wenn man sich absolut sicher ist, dass die eigene SharePoint Umgebung niemals in die Cloud migriert werden soll, dann kann man Farmlösungen verwenden. Aber wer weiß schon, was die Zukunft bringt.

Alle Berichte von der Microsoft Ignite rund um SharePoint und Office 365 finden Sie hier.

Finden Sie Ihren SharePoint Aha-Moment!

Verschaffen Sie sich auf unserer Roadshow einen Überblick zu aktuellen SharePoint-Entwicklungen und sammeln Sie neue Ideen, wie Sie Ihren SharePoint in Zukunft noch besser nutzen können. Alles was Sie wissen müssen erfahren Sie von unserem SharePoint Expertenteam in kurzen Vorträgen mit Live-Demos und anschaulichen Praxisbeispielen.

20.10.2016 | München 02.11.2016 | Frankfurt 15.11.2016 | Düsseldorf Jetzt anmelden »
25.10.2016 | Stuttgart 08.11.2016 | Leipzig 17.11.2016 | Hamburg

 

Diesen Artikel teilen

Artikel vom:
12.05.2015

geschrieben von:

TAGS:
Microsoft, SharePoint

Thema:

Kommentieren sie diesen Artikel...

© COMPAREX AG
Zurück nach oben