0 comments
Business Intelligence 
Eén van de meest in het oog springende nieuwe features in Reporting Services 2008 R2 is de Report Part Gallery. Hiermee kun je onderdelen van rapporten delen met andere rapportbouwers. Deze onderdelen heten Report Parts en ze zijn zichtbaar in de Report Part Gallery in Report Builder 3.0.
Als ontwikkelaar ben je snel geneigd met een ontwikkelaarsbril te kijken naar deze nieuwe feature. Je krijgt dan vragen als ‘wat gebeurt er wanneer ik een Report Part wijzig’ en ‘hoe kan ik alle rapporten waarin een bepaald Report Part gebruikt is updaten’. Maar helaas, dit is geen feature bedoeld voor ontwikkelaars of beheerders. Het is een feature louter en alleen bedoeld voor power users die met Report Builder zo snel mogelijk een rapport willen maken samengesteld uit al bestaande onderdelen. Je zult dan ook vergeefs zoeken naar mogelijkheden centraal een update uit te voeren. Ook in de API’s kan ik geen mogelijkheden daartoe vinden.
Report Part Gallery is alleen beschikbaar in Report Builder 3.0. Vanuit Report Designer kun je Report Parts deployen, maar er is geen enkele mogelijkheid ze daar te gebruiken. Wanneer de gebruiker van Report Builder 3.0 een rapport maakt op basis van één of meer Report Parts, wordt de definitie van dat onderdeel als het ware gekopieerd in het rapport. Er ontstaat zo een nieuwe instance van het Report Part en alleen binnen dat rapport ligt vast dat het onderdeel daarin gebruikt is.
Laten we eens kijken wat er eigenlijk achter de schermen gebeurt. In onderstaand voorbeeld zie je hoe ik een Report Part vanuit Report Designer deploy naar de server. Het onderdeel dat we bekijken is het Adventure Works logo. Zodra je van een onderdeel van een rapport zegt dat je het als Report Part wilt publiceren, wordt er een ComponentID voor gegenereerd. Dit is een unieke GUID.
Bij het deployen van het rapport, wordt voor ieder nieuw Report Part in het rapport een entry toegevoegd in de tabel Catalog in de ReportServer database. In dezelfde tabel staan ook alle rapporten. Een Report Part heeft een eigen type (9) én de ComponentID die je ook in Report Designer zag.
Ga je dit Report Part gebruiken in een Report Builder rapport, dan zie je ook in de Report Definition Language van dit rapport deze ComponentID weer terug.
Verderop zie je echter ook ‘gewoon’ de definitie van het Report Part terugkomen. Er is dus een kopie van het Report Part in het rapport opgenomen en alleen binnen dit rapport is de verwijzing naar dat Report Part vastgelegd. Niet op de server. Omdat het een kopie betreft, kun je deze binnen het rapport naar wens veranderen.
Wanneer het rapport, na wijziging van het Report Part, weer wordt geopend in Report Builder, zal Report Builder melden dat er een Report Part gewijzigd is. Dat kan omdat in de RDL de verwijzing naar het Report Part is vastgelegd, evenals de laaste SyncDate. In de Catalog tabel kun je eenvoudig zien of de ModifiedDate van het part met de juiste ComponentID nieuwer is dan de SyncDate van het part in de RDL. Als maker van het rapport, kun je kiezen: de wijziging accepteren of weigeren.
Dit is allemaal geheel in lijn met hoe Microsoft Report Parts positioneert. Als middel voor de eindgebruiker om snel ‘grab-and-go’ reports te maken. Gebruik je daarin Report Parts? Prima. Wil je een wijziging in een Report Part meenemen in jouw rapport? Prima. Maar de workflow is dat jij dat als maker van het rapport beslist. Niet vanuit beheer.
Ik zou wel een paar verbeterpunten kunnen noemen voor deze feature. Zoals Microsoft hem nu neerzet, is hij bruikbaar voor power users. Maar waarom niet het beste uit twee werelden combineren? Wanneer je van een Report Part aan zou kunnen geven of je die bij gebruik ervan kunt wijzigen én er wordt ook op de server vastgelegd waar een Report Part gebruikt wordt, zou je wel centraal een update door moeten kunnen voeren van een Report Part. Al is het goed stil te staan bij de mogelijke complicaties daarvan… Wat denk je dat er in bovenstaand voorbeeld gebeurt met rapporten waarin het Adventure Works logo wordt gebruikt en de huisstijlist bepaald dat het logo voortaan verticaal georiënteerd moet worden…?