70-467 · Question #14
You are designing a strategy for an enterprise reporting solution that uses SQL Server Reporting Services (SSRS). Many of the SSRS reports will use common utilities and functions, including the…
The correct answer is D. Create an assembly that contains formatting properties and code. For enterprise SSRS solutions needing centralized, easily updatable shared code and formatting, deploying a custom .NET assembly to the SSRS server is the correct strategy. All reports reference the single assembly, so updating and redeploying it propagates changes everywhere…
Question
You are designing a strategy for an enterprise reporting solution that uses SQL Server Reporting Services (SSRS). Many of the SSRS reports will use common utilities and functions, including the following:
- Report utility functions and business logic in code
- Standardized report formatting properties such as fonts and colors
for report branding Formatting may change and new functions may be added as the reporting solution evolves. You need to create a strategy for deploying the formatting and code across the entire enterprise reporting solution. You must also ensure that reports can be easily updated to reflect formatting and function changes. What should you do? (More than one answer choice may achieve the goal. Select the BEST answer.)
Options
- ACreate a report as a template. Apply standardized formatting to the template.
- BBuild a web service that retrieves formatting properties and runs code.
- CStore the formatting properties and code in database objects.
- DCreate an assembly that contains formatting properties and code.
How the community answered
(36 responses)- A6% (2)
- B22% (8)
- C11% (4)
- D61% (22)
Why each option
For enterprise SSRS solutions needing centralized, easily updatable shared code and formatting, deploying a custom .NET assembly to the SSRS server is the correct strategy. All reports reference the single assembly, so updating and redeploying it propagates changes everywhere automatically.
A report template applies standardized formatting only at report creation time; changes to the template after reports have been created do not propagate to existing reports, requiring manual updates across the entire report catalog.
A web service introduces network latency on every report render, creates an external dependency that becomes a single point of failure, and requires significantly more development and infrastructure effort than a compiled assembly.
Storing formatting properties and code in database objects forces reports to query the database at render time for styling values, adds query overhead, and mixes presentation logic with data storage in a way that is harder to maintain than a versioned assembly.
A custom assembly deployed to the SSRS report server can be referenced by all reports via report properties, making utility functions and formatting constants available solution-wide from one compiled artifact. When formatting or business logic changes, only the assembly needs to be updated and redeployed - no individual report modifications are required - directly satisfying the easy-update requirement. This is the standard SSRS mechanism for sharing code across reports in an enterprise deployment.
Concept tested: SSRS custom assembly deployment for shared enterprise code
Source: https://learn.microsoft.com/en-us/sql/reporting-services/custom-assemblies/using-custom-assemblies-with-reports
Topics
Community Discussion
No community discussion yet for this question.