A chaque fois que j’ai eu à mettre en œuvre les abonnements Reporting Services, je demandais juste à l’admin :

Il me faut du relaying SMTP depuis tel serveur.

Dernièrement, j’ai eu à le faire en partie moi-même et, cerise sur le gâteau, le relaying anonyme (ie. identification implicite via la topologie réseau) n’était pas autorisé.

Pour la configuration SSRS, Fabrice Romelard a très bien expliqué la procédure la semaine dernière.

Le post est ici :

Fabrice Romelard : SQL Server Reporting Services – Activer l’envoi de message nécessitant l’authentification sur le serveur SMTP

Si vous n’avez que 2 mots-clés à retenir, ce sera :

• rsreportserver.config
• SMTPAuthenticate=2

Je vais quand même ajouter mon petit plus

Si votre administrateur Exchange vous dit qu’il ne sait pas ajouter le relaying SMTP sur son Exchange (ou que vous souhaitez briller lors d’un diner geeko-mondain), voici la cmdlet Powershell à exécuter.

New-receiveConnector –Name RelayConnector –usage Custom –Bindings '<ip>:25' –fqdn <serveur>.domain.local –RemoteIPRanges '<ip-start>-<ip-end>;' –AuthMechanism 'None' 

La cmdlet ajoute une interface que vous pouvez configurer pour filtrer les IP, le mode d’authentification, etc.

Quand on génère de rapports sous le format Excel, on a souvent besoin de générer des classeurs, c’est à dire avoir des tableaux ou graphes sur différents onglets.

Pour arriver à ce résultat, il va falloir jouer avec 2 propriétés des éléments de votre rapport :

• Page Break (ie. les sauts de page)
• Page Name

A chaque “page” correspondra un onglet et la propriété PageName sera le nom de l’onglet.

Sur votre tableau / graphe / rectangle, mettez juste un saut de page à la fin (ou au début du suivant). Vous pouvez passer par la fenêtre de configuration.

La propriété PageName est à mettre sur l’élément de la page correspondante et évidemment, vous pouvez utiliser une expression pour rendre cela dynamique (avec le nom d’un groupe par exemple).
A noter qu’elle n’est accessible que par le panneau des propriétés, il n’y a pas d’assistant.

Note : n’hésitez pas à utiliser des Rectangle pour mieux maitriser votre mise en page.

Evidemment, quand on a plusieurs centaines de rapports et des dizaines de DataSources accumulés depuis des années, on oublie vite l’idée de faire le référencement à la main.
Surtout quand on sait qu’on a tout dans la base de données de Reporting Services (ReportServer).

J’ai donc écrit une requête qui pioche les informations dans la table dbo.Catalog.
Attention, il y a:

• du type XML à la toque pour creuser dans la définition RDL
• des CTE pour simplifier (ou presque)

Je ne vais pas m’étendre sur une explication de texte. Sachez juste que la table stocke le RDL (format XML de définition du rapport) dans le champ Content (de type binaire).
Avec quelques requêtes XQuery, on récupère le nom de la source de données partagées ou de la chaîne de connexion (pour de l’embedded).
Evidemment, j’exclue les rapports liés.

WITH 
datasources	AS
(
	SELECT 
		[Path], [Name], ItemId,
		CAST(CAST(content as varbinary(max)) as xml).value('/*:DataSourceDefinition[1]/*:Extension[1]', 'varchar(100)') as Provider,
		CAST(CAST(content as varbinary(max)) as xml).value('/*:DataSourceDefinition[1]/*:ConnectString[1]', 'varchar(100)') as ConnectionString
	FROM dbo.Catalog 
	WHERE [Type] = 5
)
,reports AS
(
	SELECT 
		ItemID, 
		Path, Name
		,CAST(CAST(content as varbinary(max)) as xml) as XmlDefinition
	FROM dbo.Catalog
	WHERE [Type] = 2
)
SELECT
	reports.ItemId, reports.[Path], reports.Name, 
	T2.ds.value('(.//*:DataSourceReference)[1]', 'varchar(200)') as DataSourceReference,
	COALESCE(T2.ds.value('(.//*:ConnectString)[1]', 'varchar(200)'),datasources.ConnectionString) as ConnectionString,
	COALESCE(T2.ds.value('(.//*:DataProvider)[1]', 'varchar(200)'),datasources.Provider) as DataProvider
FROM reports
	CROSS APPLY XmlDefinition.nodes('/*:Report/*:DataSources/*:DataSource') as T2(ds)
LEFT JOIN datasources
	ON datasources.Name = T2.ds.value('(.//*:DataSourceReference)[1]', 'varchar(200)') 

PS : après avoir galéré avec les namespaces qui changent entre les version de Reporting Services et de Report Builder, j’ai opté pour la syntaxe wildcard (ex : .//*:DataSourceReference)

Pas de révolution, on trie les catégories de façon décroissante et on ajoute une seconde série qui est le % cumulé que l’on place sur le second axe (de type pourcentage).

Sachez qu’il existe un moyen très rapide de créer ce type de rapport en configurant juste une propriété.
La série a des propriétés dans CustomAttributes pour gérer des paramétrages particuliers.

Vous avez juste à fixer la propriété ShowColumnAs à la valeur Pareto.

Merci à Hennie

Evidemment, nos utilisateurs sont en droit d’attendre une réponse plus adaptée comme une résolution de cette problématique par exemple.

En SSRS 2005, le problème venait de IIS (qui faisait tourner les rapports) qui “éteint” le processus au bout d’un certain temps. La valeur par défaut étant de 20 minutes, on comprend la latence au démarrage du premier appel. Pour palier le problème, il suffit juste de configurer l’Application Pool.

En SSRS 2008, il n’y a plus IIS donc inutile de l’incrimer. En revanche, Reporting Services implémente la même logique. Il suffit donc de configurer le délai de recyclage. Cela se passe dans le fichier rsreportserver.config (c:\program files\microsoft sql server\<instance>\Reporting Services\ReportServer\).

Au paramètre RecycleTime, il suffit de mettre 0 pour indiquer à SSRS que l’instance ne doit pas s’éteindre.

<service>
  <recycletime>0</recycletime>
</service>

Prochain sujet : le pre-load des rapports pour démarrer encore plus vite .

Le problème rencontré est le suivant :

A l’impression, le format se met par défaut sur Letter (format US)

Pour changer ce comportement, il faut déjà vérifier les paramètres du rapport :

• language = fr-FR
• PageSize = 21 * 29,7cm

Malgré ce paramétrage, il est possible que vos utilisateurs se plaignent que la configuration par défaut se positionne encore sur Letter et non sur A4 à l’impression depuis le Report Manager.

Cela vient de la configuration même du serveur de rapport qui a ce setting by-design. Pour le changer, il faut aller changer la configuration de l’extension de rendu.

Il faut donc aller dans le fichier de configuration de Report Server (C:\Program Files\Microsoft SQL Server\<instanceSSRS>\Reporting Services\ReportServer\rsreportserver.config) et modifier la section Render.

On ajoute juste les settings dans l’extension de rendu RPL (celle utilisée par le serveur pour l’impression) en forçant les hauteurs et largeurs afin de coller à du A4.

Ca donne ça :

 <extension name="RPL" type="Microsoft.ReportingServices.Rendering.RPLRendering.RPLRenderer,Microsoft.ReportingServices.RPLRendering" visible="False" logallexecutionrequests="False">   <configuration>     <deviceinfo>       <outputformat>RPL</outputformat>       <pageheight>297mm</<pageheight>       <pagewidth>210mm</pagewidth>     </deviceinfo>    </configuration> </extension>

Et les rapports liés

Cependant, vous aurez toujours le problème avec un rapport lié.

Cela est dû au fait que, dans la base de données ReportServer, quand l’object LinkedReport est créé, les propriétés du rapport ne sont pas recopiées.

 Select ItemID, Content, LinkSourceID, Property From Catalog

Il existe quelques bugs sur Connect qui expose le problème. Je vous invite à voter pour que la prochaine version corrige le problème .

• https://connect.microsoft.com/SQLServer/feedback/details/651504/ssrs-report-margins-do-not-propagate-to-linked-report-and-other-bugs
• https://connect.microsoft.com/SQLServer/feedback/details/631843/properties-from-report-to-linked-report
• https://connect.microsoft.com/SQLServer/feedback/details/225025/linked-report-makes-a-landscape-report-appear-portrait-in-print-preview
• https://connect.microsoft.com/SQLServer/feedback/details/162129/linked-reports-do-not-honour-page-margins

Ceci est dû au fait que SSRS appelle les WebServices de Sharepoint pour construire le lien final et donc perd du temps au passage.

C’est ce qui est arrivé chez l’un de nos clients et après de nombreux allers-retours avec le support Microsoft, un fix est sorti. Ca fait donc chaud au coeur de savoir que Bewise (et notamment Olivier) a apporté sa pierre à l’édifice avec ce correctif.

Trève de bavardage, les infos sur ce fix. Il est présent dans le CU6 de SQL Server.

- http://support.microsoft.com/kb/2492329/en-us – FIX: Decrease in rendering performance for SQL Server 2008 R2 Reporting Services in SharePoint Integrated mode when a report contains expressions in "Go to URL" actions

Tout cela milite pour l’importance et l’efficacité du support Microsoft et du programme Connect.

Pour dresser cette liste rapidement, il suffit de jouer la requête suivante sur votre base de données ReportServer :

SELECT [Path]

      ,[Description]FROM [ReportServer].[dbo].[Catalog]WHERE Type = 2

Et pourquoi ne pas en faire un rapport

Ci-dessous, la matrice de compatibilité. Pour un rapport réalisé avec tel version d’outil, sur quelle version le déployer…

BIDS : Business Intelligence Development Studio (en fait, juste les template de projet BI pour Visual Studio )

Pour configurer BIDS, il suffit d’aller dans les propriétés du projet :

Et dans la série des liens utiles, les versions Stand Alone de Report Builder sont disponibles à ces adresses :

• Report Builder 3.0
• Report Builder 2.0

J’assurai la partie Reporting Services avec quelques démos sur les nouveautés :

• Nouveau Report Manager
• Report Parts et Report Gallery
• Shared Datasets
• KPI, Sparkline, Databar
• Cartographie

La vidéo se trouve ici :

http://www.microsoft.com/france/vision/mstechdays10/Webcast.aspx?EID=32499E98-3D41-42DA-A396-B6F030697957