Das Problem

Manchmal steht man vor einem Problem welches sich mit SSRS-„Bordmitteln“ nicht lösen lässt. So ein Problem ergab sich vor einiger Zeit bei einem Kunden.
Es sollte eine ziemlich komplizierte Anzeigelogik für einen Report entwickelt werden. Nach einigen Versuchen mit verschachtelten IIF()-Funktionen, kam mir der Gedanke, dass dies nicht der Weisheit letzter Schluss sein konnte.

Die Lösung

Aus SSIS kannte ich schon die Skript-Tasks und so etwas Ähnliches schwebte mir auch für meinen Report vor.
Glücklicherweise gibt es in SSRS tatsächlich die Möglichkeit, eigenen Code zu schreiben oder auch eine externe DLL im Report zu referenzieren.
Da der Code sehr umfangreich war, entschied ich mich dafür, den Code nicht direkt in den Report einzubinden, sondern als Referenz zu verlinken.
Im folgenden Beispiel habe ich das weitere Vorgehen mit einem stark vereinfachten Beispiel dargestellt:

Zunächst muss ein Visual Basic-Klassenbibliotheks-Projekt angelegt werden.
Dieses Projekt bekommt dann eine neue Klasse namens „ColorClass“ mit folgendem Inhalt:

Imports Microsoft.VisualBasic
 
Public Class ColorClass
    Public Shared Function COLORNUMBER(ByVal profit As Decimal) As String
        Dim st As String
        If profit >= 1000 Then
            st = "LimeGreen"
        ElseIf profit >= 500 Then
            st = "Gold"
        Else
            st = "Red"
        End If
        Return st
    End Function
End Class

Dann wird das Projekt in den Projekteigenschaften mit einem Zertifikat signiert:

Weiterhin muss das Projekt auf .NET-Version 3.0 umgestellt werden

Als nächstes wird als Sicherheits-Feature noch das Assembly-Attribute „AllowPartialTrustedCaller“ gesetzt.

Die kompilierte DLL muss im nächsten Schritt sowohl in das bin-Verzeichnis des Report-Servers als auch den GAC kopiert werden.
Das Bin-Verzeichnis des Report-Server 2008 befindet sich unter: „%programfiles%\Microsoft SQL Server\MSRS10_50.REPORTSERVICES\Reporting Services\ReportServer\bin“:

 

Die Assembly wird folgendermaßen über die Konsole in den GAC kopiert:
„gacutil.exe -i SSRSCustomAssembly.dll“

Im Report wird dann eine Tabelle erstellt die mit Testdaten gefüllt wird.
In den Report-Properties muss dann unter „References“ mit „Add“ eine neue Referenz auf die soeben kopierte DLL erstellt werden:

In diesem Beispiel habe ich dann in die Color-Eigenschaft meiner Tabellen-Zelle für Aufwände die Vordergrund-Farbe durch die DLL setzen lassen, dazu wird folgender Code in die „Color„-Eigenschaft der Zelle eingefügt:
=SSRSCustomAssemblyVB.ColorClass.COLORNUMBER(Fields!Aufwand.Value)

Das Endergebnis sieht dann folgendesmaßen aus:

Fazit

Auch wenn der gewählte Ansatz im Beispiel viel zu schwergewichtig ist, zeigt er, was für neue Möglichkeiten Custom-Assemblies eröffnen.
Die Entscheidung ob auf Custom-Assemblies zurückgegriffen wird, sollte jeder Entwickler aber sorgfältig abwägen und dabei auch den erhöhten Deployment-Aufwand bedenken.
Teilweise weigern sich Infrastruktur-Abteilungen „wildfremde“ Assemblies auf den Report-Server zu deployen, sodass der Ansatz dann direkt ausscheidet.
Eine Möglichkeit wäre dann auf eingebetten Code im Report zurückzugreifen.

Für die Reports, die ich bei meinem Kunden erstellen sollte, sorgte dieses Vorgehen für einen sehr strukturierten, gut wartbaren Code.

Links

[1] http://www.sql-server-performance.com/2011/custom-code-ssrs-reporting-services-2008-r2