我们有一个现有的跨浏览器Web前端收集报告输入(对于非SSRS平台),我们希望看到继续使用SSRS.它包括已经在内部开发的特定于用户界面的UI控件,而没有任何东西可以使用SSRS关闭OOTB.
我们不需要对类型感知控件进行动态渲染 – 虽然我想象RDL可以帮助告诉我们报告采用什么参数(和它们的类型),但是我们确实需要比Report Manager给我们更多的参数.
本质上,我们想定制/替换Report Manager生成的输入收集UI.我们也需要一些小品牌.通过我们自己的ASP.NET应用程序,直接将SSRS Web服务直接与SSRS Web服务器进行接口(外部是我的意思),更简单地报告报告管理器？
我是报道地形的新手,我找不到任何有关这方面的信息.我们正在使用SQL Server 2005报表服务.
解决方法
本质上我们有一个用户与之交互的自定义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.
