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.

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.

Nach der Installation dürften sich die Nutzer folgender Ansichten im Internet Explorer erfreuen:

Abb. 1: Fehlermeldung beim Aufruf des Berichts Managers

Abb. 2: Fehlermeldung beim Aufruf des Berichtsservers

Voraussetzung ist natürlich ein Reporting Services Dienst der vor dem SP1 korrekt lief. Sollte das nicht der Fall sein, könnte folgender Artikel weiterhelfen Wie Installieren von SQL Server 2005 Reporting Services auf einem Windows Vista-based Computer.

Nun zur Behebung des Problems

Die Ursache ist die Abschaltung der Funktionalitäten für ‚Skripte’ und ‚Ausführen’ für die Site des Berichtsservers. Mit folgenden Schritten sollten die geliebten Berichte wieder erreichbar sein:

1. Klicken Sie in der Systemsteuerung auf System und Verwaltung.
2. Klicken Sie auf Verwaltung.
3. Doppelklicken Sie auf Internetinformationsdienste-Manager.
4. Klicken Sie in dem Dialogfeld User Account Control auf Fortsetzen.
5. Öffnen Sie im linken Bereich der Verbindungen den Baum soweit bis Sie auf ReportServer treffen. Im Normalfall sollte das folgender Pfad sein <Servername> -> Sites -> Default Web Site -> ReportServer.
6. Klicken Sie auf ReportServer.
7. Im mittleren Bereich auf Handlerzuordnungen doppelklicken.

    


8. Hier liegt die Ursache des Ganzen, das deaktivierte ISAPI Modul. Diese muss nun wieder aktiviert werde. Im Bereich Aktionen auf Featureberechtigungen bearbeiten klicken.

    


9. Im Dialog Featureberechtigungen Skript aktivieren und mit OK bestätigen.
10. Nochmals im Bereich Aktionen auf Featureberechtigungen bearbeiten klicken.
11. Im Dialog Featureberechtigungen Ausführen aktivieren und mit OK bestätigen. Das ISAPI Modul sollte nun wieder aktiviert sein.
12. Anschließend muss jetzt noch der IIS neu gestartet werden. Dazu im linken Bereich Verbindungen den Server auswählen und im rechten Bereich Aktionen auf Neu starten klicken.

Viel Spaß beim weiteren Arbeiten mit Reporting Services 2005, Ihr Jörg Knuth.

Um so verwirrter guckt dann dieser Controller, wenn man ihm versucht zu erklären, dass das mit den Reporting Services nicht möglich ist. Zum Glück stimmt das auch nicht ganz.

Mit Hilfe von Dundas Chart für Reporting Services ist dies fast so einfach wie in Excel. Der Haken liegt dann nur noch bei den Lizenzkosten.

Aber auch ohne zusätzliche Software sind einfache Trendlinien mit SSRS möglich, denn genaugenommen ist das ja nichts weiter als ein “bisschen” Mathematik.

Grundlage für die oben gezeigte gerade Trendlinie ist die einfache lineare Regression. Und dafür gibt es in MDX Funktionen, die sich nutzen lassen, um diesen Trend zu berechnen. Die Grundlagen dieser MDX Funktionen und der mathematischen Konzepte dahinter hat Mosha bereits vor einigen Jahren in seinem Blog veröffentlicht.

Nun aber zurück zum eigentlichen Thema, das Erzeugen der oben gezeigten Grafik in den Reporting Services:

Mit dem Assistenten erstellen wir einen neuen Bericht auf den Adventure Works Cube aus der Adventure Works DW Datenbank. Nach dem Umschalten des Designmodes kommt für das Dataset folgender Quellcode zum Vorschein:

SELECT

NON EMPTY { [Measures].[Sales Amount] } ON COLUMNS,

NON EMPTY { ([Date].[Calendar].[Calendar Quarter].ALLMEMBERS) } ON ROWS

FROM [Adventure Works]

Um später die Lesbarkeit des Codes zu erhöhen, erstellen wir uns als erstes ein Set, dass alle Quartale enthält, die wir auch der Achse anzeigen wollen.

WITH

SET

myMonate AS ([Date].[Calendar].[Calendar Quarter].ALLMEMBERS)

Nun müssen wir für jede Zeile den Wert ermitteln, der für das jeweilige Quartal auf der Trendlinie liegt. Dazu nutzen wir die MDX-Funktion: LinRegPoint.

LinRegPoint(Slice_Expression_x, Set_Expression, Numeric_Expression_y [ ,Numeric_Expression_x ] )

Slice_Expression_x: Hier wird ein numerischer Ausdruck erwartet, der als x-Wert genutzt werden soll. Da die Quartale nicht numerisch sind, können wir diese hier nicht direkt benutzen. Wir können jedoch die RANK-Funktion nutzen, um die Position des jeweiligen Quartales auf der X-Achse zu ermitteln. Diesen merken wir uns in einem eigenen Member:

MEMBER

Measures.myX AS Rank([Date].[Calendar].CurrentMember, [Date].[Calendar].CURRENTMEMBER.LEVEL.MEMBERS)

Set_Expression: An dieser Stelle wird definiert, über welches Set der Trend-Wert berechnet werden soll. Hier könnte z.B. die letzten 10 Perioden gewählt werden, oder ein Set, das von Berichtsparametern abhängig ist, genutzt werden. In unserem Fall wollen wir einfach alle Quartale zur Berechnung heranziehen und nutzen deshalb das eben erstellte Set myMonate.

Numeric_Expression_y: Der gewünschte y-Wert ist einleuchtend: [Measures].[Sales Amount], dafür machen wir das ganze ja schließlich.

Numeric_Expression_x: Hier wird die Formel erwartet, die genutzt werden kann, um die x-Werte der anderen Punkte “vorauszusagen”. Wir können hier einfach den gleichen Ausdruck benutzen, wie bei Slice_Expression_x: myX

Wenn wir das alles einsetzen und dem Ganzen dann noch einen Namen geben, erhalten wir folgenden Ausdruck:

MEMBER

Measures.[Sales Trend] AS LinRegPoint(Measures.myX, myMonate, [Measures].[Sales Amount], Measures.myX)

Unsere Quelle für das Berichts-Dataset sieht nun also folgendermaßen aus:

WITH

SET

myMonate AS ([Date].[Calendar].[Calendar Quarter].ALLMEMBERS)

MEMBER

Measures.myX AS Rank([Date].[Calendar].CurrentMember, [Date].[Calendar].CURRENTMEMBER.LEVEL.MEMBERS)

MEMBER

Measures.[Sales Trend] AS LinRegPoint(Measures.myX, myMonate, [Measures].[Sales Amount], Measures.myX)

SELECT

NON EMPTY { [Measures].[Sales Amount],Measures.[Sales Trend] } ON COLUMNS,

NON EMPTY {myMonate} ON ROWS

FROM [Adventure Works]

Und wenn wir das ganze als Grafik anzeigen, dann sieht das in etwa so aus:

Wenn das unseren Controller nicht glücklich macht

An dieser Stelle sollte noch angemerkt werden, dass die LinRegPoint-Funktion mit Rekursion arbeitet und damit, vor allem bei vielen Zeit-Werten, eine potentielle Performancebremse ist. Wer also beim Darstellen des Trends mit diesem Verfahren an die Grenzen stößt, der sollte dann doch mal Dundas ausprobieren, oder auf die nächste Version des SQL Servers (2008) hoffen.