JPo*_*Pot 13 asp.net reportingservices-2005 reporting-services
是否可以创建自定义Web前端来运行SSRS报告？
我们有一个现有的跨浏览器的web前端收集报告输入(非SSRS平台),我们会希望看到继续SSRS代替.它包括已经在内部开发的特定于域的UI控件,并且没有任何关于OOTB与SSRS的关系.
我们不需要对类型感知控件进行动态渲染 - 尽管我认为RDL可以帮助告诉我们报告所采用的参数(及其类型) - 但我们确实需要的不仅仅是Report Manager为我们提供的参数.
基本上我们想要自定义/替换Report Manager生成的输入收集UI.我们还需要一些品牌.是否更容易废弃报表管理器(外部我的意思)并通过我们自己的ASP.NET应用程序直接与SSRS Web服务接口？
我是报道地形的新手,我找不到任何相关信息.我们正在使用SQL Server 2005 Reporting Services.
对的,这是可能的.我们在2年前实施了类似于此的解决方案,当时我们对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.