BI 2008 Migration: Reporting Services (3/3)

2. Dezember 2011

Im dritten und letzten Teil meiner Serie BI 2008 Migration möchte ich über Vorgehensweisen zur Reportmigration und Deployment sowie meine Erfahrungen dazu berichten.

Bei SSRS 2008 ergaben sich einige Neuerungen. Die bedeutendste ist sicherlich die Einführung des Tablix-Elementes, das bisherige Tabellen, Matrizen und Listen ersetzt. Tabellen sind die mit Abstand am häufigsten eingesetzten Reportelemente. Diese können auch verschachtelt sein und sollen natürlich auch nach der Migration auf die 2008er Version problemlos funktionieren – in unseren Migrationsprojekten war das erfreulicherweise sehr gut erfüllt. Als Ansätze stehen hierzu Backup/Restore, Visual Studio und Eigenentwicklungen zur Diskussion.

Ähnlich wie Analysis Services verfügt Reporting Services über eine eigene Datenbasis. Diese besteht aus den beiden SQL Server Datenbanken

  • ReportServer
  • ReportServerTempDB

Beide Datenbanken sind voneinander abhängig. Die ReportServer Datenbank enthält alle Reports, Datenquellen, Verzeichnisse, Sicherheitseinstellungen und weitere Objekte in verschlüsselter Form. Damit der Reporting Services Dienst die ReportServer-Datenbank Inhalte entschlüsseln kann, wird ein entsprechender Encryption Key benötigt. Dieser wird mit der Reporting Services 2005 Configuration erstellt. Nach einfachem Backup/Restore der beiden Datenbanken wird auf der Zielumgebung der Encryption Key mittels Reporting Services Configuration Manager 2008 wieder eingelesen. Danach sollten alle Reports 1:1 auf der neuen Umgebung bereit stehen.

Das klingt einfach – ist es auch. Doch meist zieht im Rahmen des Migrationsprojektes auch der Datenbank-Server um, und wir haben ja in den Datenquellen noch überall die Verweise auf die 2005er Datenquellen! Bei wenigen Reports kann der Administrator die Anpassungen manuell über den Berichts-Manager durchführen. Ähnlich verhält es sich mit dem Deployment über Visual Studio 2008, jedoch hat der Entwickler meist keinen Content Manager Zugriff auf produktive Systeme.

Als Alternative zu Backup/Restore der SSRS Datenbanken bieten sich automatisierbare Eigenentwicklungen an, die den Reporting Services Dienst über SOAP ansprechen. Der Entwickler kann damit die RDL-Dateien plus eine aktualisierte Konfigurationsdatei an das operative Team übergeben, welches dann das Deployment automatisiert ausführt.

Für den Report-Entwickler ergeben sich nach meiner Erfahrung keine Probleme. Beim Öffnen eines RS 2005 Projektes mit Visual Studio 2008 wird aber zunächst nur das Projektfile migriert. Die Reports werden in das neue RDL Format überführt, wenn man sie einzeln öffnet und abspeichert.

Fazit: Der Entwickler kann die Reports problemlos nach 2008 überführen. Beim Deployment sehr vieler Reports auf die neuen Server in großen Enterprise-Umgebungen sind automatisierbare Eigenentwicklungen de facto unverzichtbar.