SQL Server Reporting Services (SSRS) – Wofür können diese eigentlich alles genutzt werden?

Ein schon ein paar Tage zurückliegendes Meeting mit einem Kunden brachte mich auf die Idee für diesen Post.

Es ging dabei um einen Pitch für den SQL Server und all seine Möglichkeiten. Ihr wisst schon, diese “Zeigen Sie mal, was das kann…” Termine in 90Min. Also war wieder selektives & spontanes Highlights zeigen angesagt. Hat ja keiner die notwenigen 48h Zeit.

Ein echtes Highlight aus meiner Sicht sind die Reporting Services (SSRS). Aber ähnlich wie die Integration Services (SSIS), welche gerne mal nach wenigen Minuten mit “sagen Sie doch gleich Schnittstelle…” abgetan werden, sind die Reporting Services für viele einfach “ach so, Berichte, haben wir natürlich schon…” und liegen damit wohl verpackt in einer Schublade, die den Möglichkeiten einfach nicht gerecht wird.

Sofern Ihr auch mal in diese Situation kommen solltet, hier ein paar Anregungen (ohne den Anspruch auf Vollständigkeit) wofür die SQL Server Reporting Services noch alles genutzt werden können.

Berichtswesen (Enterprise Reporting) & Self-Service BI Tool
Klar, das ist DIE Domäne der Reporting Services und da muss sich das Produkt auch nicht vor Marktbegleitern verstecken. Neben den Möglichkeiten im eigentlichen Bericht (Tablix & co), sollte da aber immer auch auf die “Enterprise” Features eingegangen werden, wenn denn ein CIO im Raum ist. Denn Enterprise steht für mich als das Synonym für “Große, komplexe bis unübersichtliche Umgebungen”. Hier können die Reporting Services durch ihren Ansatz als zentraler hochverfügbarer Dienst punkten. Die Verwaltung lässt sich auch weitestgehend automatisieren.

Nur was kann jetzt noch kommen? Was können die Reporting Services nun noch außer Berichte erzeugen? Eine ganze Menge!

Dashboards
Auf Basis der Reporting Services lassen sich aussagekräftige Armaturenbretter (neudeutsch Dashboards) erstellen. Und dabei können diese von Tachometer (Gauge) bis hin zur Sparkline alle geschätzten Visualisierungsansätze verwirklichen. Diese können, sofern notwendig, sich sogar automatisch in quasi Echtzeit aktualisieren.

Benutzeroberfläche für die Endanwender einer Business Intelligence Lösung
Da ja der Microsoft Business Intelligence Stack keine “eigene” Oberfläche mitbringt, steht der geforderte Berater häufig in der Pflicht hier eine kompetente Aussage machen zu müssen. Die korrekte Antwort wäre hier sicherlich SharePoint, aber es gibt immer wieder Gründe, welche den spontanen Einsatz von SharePoint verhindern. Eigentlich schade, aber was dann? Hier können die Reporting Services helfen, da diese ganz hervorragend ein zentraler Anlaufpunkt für die Endanwender sein können. Des Weiteren bietet die Möglichkeit die RDLs untereinander zu verlinken, dem Endanwender ein geschlossenes Benutzererlebnis. Und Funktionen, welche nicht dabei sind, können in ASP.NET relativ leicht nachgereicht werden. Vielleicht sollte ich später mal mehr zu diesem Punkt schreiben.

Benutzeroberfläche für die ETL/Reporting/BI Prozess Verantwortlichen
Das geht dann natürlich auch, denn irgendjemand ist ja für die Prozesse im Hintergrund verantwortlich und möchte oder sollte sich nicht immer gleich aufs Management Studio stürzen müssen, um mal was nachzusehen. Und wo wir gerade in der IT unterwegs sind. Natürlich lassen sich da auch alle anderen IT Prozesse ganz hervorragend mit kapseln und, über die Möglichkeit klassische Hyperlinks dynamisch einzubinden, auch noch interaktiv steuern.

Export Schnittstelle, welche die Fachabteilungen selbst “pflegen” können (Self-Service Schnittstelle)
Die Reporting Services können ja nicht “nur” HTML, Excel, Word & PDF exportieren, sondern auch schnödes CSV & XML. Damit lassen sich sehr einfach zentral gesteuerte (Zugriffsrechte & co) Schnittstellen für Fachabteilungen aufsetzen, welche dann im Detail, wie zum Beispiel Spaltenwahl, vor Ort gepflegt werden können. Damit lässt sich die eine oder andere Access Installation vermeiden.

Datenquelle
Nun aber, die Reporting Services können nicht nur als Daten-Konsument herhalten, sondern mittels Data Feeds (& CSV s.o.) auch als Datenquelle für weitere Prozesse und Anwendungen. Das wohl mittlerweile prominenteste Beispiel dafür ist PowerPivot, welches sich direkt aus existierenden Reports bedienen kann.

Erzeugen von Images
Und hier noch der Hinweis auf ein häufig unterschätztes Feature der Reporting Services. Es können nämlich sehr einfach Images in fast allen benötigten Formaten (jpg, png etc.) erzeugt werden. Damit lassen sich einige sehr schöne Anforderungen umsetzen! :-)

Hier endet meine kleine Liste. Wichtig wären mir noch zwei Hinweise:

1. Berücksichtigt bitte immer, dass die Reporting Services auf unterschiedlichste Wege anzusteuern und einzubinden sind. Erweiterbarkeit und die Möglichkeit der Automatisierung sind meiner Meinung nach fast schon einzigartig für einen “Berichtsserver”. Kreativität zählt hier!

2. Habt bitte immer ein Auge auf die Lizenzierung der Umgebung! Also wer von den Ergebnissen Eurer Prozesse profitiert und damit lizenziert sein müsste usw. Bei Fragen zu Details dazu wendet Euch bitte einfach an Euren Ansprechpartner bei Microsoft! :-)

Popular posts from this blog

PSG Performance Driven Development für den SQL Server

SQL Server in-Memory OLTP – Ein Plädoyer für Lasttest Werkzeuge und End-to-End Monitoring

A short history about SQL Server scalability