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