具有自定义 Web UI 的 SSRS
是否可以创建自定义 Web 前端来运行 SSRS 报告?
我们有一个现有的跨浏览器 Web 前端,用于收集报告输入(针对非 SSRS 平台),我们希望继续使用 SSRS。它包括已经内部开发的特定于域的 UI 控件,并且没有任何东西可以与 SSRS 相媲美。
我们不需要对类型感知控件进行动态渲染 - 尽管我认为 RDL 可以帮助告诉我们报表采用哪些参数(及其类型) - 但我们确实需要的不仅仅是 报告管理器 为我们提供。
本质上,我们希望自定义/替换由报表管理器生成的输入收集 UI。我们还需要一些品牌推广。完全废弃报表管理器(我的意思是外部)并通过我们自己的 ASP.NET 应用程序直接与 SSRS Web 服务交互会更容易吗?
我是报告领域的新手,我找不到这方面的任何信息。我们正在使用 SQL Server 2005 报告服务。
Is it possible to create a custom Web front-end to run SSRS reports from?
We have an existing cross-browser web front-end for gathering reporting inputs (for a non-SSRS platform) that we would like to see continue with SSRS instead. It includes domain-specific UI controls that have been developed in-house already, and nothing comes close OOTB with SSRS.
We don't need to do dynamic rendering of type-aware controls - although I imagine the RDL can help tell us what parameters (and their type) the report takes - but we do need more than what Report Manager gives us.
Essentially we would like to customize/replace the input-gathering UI generated by Report Manager. We also need some modicum of branding. Would it be easier to scrap Report manager altogether (externally I mean) and interface directly with the SSRS Web Service via our own ASP.NET application?
I am new to the reporting terrain, and I cannot find any information on this. We are using SQL Server 2005 Reporting Services.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
是的,这是可能的。两年多前,当我们对 OOTB 的参数选择不满意时,我们实施了一个与此类似的解决方案。
本质上,我们有一个与用户交互的自定义 ASP.NET 应用程序。当第一页加载时,它会显示可供该用户使用的报告列表(通过 Web 服务从 ASP.NET 应用程序到 SSRS 的通信并使用身份模拟,以便对列表进行安全修剪)。如果自定义 ASP.NET 应用程序与报表服务器位于不同的服务器上,则需要在此处使用 Kerberos。
用户选择报告后,将显示参数选择屏幕(仍在自定义 ASP.NET 应用程序中)。当他们选择参数并单击“生成报告”时,某些 JavaScript 会动态地将每个参数的输入标记添加到 HTML 表单(对用户隐藏),然后向 SSRS Web 服务器执行 HTTP POST。
然后,我们使用 OOTB 报告查看器来显示报告,但它托管在框架中,以便屏幕顶部允许用户包含在自定义 Web 应用程序中。这使他们能够快速返回并更改参数。
我们采取这种方法是因为我们有一个全球性组织,但我们的应用程序是集中托管的 - 我们希望为所有用户提供尽可能好的性能。我们发现,报告查看器的性能相当不错,但 OOTB 附带的 OOTB 参数选择对于高延迟的连接来说非常糟糕 - 大量回发和传输的流量太多。
另一个技巧 - 我们将参数“隐藏”在报告中,以便参数不会显示在报告查看器中。
编辑:我们最初使用 SSRS 2005 进行此操作,最近升级到 SSRS 2008,麻烦最少。
Yes it is possible. We implemented a solution similar to this over 2 years ago when we were dissastified with the parameter selection that came OOTB.
Essentially we have a custom ASP.NET application that users interact with. When the first page loads it presents a list of reports available for that user (communication from the ASP.NET app to SSRS via web services and with identity impersonation so that the list is security trimmed). You'll need to use Kerberos here if the custom ASP.NET app is on a different server to the Report Server.
After the user selects a report the parameter selection screen is shown (still in the custom ASP.NET app). When they select their parameters and click 'Generate Report', some JavaScript adds input tags for each parameter to a HTML Form on the fly (hidden from the user) and then performs a HTTP POST to the SSRS web server.
We are then using the OOTB report viewer to display the report, however it is hosted in frame so that the top of the screen allows the user to be contained to the custom web app. This allows them to quickly go back and change the parameters.
We took this approach because we have a global organisation, but our app was centrally hosted - we wanted performance to be as good as possible for all users. What we found was that the Report Viewer was pretty good performance wise, but that the OOTB Parameter Selection that came OOTB was terrible for connections with high latency - lots of postbacks and far too much traffic transmitted.
One other trick - we made the parameters 'hidden' in the report so that the parameters were not shown in the Report Viewer.
Edit: We intitially did with this with SSRS 2005 and have recently upgraded to SSRS 2008 with minimal hassles.
如果我理解正确,您将需要使用 ReportViewer 来呈现报告。
您可以以任何方式实现输入收集,然后只需将输入作为参数传递给报表:
ReportViewer 是一个可以放到页面上的控件:
我使用这种方法将报表查看器嵌套在母版中包含的页面内页。它允许显示菜单/页眉/页脚。
If I understand you correctly, you'll want to use ReportViewer to render the reports.
You can implement the input gathering in anyway, and then simply pass the inputs to the reports as parameters:
The ReportViewer is a control you can drop onto your page:
I've used this approach to nest the reportviewer inside a page contained in a master page. It allows the menu/header/footer to be displayed.
我们所做的是构建一个 UI 来收集标准和格式(PDF、XLS 等)数据,并使用 SSRS Web 服务 来触发报告。
它使我们能够完全按照您所说的使用您自己的 UI 和 UI 进行操作。围绕报告打造品牌。
您实质上将 RDL 名称和报告参数集合传递给 Web 服务,它将返回 HTML(或您指定的任何格式)。
一些问题包括当您使用 SSRS 的列排序时必须重写 URL,如果您想支持 PDF/Doc/XLS/ 等,则必须设置自己的 mime 类型...
What we've done is built a UI to gather criteria and format (PDF, XLS, etc.) data and used the SSRS Web Services to fire the reports.
It allowed us to do exactly what you're talking about with respect to using your own UI & branding around the reports.
You essentially pass the RDL name and a collection of report parameters to the webservice and it'll return the HTML (or whatever format you specify).
Some gotchas include having to re-write URLs when you use SSRS's column sorting, and having to set your own mime types if you want to support PDF/Doc/XLS/etc...
如果您不想使用 ASP.Net,这是在 SSRS 上创建品牌外观的另一种方法。使用子报告作为标题并在报告之间进行导航。
http://mybinote.blogspot.se /2012/03/branding-ssrs-and-make-it-look-like.html
An alternative way of creating a branded look on SSRS if you don't want to use ASP.Net. Use a sub report as header and have the navigation between reports there.
http://mybinote.blogspot.se/2012/03/branding-ssrs-and-make-it-look-like.html