Ich möchte hier kurz beschreiben, wie es möglich ist, unter Verwendung der ReportServer Datenbank, die Ausführung der Abonnements einfach zu verwalten.

Die Grundidee

Die Reporting Services speichern ihre Abonnements in der zugehörigen DB(Standardname: ReportServer). Die Tabelle in der alle Abonnements aufgeführt sind nennt sich dbo.Subscriptions:

In dieser Tabelle gibt es eine Spalte mit dem Namen InactiveFlags. Bei einem aktiven Abo ist dieser Wert auf 0 gesetzt. Um das Abo zu deaktivieren muss dieser Wert auf 1 geändert werden.

Die Umsetzung

Zunächst benötigen wir noch einige Tabellen, um die Lesbarkeit zu erhöhen, indem wir die IDs durch die zugehörigen Namen für Bericht, Abonnement und Benutzer ersetzen:

 

Mit dem nachfolgendem SQL-Statement können wir die passenden Informationen auslesen:

SELECT
     s.[SubscriptionID]
     ,s.[Description]
             ,u.UserName
             ,c.Name as ReportName
             ,[InactiveFlags]
             ,rs.ScheduleID AS JobName
             ,rs.ReportAction
             ,[ExtensionSettings]
             ,[Locale]
             ,s.[ModifiedByID]
             ,s.[ModifiedDate]
             ,[LastStatus]
             ,[EventType]
             ,[MatchData]
             ,[LastRunTime]
             ,[Parameters]
             ,[DataSettings]
             ,[DeliveryExtension]
             ,[Version]
             ,[ReportZone]
             ,[OwnerID]
             ,[Report_OID]
FROM [ReportServer].[dbo].[Subscriptions] s
             inner join dbo.Users u on u.UserID = OwnerID
             inner join [dbo].[Catalog] c on s.Report_OID = c.ItemID
             inner join [dbo].[ReportSchedule] rs on s.SubscriptionID = rs.SubscriptionID

Abhängig von den Abonnements sollte die Abfrage in etwa das folgende Ergebnis liefern:

 

Mit den oben stehenden Informationen können wir jetzt einzelne Abonnements aktivieren bzw. deaktivieren.

Für die Deaktivierung kann folgende Query verwendet werden:

UPDATE Subscriptions set
[InactiveFlags] = 1
where
[SubscriptionID] = ‘929CDEE8-…’
END

Für die Aktivierung kann das gleiche Update-Statement verwendet werden, der Wert InactiveFlags muss jetzt nur auf 0 gesetzt werden.

Ausführung von Abonnements

Gelegentlich kommt es vor, dass ein Abonnement außerhalb der geplanten Zeiten durchgeführt werden soll.

Da die Ausführung der Abonnements über den SQL Server Agent gesteuert wird, haben wir die Möglichkeit die passenden Jobs von Hand zu starten. Dies kann im SQL Server Management Studio erfolgen.

Oder es können vordefinierte gespeicherte Prozeduren aus der msdb Datenbank verwendet werden.

EXEC msdb.dbo.sp_start_job ‚251601B4…’


Die IDs der für die angelegten Jobs und die IDs für die zugehörigen Abos sind in der [dbo].[ReportSchedule] Tabelle der ReportServer DB hinterlegt. Wenn man diese Tabelle noch mit der dbo.Subscriptions verbindet:

SELECT
   [ScheduleID]
  ,[ReportID]
  ,rs.[SubscriptionID]
  ,s.Description
  ,[ReportAction]
FROM [dbo].[ReportSchedule] rs
INNER JOIN dbo.Subscriptions s ON rs.SubscriptionID = s.SubscriptionID

können die JobIDs den zugehörigen Abos zugeordnet werden.

Der passende Bericht

Nachdem die Grundlagen für die Deaktivierung bzw. Aktivierung der Abonnements geklärt sind, kann ein einfacher Bericht erstellt werden, mit dem die Ausführung und der Status des Abos gesteuert werden kann.

Für den Bericht muss eine Datenquelle für die ReportServer Datenbank erstellt werden und die folgenden Parameter werden benötigt, um die zugehörigen Funktionalitäten zu gewährleisten:

Des Weiteren brauchen wir ein Dataset, das zum einen die Informationen, wie vorhandene Abos, Berichtsnamen, etc. ermittelt, um sie im Bericht anzuzeigen, zum anderen aber auch Abos aktiviert und deaktiviert, sowie einzelne Jobs ausführt. Die Steuerung der Ausführung wird durch die einzelnen Parameter vollzogen und einzelne Teile der Abfrage übergangen oder ausgeführt:

if @SetActiv = 1
BEGIN
UPDATE Subscriptions set [InactiveFlags] = @InactiveFlags
where
    [SubscriptionID] = @id
END

if @Execute = 1
BEGIN
EXEC msdb.dbo.sp_start_job @JobName
WAITFOR
delay ‘00:00:05′
END

SELECT s.SubscriptionID, rs.ScheduleID AS JobName, s.OwnerID, u.UserName, s.Report_OID, c.Name AS Reportname, s.Description AS SubDesc, s.InactiveFlags AS Active, s.ExtensionSettings, s.Locale, s.ModifiedByID, s.ModifiedDate, s.LastStatus, s.EventType, s.MatchData, s.LastRunTime, s.Parameters, s.DataSettings, s.DeliveryExtension, s.Version, s.ReportZone
FROM Subscriptions AS s
   INNER JOIN Users AS u ON u.UserID = s.OwnerID
   INNER JOIN Catalog AS c ON s.Report_OID = c.ItemID
   INNER JOIN ReportSchedule AS rs ON s.SubscriptionID = rs.SubscriptionID


Im unteren Teil der Abfrage werden die Informationen ermittelt, im oberen Teil wird zunächst der Status des Abos aktualisiert oder der ausgewählte Job gestartet. Dadurch, dass das Statusänderungen und Jobausführungen über die Links in der Tabelle gesteuert werden, ist immer nur einer der beiden Parameter @SetActiv und @Execute eins und es wird immer nur eine der beiden Aktionen ausgeführt.

Um die Daten anzuzeigen erstellen wir eine einfache Tabelle:


Für das Feld Aktiv wird die folgende Expression: =iif(Fields!Active.Value = 0,“Aktiv”,“Deaktiviert”) verwendet und die folgende Aktion, für die Änderung des Status, definiert:


Zum Schluss muss noch das Ausführen des Jobs ermöglicht werden. Hierfür definieren wir eine Aktion für das Textfeld Execute:

Jetzt ist der Bericht soweit fertig, dass der Status und das Ausführen der Abos verwaltet werden kann, birgt aber noch die ein oder andere Gefahr in sich. So wird z.B. ein Abo erneut ausgeführt, wenn man den Bericht nach einem Execute aktualisiert. Für eine erste Demonstration sollte er aber reichen.

Freigegebene Data Sets

Genau wie freigegebene Datenquellen, die in jedem größerem Projekt verwendet werden, um Änderungen an der Datenquelle an zentraler Stelle zu realisieren, können jetzt auch Data Sets freigegeben werden und in einem geeigneten Ordner auf dem Server zu speichern. Freigegebene Data Sets können von allen Berichten verwendet werden, so können Sie z.B. für einen Parameter, der in mehreren Berichten vorkommt, ein Data Set anpassen, dieses freigeben und es dann auch in den anderen Berichten verwenden.
Mit dem Report Builder können Sie alle freigegebenen Data Sets auf dem Server verwenden, mit dem BIDS hingegen können Sie nur die freigegebenen Data Sets ihres Projekts verwenden.

Report Part Gallery

Seit der November CTP ist es möglich Teile eines Berichts zu veröffentlichen. Diese Report Parts können dann in anderen Berichten verwendet werden. Im Gegensatz zu den freigegebenen Data Sets, können Report Parts in einem neuen Bericht weiter angepasst werden, ohne dass die Vorlage davon beeinflusst wird. Ein Report Part wird sozusagen ein normales Berichtselement im neuen Report. Falls das Original aktualisiert wurde, wird Ihnen dies mitgeteilt, damit Sie Ihre verwendeten Elemente aktualisieren können.
Beim Hinzufügen eines Report Parts werden automatisch die zugehörigen Data Sets und Datenquellen mit angelegt.
Report Parts können sowohl mit dem BIDS, als auch mit dem Report Builder erstellt werden. Sie können aber zurzeit nur mit dem Report Builder verwendet werden, indem Sie einfach per Drag&Drop aus der Report Part Gallery in den Bericht gezogen werden.

Folgende Elemente stehen zur Verfügung:

• Charts
• Tabellen, Matrizen und Listen
• Messgeräte
• Maps
• Bilder
• Rectangles

Neue Berichtselemente zur Datenvisualisierung

Die neuen Berichtselemente sind speziell konzipiert worden, um in Tabellen und Matrizen eingesetzt zu werden.

Sparklines und Data Bars

Sparklines und Data Bars sind einfache Charts, die nur die wesentlichen Elemente beinhalten und gänzlich auf Legenden, Achsen und Beschriftungen verzichten. Sie werden in erster Linie in Tabellen und Matrizen verwendet, um viel Information auf möglichst geringem Raum zu repräsentieren.
Typischerweise zeigen Data Bars nur einen Wert pro Zeile an, um den Vergleich der Werte untereinander zu vereinfachen:

Im Gegensatz zu den Sparklines, die normalerweise den zeitlichen Verlauf wiederspiegeln:

Bei den Sparklines wäre noch anzumerken, dass sie nur in Gruppen- und nicht in Detailzeilen verwendet werden können.

Indikatoren

Indikatoren werden verwendet, um den Status eines Wertes auf den ersten Blick erkennen zu können. Sie werden häufig in Tabellen und Matrizen eingesetzt. Ein Indikator ist ein vereinfachtes Messgerät und kann auch in eben dieses umgewandelt werden. Sie können Trends anhand von Pfeilen, Abstimmungen durch Sterne und Status durch Bilder wie z.B. der Ampel darstellen:

Erweiterungen der RDL Ausdruckssprache

Aggregationen von Aggregationen

In der aktuellen Version ist es endlich möglich Ausdrücke zu verwenden, die Aggregationen von Aggregationen bilden. Dadurch können Werte, wie z.B. der Durchschnitt der monatlichen Einnahmen gebildet werden.
=Avg(Sum(Fields!Reseller_Sales_Amount.Value, “Month”),”Year”)

OverallPageNumber und OverallTotalPages

Zeigt die Gesamtseitenzahl und die aktuelle Seitenzahl bezogen auf das gesamte Dokument. Im Gegensatz zu den schon bekannten Feldern PageNumber und TotalPages, die die Seitenzahlen abhängig von einer Sequenz angeben(die Seitenzahlen können durch ein PageBreak zurückgesetzt werden). Diese Eigenschaften können nur im Seitenkopf oder –fuß verwendet werden.

RenderFormat

Eine weitere neue, in meinen Augen sehr nützliche Eigenschaft, ist die Globale RenderFormat. Zum Einen kann der Name durch Globals!RenderFormat.Name ermittelt werden und zum Anderen, mit der Expression =Globals!RenderFormat.IsInteractive, ob es sich um ein interaktives Ausgabeformat handelt.

Durch die Möglichkeit das Ausgabeformat zu ermitteln ergeben sich ganz neue Gestaltungsmöglichkeiten. So können für ein Excel-Export z.B. Spalten einer Tabelle ein- oder ausgeblendet werden. Es können Abhängig vom Ausgabeformat komplett unterschiedliche Elemente angezeigt werden.
Bei nicht interaktiven Formaten können, durch den Drilldown versteckte Elemente, sichtbar gemacht werden.

PageName

Endlich können Excelsheets einer Excel-Datei mit Namen versehen werden. Dafür müssen Sie einfach den PageName angeben. Wenn Sie den PageName dynamisch vergeben und den Gruppennamen verwenden für den ein PageBreak existiert, bekommt jedes Excelsheet den Namen der Gruppe.

Mit der Eigenschaft PageBreak/Disabled kann z.B., abhängig vom RenderFormat, der Seitenumbruch deaktiviert werden.

Maps

Was man in früheren Versionen der Reporting Services von Drittanbietern kaufen musste, wurde in der aktuellen Version integriert. Dieses neue Berichtselement dient zur Visualisierung von Daten abhängig von ihrer geographischen Lage. Es stehen eine Vielzahl von Karten in der Kartengalerie zur Verfügung (zurzeit, wohl aus rechtlichen Gründen, nur Karten der USA). Falls Sie eine andere Karte benötigen, können auch ESRI-Shapefiles oder SQL Spatial Datentypen verwendet werden. Sie können hinter Ihre Karte noch eine Bing Karte legen, um die Darstellung noch etwas aufzuwerten. Folgende Kartenvisualisierungen stehen zur Verfügung:

• Basic Map (Basis Karte) – Es werden einfach nur Gebiete angezeigt. So können z.B. Ihre Verkaufsgebiete angezeigt werden.
• Color Analytical Map (Farbanalytische Karte) – Informationen werden durch Farbvariationen hervorgehoben. Z.B. werden die Verkaufszahlen pro Gebiet farblich gekennzeichnet.
• Bubble Map (Blasen Karte) – Informationen werden durch die Größe der Blasen angezeigt. Die Blasen liegen zentriert in den zugehörigen Gebieten.

Report Viewer

Der neue Report Viewer verwendet AJAX für die Seitennavigation und die Interaktivität. So wird beim Öffnen eines Drilldowns die aktuelle Scrollposition beibehalten.
Das Aussehen wurde angepasst und optimiert, um mehr Platz für den Bericht zu haben.

Wir konnten natürlich nur einen kurzen Überblick über die neuen Features der Reporting Services des SQL Server 2008 R2 geben und werden daher in den nächsten Blogeinträgen gezielt und detailliert einzelne der oben genannten Features beschreiben.

Ein Glück, dass in der Datenbank diese Produktkategorien vorhanden sind, denkt sich Herr Schnell und entwickelt die sog. “cascading parameters” – also voneinander abhängige, hierarchisch angeordnete Parameter, deren Auswahl die Wertanzahl folgender Parameter einschränkt.

Zuerst werden im Report drei statt einem Parameter erzeugt. Alle Parameter sind mehrwertig und haben keinen Standardwert.

Dann werden drei Datasets für die Parameter mit folgenden Statements angelegt:

Produktkategorie:

SELECT      ProductCategoryKey, EnglishProductCategoryName FROM  DimProductCategory

Produktunterkategorie:

SELECT        ProductSubcategoryKey, EnglishProductSubcategoryName FROM         DimProductSubcategory

WHERE        (ProductCategoryKey IN (@ProductCategory))

Produkte selbst:

SELECT        EnglishProductName, ProductKey FROM  DimProduct

WHERE        (ProductSubcategoryKey IN (@ProdSubCategory))


Schlussendlich erzeugt Herr Schnell ein Dataset für die Werteabfrage:

SELECT   DimProduct.EnglishProductName, FactInternetSales.OrderQuantity * FactInternetSales.UnitPrice AS OrderVolume, FactInternetSales.Freight FROM DimProduct INNER JOIN FactInternetSales ON DimProduct.ProductKey = FactInternetSales.ProductKey

WHERE  (FactInternetSales.ProductKey IN (@Products))



Weil Herr Schnell auf Standardwerte verzichtet hat, und alle vom vorhergehenden Parameter abhängigen Parameterabfragen ohne eine Auswahl des vorhergehenden Parameters nicht getätigt werden können, sind die Auswahlboxen der nachfolgenden Parameter solange deaktiviert, bis die nötige Vorauswahl von Kategorien oder Unterkategorien abgeschlossen ist.

Nun hat Herr G. Ordnet nur die Produkte zur Auswahl, deren Anzahl er vorher durch die Auswahl an Kategorien eingeschränkt hat – und Herr Schnell noch seinen Job.

Ja und, kann doch jeder: Einfach die Sum-Funktion verwenden:

Stimmt, in den meisten Fällen kommen wir damit zum Ziel.

Was aber, wenn wir noch mehr Informationen anzeigen wollen und dadurch einige Werte doppelt vor kommen, wie z.B. in unserem Beispiel, wenn wir nicht nur die Informationen des Internetverkaufs anzeigen wollen, sondern auch noch die Daten der Wiederverkäufer und zwar landesbezogen. Wenn wir dann die Sum-Funktion verwenden bekommen wir folgende Tabelle:

Wie man erkennen kann sind die Informationen über den Internetverkauf unabhängig vom Land, wodurch in jeder Zeile die Gesamtmenge für diesen einen Reiniger angezeigt wird. Der Wert für die Anzahl, der mit der einfachen Summenfunktion ermittelt wurde, summiert natürlich jede Zeile auf, wodurch wir ein Ergebnis von 6 * 908 = 5448 erhalten. Richtig wäre, wenn auch in der Gruppenzeile 908 stehen würde.

Die Lösung

Wir müssen also in der Summenfunktion prüfen, ob der Wert schon mal aufsummiert wurde. Das können wir erreichen, indem wir im Code eine globale Variable vom Typ String definieren. Jedes neue Produkt wird ans Ende des Strings geschrieben, so dass eine Liste mit den einzelnen Produkten entsteht. Als nächstes wird noch eine Funktion benötigt, die zum Einen den Wert und zum Anderen den Produktnamen übergeben bekommt. Diese überprüft, ob das Produkt schon in der Liste steht, falls dies nicht der Fall ist, wird der Wert zurückgegeben und der Name in der Liste aufgenommen. Falls der Name schon vorhanden ist, wird 0 zurückgegeben, wie der Codeausschnitt zeigt:

private productList as String = String.Empty

function DistinctSum(quantity as Integer, product as String) as Integer
    if productList.IndexOf(product) = -1 then
        productList += product + “, ”
        return quantity
    else
        return 0
    end if
end function


Man muss nur darauf achten, dass die Funktion immer Daten vom gleichen Typ zurück gibt, da es sonst passieren kann, dass die Summe nicht berechnet wird.

Abschließend muss die Gruppenzeile so angepasst werden, dass sie die neu erstellte Funktion verwendet. Leider ist es nicht möglich, einfach das Array mit den Details zu übergeben und die Summe zu berechnen. Daher verwenden wir weiterhin die Summenfunktion, um die Liste der Details einer Gruppe zu durchlaufen. Der Trick ist jetzt  nicht einfach ein Feld eines Datasets einzutragen, sondern inerhalb der Summe die im Code erstellte Funktion zu verwenden, die dann für jedes einzelne Element prüft, ob es schon aufaddiert wurde:

=Sum(code.DistinctSum(Fields!Internet_Order_Quantity.Value,Fields!Product.Value))


Wenn der Bericht, wie beschrieben angepasst wurde sollte jetzt für die Anzahl der Bestellungen, wie in der abschließenden Grafik,  der richtige Wert angezeigt werden.

Eine Migration von Berichten mit Dundas Charts von Reporting Services (RS) 2005 nach 2008 funktioniert dank der neu integrierten Diagrammfunktionalitäten in RS 2008 relativ problemlos.

Einige Konvertierungen mit Diagrammen von Dundas laufen allerdings darauf hinaus, dass sie in RS 2008 als fehlerhaft gemeldet werden und auch nicht ersichtlich ist, woran es liegt. Visual Studio bietet an, den Code zu sichten, aber wer möchte gerne seitenlanges XML durchforsten auf der Suche nach möglichen Fehlern?

Empirisch gelangten wir zu dem Schluss, dass in jedem letztlich fehlerhaften Bericht die Dundas Charts in einer Tabelle eingebettet waren. Nun ist die Lösung ganz einfach: in RS 2005 die Charts aus der Tabelle herausschneiden und im Bericht außerhalb der Tabelle einfügen. Der Bericht muss gespeichert und als nächstes in Visual Studio 2008 erneut geöffnet werden. Dieses Mal war die Konvertierung erfolgreich! Der Entwickler braucht nur noch die Charts wieder in die Tabelle an die ursprüngliche Stelle einfügen und umgeht damit einen zeitaufwendigen Neubau.

Vor einer Konvertierung mit Dundas Charts in einer Tabelle die Diagramme also aus der Tabelle herausnehmen und alles wird gut.