RS tiered architecture

I've implemented a solution with application, database and report server on seperate machines. The application is a web app and is Internet facing. What is the best method for executing reports on the RS server that are initiated from the web server? Using URL access requires a login or anonymous access neither of which are desired. Web services works but I loose access to the toolbar. Is there some other way to pull this off where I can let the public access reports and give them access to the toolbar?

Thanks.

Assuming SSRS 2005, the best way will be to use the ASP.NET ReportViewer control since it generates the report on the server and preserves the report interactive features. This article may help to get you started.|||

Thanks.

My understanding is that the Web ReportViewer the report is rendered on the browser not on the server and as such we loose the benefits of server cashing.Does this present a performance issue?

I'll give it a shot.

|||>>

My understanding is that the Web ReportViewer the report is rendered on the browser not on the server and as such we loose the benefits of server cashing. Does this present a performance issue?

<<

Your understanding is incorrect, so it is difficult to gauge the performance issue <s>.

The ReportViewer (web or win) has two modes. One is local, the other is server. But in neither mode would the ReportViewer be rendering in the browser. The difference is whether it is rendering in the RS server or in your web server tier, and also which tier is preparing the data.

In your case it looks like you are going to be using server mode, which means the reports come from the RS server tier and the data is prepared there as well, of course. The web tier hosts the control, requests report pages from the RS server, and sends the full page content for sending to the browser

In local mode the web tier hosts the control *and* the rendering code for the report page(s) without delegating to an RS server.

In local mode, if you are talking about report caching rather than web page, yes you are not going to have it because that is provided by the RS server. But if you are in server mode the RS server is going to decide to deliver a cached report (snapshot) based on its own settings, regardless of the client, as far as I know.

HTH,

>L<

PS To be strictly accurate, in all cases and all types of content a browser also "renders" a web page for display. But how a browser chooses to "render" what a reportcontrol sends is more like how it renders an image downloaded from a server. It doesn't "render" the JPG in the sense of creating it.

|||

My understanding is that the Web ReportViewer the report is rendered on the browser not on the server and as such we loose the benefits of server cashing. Does this present a performance issue?

We need to clarify what you mean by "render" and "server caching". The VS.NET 2005 ASP.NET report viewer is no much different than an ASP.NET page. It submits report requests to the Report Server on behalf of the user, gets the report presentation, and streams it to the client. This all happens on the server side. As with any web application, it is the browser who renders the HTML content to the user but it is a thin client. As far as the "server caching" I have no idea what benefits you are referring to.

RS Server Architecture

I am working on a POC (proof of concept) for reporting services.
My question is can RS be depoyed using the following architecture.
Web Server.
App Server.
DB Server.
The web server can only see the app server, and the app server can see both
the web and db server. Would like the actual report generation to be
performed on the app server.
Can RS be depoyed in this manner?
Thank you in advance for any information.
--
Robert HillIf you assume that the App Server is what you are calling RS then the answer
is yes. Your web app can use either url integration or it can use web
services. The new webform control (2.0 framework) that comes wtih VS 2005
(it does not ship with RS) is the easiest and best way to integrate. Under
the covers it uses web services.
RS does the rendering at the server.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"RobertHillEDS" <rwhill@.nospam.nospam> wrote in message
news:DAFA3AF6-9291-4E2A-9038-3F57F2BB85B7@.microsoft.com...
> I am working on a POC (proof of concept) for reporting services.
> My question is can RS be depoyed using the following architecture.
> Web Server.
> App Server.
> DB Server.
> The web server can only see the app server, and the app server can see
> both
> the web and db server. Would like the actual report generation to be
> performed on the app server.
> Can RS be depoyed in this manner?
> Thank you in advance for any information.
>
> --
> Robert Hill|||Hi Robert,
I agree with Bruce. As for SQLserver reporting service, the report server
can be installed on a different server from the datasource used to generate
report. So for your scenario, the Application Server should be the one
which host the ReportServer, and DB server should be the one which provide
data for generaring report. And as for webserver, it just need to access
the Report server(applicaion server) to query the Reports (through url or
webservice).
#Planning a Reporting Services Deployment
http://msdn2.microsoft.com/en-us/library/ms157293(SQL.90).aspx
Regards,
Steven Cheng
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

RS architecture

Hi ,
I need to use a RS 2005 on a web farm ,
displaing the reports as part of my web application,
connected to asingle SS 2005.
Do I need to install RS on every web server ?
Do I need to pay for every instanse installed on the web farm ?
10x,
Liz.For a web farm you need license for SQL Server Enterprise Edition on each
web server and on the SQL Server Database. RS is a asp.net application that
uses SQL Server database as an object store (all reports, subscriptions, etc
are stored in the database).
Now, if you want to have a web farm that uses either URL integration or web
services to integrate with RS then you could have your application on a web
farm and RS on a single server (either the server with your database or on a
IIS box). Anyplace RS is installed you need a license. If you integrated
your app with RS and you have RS installed only on a single box then you
could use either standard or enterprise edition. A good link to check out:
http://www.microsoft.com/technet/prodtechnol/sql/2000/technologies/rptsvcs.mspx
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Liz Matyas" <lizmts@.mail.com> wrote in message
news:eAG6BAcpFHA.2444@.tk2msftngp13.phx.gbl...
> Hi ,
> I need to use a RS 2005 on a web farm ,
> displaing the reports as part of my web application,
> connected to asingle SS 2005.
> Do I need to install RS on every web server ?
> Do I need to pay for every instanse installed on the web farm ?
> 10x,
> Liz.
>

RS and J2EE High Level Architecture Question

I am looking for a tool that allows me to generate lists, mailmerged letters
and reports from a J2EE application. Are there strong reasons in favor or
against RS, specifically in regard to integrating via the Web Service API?
Can I wrap RS in a J2EE-based interface and stream reports through the
application server, as opposed to exposing the RS management interface to
the end users?
Thanks for your input.Christian,
> I am looking for a tool that allows me to generate lists, mailmerged
letters
> and reports from a J2EE application. Are there strong reasons in favor or
> against RS, specifically in regard to integrating via the Web Service API?
This is one of the RS strongest points because with RS reports are
web-enabled by default. In other words, once you deploy your report to the
report catalog there is nothing you have to do to expose it over the web.
> Can I wrap RS in a J2EE-based interface and stream reports through the
> application server, as opposed to exposing the RS management interface to
> the end users?
You bet. You can generate RS reports on the server-side your J2EE
application by calling the RS Render SOAP API. In addtion, the Report Server
supports URL addressibility where a HTTP-GET request is generated on the
client side of the application. You should carefully evaluate both SOAP and
URL addressibility to find out which one meets your app requirements better.
--
Hope this helps.
----
Teo Lachev, MCSD, MCT
Author: "Microsoft Reporting Services in Action"
Publisher website: http://www.manning.com/lachev
Buy it from Amazon.com: http://shrinkster.com/eq
Home page and blog: http://www.prologika.com/
----
"Christian Donner" <stealthcdonner@.stealthmolecular.comremovestealth> wrote
in message news:esT536OlEHA.3760@.TK2MSFTNGP12.phx.gbl...
> I am looking for a tool that allows me to generate lists, mailmerged
letters
> and reports from a J2EE application. Are there strong reasons in favor or
> against RS, specifically in regard to integrating via the Web Service API?
> Can I wrap RS in a J2EE-based interface and stream reports through the
> application server, as opposed to exposing the RS management interface to
> the end users?
> Thanks for your input.
>|||Christian,
I don't see why not. the web service methods for RS include the RENDER
method. Since this is a SOAP call which returns a byte array (representing
the rendered report) RS is client agnostic. have at it.
hope this helps.
dlr
"Christian Donner" <stealthcdonner@.stealthmolecular.comremovestealth> wrote
in message news:esT536OlEHA.3760@.TK2MSFTNGP12.phx.gbl...
> I am looking for a tool that allows me to generate lists, mailmerged
letters
> and reports from a J2EE application. Are there strong reasons in favor or
> against RS, specifically in regard to integrating via the Web Service API?
> Can I wrap RS in a J2EE-based interface and stream reports through the
> application server, as opposed to exposing the RS management interface to
> the end users?
> Thanks for your input.
>