Zusammenarbeit: Integration von SQL Server 2008 R2 Reporting Services in SharePoint  2010

  • Artikel

Alan Le Marquand

SQL Server und SharePoint haben schon immer gut zusammengearbeitet. SharePoint Server 2010 und SQL Server 2008 R2 weisen bedeutende Verbesserungen hinsichtlich der Zusammenarbeit zwischen SharePoint und SQL Server 2008 R2 Reporting Services (SSRS) auf. In diesem Artikel werden die Konfiguration und Verwendung dieser neuesten Verbesserungen betrachtet.

Architektur der Serverintegration

Da Reporting Services-Add-in für SharePoint ist eigentlich die Komponente, welche die Zusammenarbeit zwischen den beiden Servern steuert. Sie installieren das Add-In, das als kostenloser Download im Microsoft Download Center verfügbar ist, auf allen SharePoint 2010-Web-Front-End (WFE)-Servern, die mit einem Berichtsserver zusammenarbeiten müssen. Abbildung 1 zeigt die Architektur der Integrationskomponenten.

Auf dem SharePoint 2010 WFE installiert das Add-In drei Komponenten: den SSRS-Proxy, ein Berichts-Viewer-Webpart und die Anwendungsseiten, die es Ihnen ermöglichen, Inhalte von Berichtsservern auf einer SharePoint-Website oder –Farm anzuzeigen, zu speichern und zu verwalten. Der SSRS-Proxy erleichtert die Kommunikation zwischen WFE und dem Berichtsserver. Auf den SharePoint-Seiten für die zentrale Verwaltung der Reporting Services können Sie den Proxy mit dem Berichtsserver konfigurieren, auf den Sie zugreifen möchten, sowie die Authentifizierungsmethode und die Anmeldeinformationen für den Zugriff auf den Server angeben. Damit die Zusammenarbeit funktioniert, müssen Sie den Berichtsserver für die Ausführung im integrierten SharePoint-Modus konfigurieren.

Figure 1: Server Integration Architecture

Abbildung 1 Architektur der Serverintegration

Besonders ist in Abbildung 1 die SharePoint-Objektmodellkomponente auf dem Berichtsserver zu beachten. Damit der Berichtsserver die in SharePoint gespeicherten Berichtsdaten verstehen und sie sichern kann, muss er mit den Konfigurations- und Inhaltsdatenbank der SharePoint-Website oder -Farm interagieren können. Sie erreichen dies, indem Sie eine minimale Kopie von SharePoint auf dem Berichtsserver installieren und der Farm hinzufügen.

Sie müssen auf dem Berichtsserver dieselbe SharePoint-Version installieren, die innerhalb der Farm verwendet wird.  Dies ist nur dann erforderlich, wenn der Berichtsserver auf einem eigenen Computer ausgeführt wird. Wenn SharePoint und Reporting Services auf demselben Computer ausgeführt werden, müssen Sie nur das Add-In installieren.

Konfigurieren der Integration

Insgesamt wurde die Konfiguration der Integration in SharePoint 2010 und SQL Server 2008 R2 vereinfacht. Die Reihenfolge, in der die Konfiguration ausgeführt wird, hängt davon ab, was bereits installiert worden ist. Auch wenn Sie von Grund auf neu beginnen oder von einer vorhandenen Installation ausgehen, ist es wichtig, alle Hauptkomponenten zu installieren, bevor Sie den SSRS-Proxy in SharePoint konfigurieren. Um die besten Ergebnisse bei der Integration von SQL Server Reporting Service 2008 R2 in SharePoint 2010 zu erhalten, wird folgende Reihenfolge empfohlen, wenn Sie von Grund auf neu beginnen:

  1. Führen Sie das Installationsprogramm für die in SharePoint 2010 vorausgesetzte Software aus; damit wird das SSRS 2008 R2-Add-In für SharePoint installiert.
  2. Installieren und konfigurieren Sie SharePoint 2010 in einer Farmkonfiguration.
  3. Wiederholen Sie Schritt 1 und 2 auf dem Computer, der als Berichtsserver fungiert, falls dies ein anderer Computer als der SharePoint WFE-Computer ist, und konfigurieren Sie ihn, sodass er der in Schritt 2 erstellten SharePoint-Farm beitritt.
  4. Installieren Sie SQL Server Reporting Services im integrierten SharePoint-Modus.
  5. Konfigurieren Sie den SSRS-Proxy über die Seite Reporting Services-Integration, und aktivieren Sie das Feature Reporting Services.  

Wenn die Reporting Services-Inhaltstypen auf der Site nicht im Menü Dokument| Neu angezeigt werden, müssen Sie sie manuell hinzufügen. Weiter unten im Abschnitt Integration in Report Builder 3.0 wird beschrieben, wie Sie die Report Server-Inhaltstypen manuell hinzufügen.

In diesem Szenario verwende ich den SQL Server für die SharePoint-Datenbank statt der eingebetteten Version, die standardmäßig in SharePoint verwendet wird. Wenn Sie alle Komponenten auf einem Computer installieren möchten, ist Schritt 5 redundant. Schritt 1 und 2 können im SQL Server-Installationsprozess kombiniert werden.

Wenn bereits eine SharePoint-Installation vorhanden ist, können Sie das Add-In herunterladen und zu einem späteren Zeitpunkt installieren. Während der Add-In-Installation werden sowohl die erforderlichen Seiten der SharePoint-Zentraladministration als auch die neuen Report Server-Inhaltstypen für vorhandene SharePoint-Bibliotheken in Websites mit der Business Intelligence (BI) Center-Websitevorlage hinzugefügt.

Auf der SharePoint-Seite können Sie die Integration entweder in SharePoint Server 2010 oder SharePoint Foundation 2010 konfigurieren. Beide unterstützen die Installation des Reporting Services-Add-ins. Wenn Sie SharePoint und Reporting Services auf verschiedenen Computern installieren, müssen Sie auf dem Berichtsserver dieselbe SharePoint-Version installieren. Beispielsweise können Sie auf dem Berichtsserver nicht SharePoint Foundation 2010 installieren, wenn SharePoint Server 2010 als Web-Front-End verwendet wird.

Die Add-In-Installation ist sehr einfach. Abgesehen von der Eingabe des Namens und der Firma, sind keine weiteren Konfigurationseinstellungen erforderlich. Wenn Sie SharePoint zum ersten Mal installieren, sollten Sie das Add-In vor SharePoint installieren. Wenn Sie das Installationsprogramm für die vorausgesetzte Software ausführen, wird es automatisch installiert.

Die Konfiguration des Berichtsservers ist unkompliziert. Folgende wichtige Punkte sind zu berücksichtigen:

  • Es ist SQL Server Standard Edition, Enterprise Edition oder eine höhere Edition erforderlich.
  • Die Berichtsserverdatenbank muss für die Ausführung im integrierten SharePoint-Modus erstellt werden.
  • Wenn Sie SharePoint und Reporting Services auf verschiedenen Computern installieren, ist eine Minimalinstallation von SharePoint erforderlich, die der Farm auf dem Berichtsserver hinzugefügt wird.

Ein Berichtsserver wird als Windows-Dienst implementiert, der unter einem integrierten Konto oder einem lokalen Benutzerkonto oder einem Windows-Domänenbenutzerkonto ausgeführt wird. Der Berichtsserver-Dienst wird im integrierten SharePoint-Modus entsprechend bereitgestellt, sodass er auf die SharePoint-Konfiguration und –Inhaltsdatenbank sowie die Ressourcen des SharePoint-Objektmodells zugreifen kann. Dies geschieht, wenn die Reporting Services-Integration in SharePoint über die Seite Reporting Services-Integration konfiguriert wird.

Wenn der Authentifizierungsmodus "Windows-integriert" verwendet wird, dann wird beim Aufbau der Verbindung zwischen WFE und Berichtsserver ein Identitätswechsel für den bei SharePoint angemeldeten Windows-Benutzer durchgeführt. Wenn als Authentifizierungsmodus ein vertrauenswürdiges Konto verwendet wird, dann wird der SharePoint-Benutzerkontexts des in SharePoint angemeldeten Benutzers in Form eines SharePoint-Benutzertoken an den Berichtsserver übergeben. Das Anwendungspoolkonto des SharePoint-WFE wird zum Herstellen der Verbindung zwischen WFE und Berichtsserver benutzt. Sie finden eine Zusammenfassung der Dienstkontenkonfiguration im TechNet-Artikel "Konfigurieren von Reporting Services für die SharePoint 2010-Integration.”

Wenn Sie Reporting Services bereits unter Verwendung der Standardeinstellungen installiert haben, dann wurde die Reporting Services-Datenbank im einheitlichen Modus erstellt. Um im integrierten SharePoint-Modus arbeiten zu können, müssen Sie zum SharePoint-Konfigurationstool wechseln und auf der Seite Datenbankeinstellungen den Modus von Einheitlich in Integrierter SharePoint-Modus ändern. 

Sie können den Berichtsservermodus jederzeit vom einheitlichen Modus in den integrierten SharePoint-Modus ändern, damit wird allerdings nicht die vorhandene Datenbank konvertiert. Jedes Mal, wenn Sie den Modus ändern, müssen Sie entweder eine neue Datenbank erstellen oder eine Verbindung mit einer vorhandenen Datenbank herstellen.

Bevor Sie die Reporting Services-Proxyoptionen in SharePoint konfigurieren, müssen Sie eine weitere Einstellung vornehmen. Sie sollten sicherstellen, dass bei der Webanwendung keine anonymen Zugriffe zulässig sind. Dies hindert Sie zwar nicht daran, die Reporting Services-Proxyeinstellungen zu konfigurieren, die Benutzer erhalten jedoch eine Fehlermeldung, wenn sie Berichte ausführen. Sie können die Windows-Authentifizierung oder eine beliebige forderungsbasierte Authentifizierung anderer Anbieter verwenden, und wenn Sie die Zusammenarbeit zwischen einem Berichtsserver und einer SharePoint-Farm konfigurieren, dann kann jede SharePoint-Webanwendung in der Farm für einen anderen Authentifizierungsanbieter konfiguriert werden.

Das Add-In erstellt einen neuen Reporting Services-Abschnitt auf der Seite Allgemeine Anwendungseinstellungen der SharePoint-Zentraladministration. Auf der Seite Reporting Services-Integration geben Sie die Berichtsserver-URL und die Authentifizierungsdaten an und aktivieren das Reporting Services-Feature auf allen oder ausgewählten Websitesammlungen der Farm.

Abbildung 2 Konfigurieren des Reporting Services-Proxy

Nachdem Sie die in Abbildung 2 dargestellte Seite bearbeitet haben, ist die Integrationskonfiguration abgeschlossen.

Integration in Report Builder 3.0

Der Hauptvorteil der Zusammenarbeit zwischen SharePoint und Reporting Services besteht darin, dass sie es Benutzern ermöglicht, Berichte in SharePoint zu erstellen, zu ändern und zu veröffentlichen. Reporting Services stellen einige vordefinierte Inhaltstypen zum Verwalten verschiedener Dateien bereit, darunter freigegebene Berichtsdatenquellendateien (.rsds), Report Builder-Modelldateien (.smdl) und Report Builder-Berichtsdefinitionsdateien (.rdl). Nachdem Sie die Integration so konfiguriert haben, dass die Benutzer diese neuen Inhaltstypen über das Menüband und die Kontextmenüs erstellen und verwalten können, müssen Sie die neuen Inhaltstypen in den Bibliotheken aktivieren.

Wenn Sie die BI Center-Websitevorlage verwenden, müssen Sie gar nichts tun; die Inhaltstypen werden bei der Vorlage und allen Websites, die mit dieser Vorlage erstellt werden, automatisch aktiviert. Bei allen anderen Website- und Dokumentbibliotheken müssen Sie einen zweistufigen Konfigurationsprozess ausführen. Zuerst müssen Sie die Verwaltung des Inhaltstyps in den Bibliotheken aktivieren, sie ist standardmäßig deaktiviert. Dann müssen Sie die Inhaltstypen für die Bibliothek aktivieren. Zur Aktivierung der Inhaltstypverwaltung in einer Dokumentbibliothek befolgen Sie Anleitung im TechNet-Artikel "Vorgehensweise: Hinzufügen von Berichtsserver-Inhaltstypen zu einer Bibliothek (Reporting Services im integrierten SharePoint-Modus).”

Sobald diese neuen Inhaltstypen einer Bibliothek hinzugefügt wurden, sind auf der Registerkarte Dokumente im Dropdownmenü Neu drei neue Optionen verfügbar. Wenn Sie jetzt die Option Berichts-Generator-Bericht auswählen, wird Report Builder 3.0 auf den Client heruntergeladen und ausgeführt. Sie können dieses Verhalten über die SharePoint-Zentraladministration ändern. Auf Seite Reporting Services-Serverstandardwerte können Sie diese Option deaktivieren sowie eine alternative URL für den Berichts-Generator angeben.

Verwenden des Berichts-Viewer-Webparts auf einer SharePoint-Website

Das Berichts-Viewer-Webpart ist eine benutzerdefinierte Webpart-Komponente, die vom Reporting Services-Add-In installiert wird. Sie können mit der Webpart-Komponente auf einem Berichtsserver vorhandene Berichte anzeigen, durchsuchen, drucken und exportieren. Um dieses Webpart einer Seite hinzuzufügen, befolgen Sie die Anleitung im TechNet-Artikel “Vorgehensweise: Hinzufügen von Berichts-Viewer-Webparts zu einer Webseite (Reporting Services im integrierten SharePoint-Modus).”

Jedes Berichts-Viewer-Webpart stellt jeweils einen Bericht dar, der durch die absolute URL der Berichtsdatei (.rdl) in der Report-Eigenschaft angegeben wird. Diese URL muss ein voll qualifizierter Pfad zum Bericht auf der aktuellen SharePoint-Website oder einer Website innerhalb derselben Webanwendung oder Farm sein. Die URL muss in eine Dokumentbibliothek oder einen Ordner innerhalb einer Dokumentbibliothek aufgelöst werden, die den Bericht enthält. Die Berichts-URL muss die Dateinamenerweiterung .rdl enthalten. Wenn der Bericht auf einem Modell oder freigegebenen Datenquellendateien beruht, müssen Sie diese Dateien nicht in der URL angeben. Der Bericht enthält Referenzen auf die benötigten Dateien.

Forderungsbasierte Authentifizierung und Reporting Services

Eines der neuen Features von SharePoint Server 2010 ist die Unterstützung der forderungsbasierten Authentifizierung. In Anwendungen, die Ansprüche unterstützen, stellen Clients "Forderungen" an die Anwendung. Diese Forderungen enthalten Daten über den Benutzer, z. B. den Benutzernamen, die E-Mail-Adresse oder den Namen des Vorgesetzten. Die Anwendung erhält auf diese Weise mehr Informationen als beim Einsatz von Kerberos. Nehmen wir beispielsweise eine Einkaufsanwendung: Zwei Forderungen, die der Anwendung übergeben werden, könnten die E-Mail-Adresse des Vorgesetzten des Benutzers und das Einkaufslimit des Benutzers enthalten. Bei einer Anwendung, die keine Ansprüche unterstützt, müssten diese Daten von der Anwendung verwaltet werden.

Im SharePoint-Universum löst die forderungsbasierte Authentifizierung das Problem der gemeinsamen Nutzung von SharePoint-Websites durch verschiedene Unternehmen. Mithilfe eines Produkts wie Active Directory Federation Services (AD FS) können zwei Organisationen mit verschiedenen Authentifizierungsmethoden Forderungen einrichten, auf deren Grundlage SharePoint einen Benutzer identifizieren und ihm die richtigen Berechtigungen zuweisen kann.

Weil diese Funktionalität in die SharePoint 2010-Produkte integriert ist, können Reporting Services dieses Authentifizierungsmodell nutzen. In Reporting Services selbst werden Forderungen nicht unterstützt; stattdessen erfolgt die Kommunikation mit SharePoint über ein vertrauenswürdiges Konto. Der Proxydienst im SQL Server 2008 R2-Add-In konvertiert mithilfe des SharePoint-Objektmodells die Forderungstoken in den entsprechenden SharePoint-Benutzerkontext in Form eines SharePoint-Benutzertoken, den der Berichtsserver erkennen und anhand der SharePoint-Datenbank überprüfen kann. Kurz, der Prozess funktioniert so:

  1. SharePoint führt die entsprechende forderungsbasierte Authentifizierung durch und übergibt unter Verwendung des SharePoint Secure Token Service den Forderungstoken an den Reporting Services-Proxy.
  2. Der Reporting Services-Proxy benutzt diesen Forderungstoken in der Kommunikation mit dem SharePoint-Objektmodell und generiert einen entsprechenden SharePoint-Benutzertoken, den er an den Berichtsserver weiterleitet.
  3. Der Berichtsserver verwendet den SharePoint-Benutzertoken mit dem lokalen SharePoint-Objektmodell, um den richtigen SharePoint-Benutzerkontext zu erzeugen.
  4. Wenn der Benutzer über die erforderlichen Berechtigungen verfügt, sendet der Berichtsserver die angeforderten Informationen wie gewöhnlich unter Verwendung des entsprechenden SharePoint-Benutzerkontexts an SharePoint.

Systemeigene Listenberichterstellung

In SQL Server 2008 R2 Reporting Services werden jetzt SharePoint-Listen als Datenquellen unterstützt. Dies ermöglicht es Ihnen, Listendaten aus SharePoint Foundation 2010, SharePoint Server 2010, Windows SharePoint Services 3.0 und Office SharePoint Server 2007 abzurufen. Diese Fähigkeit zum Zugriff auf Listendaten ist nicht vom Add-In oder davon abhängig, ob der Berichtsserver im einheitlichen Modus oder im integrierten SharePoint-Modus ausgeführt wird. Diese Funktionalität ist in den Berichtsserver integriert. In den verschiedenen Konfigurationen ist lediglich die Zugriffsmethode unterschiedlich.

Es gibt zwei Methoden, mit denen auf SharePoint-Listendaten zugegriffen werden kann. Einmal über den Webdienst lists.asmx und zum Zweiten über die APIs des SharePoint-Objektmodells. Sie können bei jeder beliebigen SharePoint-Installation die URL http://<sharepoint_server_name>\lists.asmx eingeben und erhalten eine XML-Liste aller Listen der SharePoint-Website, auf die Sie zugreifen können. Mit dieser Methode kann Report Builder 3.0 die Listen abrufen. Berichtsserver, die für den einheitlichen Modus konfiguriert wurden, müssen ebenfalls diese Methode verwenden.

Die SharePoint-Objetkmodell-API-Methode kann in zwei Szenarien verwendet werden. In einem Szenarium ist der Berichtsserver für den integrierten SharePoint-Modus konfiguriert und die Liste befindet sich in derselben SharePoint-Farm, in die Reporting Services integriert wurde, und alle diese Komponenten befinden sich auf demselben Computer. Denken Sie daran, dass in diesem Szenario eine SharePoint-Instanz auf dem Berichtsserver ausgeführt wird, die diesem Zugriff auf die APIs gewährt. In dem anderen Szenario wurde SharePoint 2010 zusammen mit dem Add-In installiert, aber es ist kein Berichtsserver vorhanden. Dies wird als lokaler Modus bezeichnet und weiter untern im Abschnitt "Berichtserstellung ohne Reporting Services" behandelt.

Um die aus einer SharePoint-Liste abgerufenen Daten in einem Bericht verwerten zu können, müssen Sie zuerst eine Datenquelle und anschließend ein Dataset erstellen, das diese Datenquelle verwendet. In Report Builder 3.0 ist ein neuer Verbindungstyp auf der Eigenschaftenseite für Datenquellen verfügbar, der Microsoft SharePoint-Liste heißt und in Abbildung 3 dargestellt ist. Bei dieser Option geben Sie die URL der SharePoint-Website ein, wobei Sie lists.asmx der URL nicht hinzufügen müssen. Die Datenquelle kann auch mit den verschiedenen Anmeldeinformationen konfiguriert werden, die beim Zugriff auf den SharePoint-Server verwendet werden sollen.

Figure 3: SharePoint List Connection Type

Abbildung 3 Verbindungstyp SharePoint-Liste

Wenn Sie auf der Grundlage dieser Datenquelle ein neues Dataset erstellen, erhalten Sie eine Liste aller SharePoint-Listen der Website, auf die Sie zugreifen können. Sie können in einer Liste auf einzelne Listenelemente zugreifen, Filter erstellen, Parameter definieren und Berichte erstellen, so als handelte es sich um eine SQL-Datenbanktabelle.

Unterstützung der alternativen Zugriffszuordnung

Eine weitere Verbesserung für die Integration ist die Unterstützung der alternativen Zugriffszuordnung (Alternate Access Mapping, AAM). Dieses Feature ist seit der Version SharePoint 2007 verfügbar, wurde von Reporting Services jedoch nicht unterstützt. Wenn Sie jetzt eine alternative Zugriffszuordnung in der SharePoint-Zentraladministration konfigurieren, behält das Reporting Service-Add-In die URL-Struktur bei. Der einfache Bericht in Abbildung 4 zeigt dies. Sowohl http://sql-01 als auch https://www.contoso.com ergeben denselben Bericht.

Figure 4: Alternate Access Mapping

Abbildung 4 Alternative Zugriffszuordnung

Berichtserstellung ohne Reporting Services

Bislang bezogen sich alle Informationen in diesem Artikel auf das, was verbundener Modus genannt wird In den früheren Versionen von Reporting Services war dies der einzig verfügbare Modus und bedeutete, dass SharePoint mit einem Reporting Services-Berichtsserver, der für den integrierten SharePoint-Modus konfiguriert war, verbunden sein musst, um Bericht im Berichts-Viewer darstellen zu können.

Seit dem Erscheinen von SQL Server 2008 R2 können Sie Berichte rendern, ohne die SharePoint-Website oder –Farm in einen Reporting Services-Berichtsserver integrieren zu müssen. Stattdessen können Sie im Berichts-Viewer direkt Berichte aus SharePoint darstellen, wenn die Datenerweiterung die Berichtserstellung im lokalen Modus unterstützt. Standardmäßig unterstützen nur die Reporting Services-Erweiterungen für SharePoint-Listen und Microsoft Access 2010 dies.

Wenn der lokale Modus aktiv ist, können Sie einen Bericht darstellen, der über eine eingebettete Datenquelle oder eine freigegebene Datenquelle aus einer RSDS-Datei verfügt. Sie können allerdings weder den Bericht noch die zugehörige Datenquelle verwalten, da dies im lokalen Modus nicht unterstütz wird.

Unterstützte Kombinationen von SharePoint-Add-In und Berichtsserver

Seit dem Erscheinen von SQL Server 2008 R2 und SharePoint Server 2010 sind mittlerweile drei SQL-Versionen, drei Add-In-Versionen und zwei SharePoint-Versionen verfügbar. Die Integrationskomponenten können mit allen diesen Versionen eingesetzt werden, sie müssen jedoch die richtigen Versionen einander zuordnen. Die Tabelle in Abbildung 5 enthält die unterstützten Produktkombinationen.

Figure 5: Supported Combinations of the SharePoint Add-In Report Server

Abbildung 5 Unterstützte Kombinationen von SharePoint-Add-In und Berichtsserver

Alan Le Marquand* ist in Großbritannien ansässig und IT Pro Content Architect für Microsoft. Weiteres Lesematerial von Le Marquand finden Sie in seinem Blog** Alan’s World of IT*.

Verwandter Inhalt