Integrationsoptionen von SharePoint 2010 und Microsoft Azure (Teil 2)
Kommentare

Sehen wir uns das größere Bild der Microsoft-Cloud-Welt an. Neben den „Hosted Services“ gibt es die Microsoft Azure Platform. Diese bietet einen komplett anderen Dienstelevel. Während Office 365 Software

Sehen wir uns das größere Bild der Microsoft-Cloud-Welt an. Neben den „Hosted Services“ gibt es die Microsoft Azure Platform. Diese bietet einen komplett anderen Dienstelevel. Während Office 365 Software as a Service (SaaS) bereitstellt – also ein Rundum-sorglos-Paket, geht Azure tiefer: Die Plattform erlaubt es, eigene Web Services, Virtual Machines, Datenbanken, Service Buses etc. in der Cloud zu betreiben. Wenn man über einen Schritt in Richtung Cloud nachdenkt, liegt es also nahe, beide Angebote zu integrieren. Tabelle 1 zeigt die Microsoft-Azure-Dienste in der Übersicht.

Dienst Beschreibung
Windows Azure Stellt Dienste bereit, die es ermöglichen, eigenen Code in der Cloud auszuführen. Als WCF Web Services in .NET programmiert, aber auch PHP und JavaScript (wie node.js)
SQL Azure Stellt einen kompletten SQL-Cluster in der Cloud zur Verfügung. Die Verbindung kann einfach wie gewohnt über einen ConnectionString hergestellt werden.
AppFabric Eine Sammlung von Middleware-Diensten, wie Enterprise Service Bus, Caching und Content Delivery.
Tabelle 1: Microsoft-Azure-Dienste

Denkbar sind Integrationsszenarien, bei denen große Datenmengen in Form von speziellen Formaten, wie CAD-Zeichnungen, anfallen. Diese Daten in SharePoint (und SQL Server) zu speichern, ist auch aus Performancegründen wenig sinnvoll. Denkbar wäre ein in der Azure Cloud ausgerollter Web Service, der vom Azure Blob Storage CAD-Zeichnungen lädt und via Business Connectivity Services SharePoint Online zur Verfügung stellt. Benötigen in Zukunft eigene Anwendungen dieselben Daten, können sie problemlos ebenfalls als Webanwendungen in die Cloud ausgerollt werden und wiederum vie SharePoint REST-API die Daten aus SharePoint aufbereitet verwenden. Ein Geben und Nehmen also. Natürlich können die Anwendungen auch On-Premise laufen und die Daten aus der Cloud holen – friedliche Koexistenz von Cloud on On-Premise.

Ebenen der Integration

In der Praxis ergeben sich aus den vielen Möglichkeiten drei Ebenen der Integration, die in Abbildung 1 zusammengefasst sind. Andrew Connell hat sie im Oktober 2011 auf der SharePoint Conference [3] ausführlich vorgestellt.

Abb. 1: SharePoint 2010 und Azure Levels der Integration
Abb. 1: SharePoint 2010 und Azure Levels der Integration

Die simpelste Integrationsoption ist es, in SharePoint Online Webinhalte anderer Quellen in das bestehende Seitenlayout zu integrieren. Diese Möglichkeit mag trivial klingen, kann jedoch gerade bei SharePoint-Einführungsprojekten ein wichtiger Aspekt sein, sodass man Inhalte von bestehenden webbasierten Systemen in die Oberfläche von SharePoint integrieren kann. Wohl gemerkt: Oberfläche! Natürlich stellt diese Option außer der Anpassung des UI keine echte Integration von Daten oder Prozessen dar. Erreicht werden kann das aber out of the box sehr einfach mit dem Page Viewer Webpart, das ein iframe für einen beliebigen URL erzeugt.

Abbildung 2 zeigt diese Möglichkeit, indem ein lokaler Geodatendienst in eine SharePoint-Seite eingebunden wird. Einfach, aber möglicherweise ausreichend, um den Job zu erledigen.

Abb. 2: Externe Inhalte in das SharePoint-UI integrieren
Abb. 2: Externe Inhalte in das SharePoint-UI integrieren

Ist eine echte Integration von Daten erforderlich, muss man sich die Hände schmutzig machen. Eine etwas fortgeschrittenere Möglichkeit ist die Verwendung von bestehenden Web Services. SharePoint Designer 2010 erlaubt die Integration von WCF Web Services als externe Inhaltstypen in SharePoint 2010 – no Code! Reicht SharePoint Designer aus irgendeinem Grund nicht aus, besteht noch die Option, direkt aus JavaScript auf den Web Service zuzugreifen. Aus eigenem serverseitigem Code funktioniert dies ohne BCS nicht, da die Sandbox Aufrufe auf externe Web Services nicht erlaubt. JavaScript-Code ist eine großartige Möglichkeit, mit sehr wenig Aufwand sehr viel Funktionalität in SharePoint einzubringen. Den Code dynamisch in SharePoint zu integrieren, ist dabei besonders einfach, vorausgesetzt, man verwendet das Content Editor Webpart. Dieses OOB Webpart erlaubt es, beliebige HTML- und auch Script-Blöcke in bestehende Sites einzubinden. Listing 1 zeigt, wie einfach Daten von einem REST Web Service in JavaScript abgerufen werden können. Diesen Script-Block kann man nun direkt in ein Content Editor Webpart (CEWP) kopieren und in bestehende SharePoint-Seiten integrieren (Abb. 3).

Listing 1
$("#results").html("Fetching customers...");
var url = ".cloudapp.net/CustomerService.svc/Customers"
$.getJson(url, function (result) {
    if (result.d.length > 0) {
        $("#results").html("");
        var list = $("
    "); for (var i = 0; i < result.d.length; i++) { var item = $("
  • ").html(result.d[i].Name); $(item).appendTo(list); } } else { $("#results").html("No customers found"); }});
    Abb. 3: JavaScript mit CEWP einbinden
    Abb. 3: JavaScript mit CEWP einbinden

    Alle Developer und Projektverantwortlichen, für die obige Optionen zu wenig oder nicht in Frage kommen, können sich in komplexeren Integrationsszenarien mit den vielen Schnittstellen von Azure und SharePoint austoben. Da die meisten Inhalte, die in Azure verwaltet werden, via HTTP/HTTPS als standardisierte OData Services zur Verfügung gestellt werden, ist die Kommunikation von und nach SharePoint ein Leichtes. Der Zugriff auf SQL-Azure-Datenbanken via BCS erfolgt einfach via ConnectionString. Besser ist jedoch noch der Zugriff über die SQL- Server-eigene, eingebaute OData-REST-Schnittstelle, die dem Trend zur Entkopplung und Servicerientierung Rechnung trägt.

    Unsere Redaktion empfiehlt:

    Relevante Beiträge

    Meinungen zu diesem Beitrag

    X
    - Gib Deinen Standort ein -
    - or -