report viewer vs SOAP API

The situation is... I have written my own little "report viewer" using the
SOAP API, but it renders slower than the report viewer, and paging (i've
tried both the "count <HR> then rerender" method, as well as the hidden text
field method) is a real pain in the butt. The reason why I've gone with the
SOAP API is for security purposes... I don't want to open the report server
for anonymous access... using the SOAP API i can control security calls and
logons.
After reading around a little, I began to wonder if perhaps the report
viewer could be inserted into a page... use URL access, but still have
network credentials (or RS.LogonUser) accompany it to call the report. In
that regard, I keep all the functionality of the report viewer/URL access,
but still have my security.
Has anybody ran into this, or have suggestions how to go about doing this?
Also... isn't there a way--using the report caching options--to have it
render all the pages, and anytime somebody calls the next page via the SOAP
API, it doesn't have to rerender, but rather, grabs a cached copy of that
page?
Thanks,
--
FooberFoober,
I believe your idea of wrapping the report viewer inside an application that
calls RS.LogonUser first and then if it is successful uses URL access would
work fine. I haven't done it exactly that way, but my application requires
the user to logon to it and then once it does I use URL access with an
embedded IE control to render the reports. Using RS.LogonUser would supplant
my custom login code.
I'm not too clear on your second question, but if a report is setup to cache
its execution for a specific period of time, by altering the
properties->execution settings of the report to cache its execution, the
whole report should be cached, not just a page that has been viewed. My
belief is that because you're implementing paging yourself through the
methods you described, you are circumventing the cached report and
rerendering it somehow. I'm not too sure how you're accomplishing this, but
with URL Access I can tell you it isn't a problem. I guess using the SOAP
API is treating the paging differently.
Hope this helps.
- Joel
"Foober" <Foober@.discussions.microsoft.com> wrote in message
news:67CAA176-55FE-4E18-9E64-48C23FBB960B@.microsoft.com...
> The situation is... I have written my own little "report viewer" using the
> SOAP API, but it renders slower than the report viewer, and paging (i've
> tried both the "count <HR> then rerender" method, as well as the hidden
> text
> field method) is a real pain in the butt. The reason why I've gone with
> the
> SOAP API is for security purposes... I don't want to open the report
> server
> for anonymous access... using the SOAP API i can control security calls
> and
> logons.
> After reading around a little, I began to wonder if perhaps the report
> viewer could be inserted into a page... use URL access, but still have
> network credentials (or RS.LogonUser) accompany it to call the report. In
> that regard, I keep all the functionality of the report viewer/URL access,
> but still have my security.
> Has anybody ran into this, or have suggestions how to go about doing this?
> Also... isn't there a way--using the report caching options--to have it
> render all the pages, and anytime somebody calls the next page via the
> SOAP
> API, it doesn't have to rerender, but rather, grabs a cached copy of that
> page?
> Thanks,
> --
> Foober|||Joel,
I'll definitely have to try doing that (RS.LogonUser matched up with RS
reportViewer); just by being able to bounce that off of somebody else gives
me a little more pep towards trying it... of course, i'll leave my own
reportviewer that I wrote intact.
Re: caching... I realize I didn't word that question very well. I went
directly into the report server and went to a particularly large report,
turned on caching directly there, and then ran the report. Report takes ~3
minutes to render (HUGE, nasty query) but after that, takes ~5 seconds from
page to page (using my viewer) and time between pages is negligible using the
built in URL access (under the report server itself). Caching is definitely
a necessity for what i'm doing... so I just need to read up on how to enable
it via the SOAP calls... (reason why I need to do it via SOAP calls is i
wrote a dynamic report generator that generates the RDL and follows through
to publish the report via SOAP calls);
Re: paging in SOAP... unfortunately it doesn't provide an "Easy" way to
determine how many pages a report contains, etc; you actually have to render
the entire report, then count the number of <HR> in the result stream...
that'll give you page count. You then proceed to rerender only page 1 to
start, then let user change pages as necessary. Another method to acquire
pages via the SOAP is to provide an actual textbox or something in the report
header or footer that has GLOBALS!PageNumber (or whatever the heck it is)...
you could render page 1, pull that down, and then let user change pages
afterwards. Either way it is only a difference of microseconds (time to
parse the result stream) between the two methods... especially if caching is
enabled (thanks for the thought concerning that--glad to know it caches
entire report and not only the page that had been viewed).
--
Foober
"Joel Rumerman" wrote:
> Foober,
> I believe your idea of wrapping the report viewer inside an application that
> calls RS.LogonUser first and then if it is successful uses URL access would
> work fine. I haven't done it exactly that way, but my application requires
> the user to logon to it and then once it does I use URL access with an
> embedded IE control to render the reports. Using RS.LogonUser would supplant
> my custom login code.
> I'm not too clear on your second question, but if a report is setup to cache
> its execution for a specific period of time, by altering the
> properties->execution settings of the report to cache its execution, the
> whole report should be cached, not just a page that has been viewed. My
> belief is that because you're implementing paging yourself through the
> methods you described, you are circumventing the cached report and
> rerendering it somehow. I'm not too sure how you're accomplishing this, but
> with URL Access I can tell you it isn't a problem. I guess using the SOAP
> API is treating the paging differently.
> Hope this helps.
> - Joel
>
> "Foober" <Foober@.discussions.microsoft.com> wrote in message
> news:67CAA176-55FE-4E18-9E64-48C23FBB960B@.microsoft.com...
> > The situation is... I have written my own little "report viewer" using the
> > SOAP API, but it renders slower than the report viewer, and paging (i've
> > tried both the "count <HR> then rerender" method, as well as the hidden
> > text
> > field method) is a real pain in the butt. The reason why I've gone with
> > the
> > SOAP API is for security purposes... I don't want to open the report
> > server
> > for anonymous access... using the SOAP API i can control security calls
> > and
> > logons.
> >
> > After reading around a little, I began to wonder if perhaps the report
> > viewer could be inserted into a page... use URL access, but still have
> > network credentials (or RS.LogonUser) accompany it to call the report. In
> > that regard, I keep all the functionality of the report viewer/URL access,
> > but still have my security.
> >
> > Has anybody ran into this, or have suggestions how to go about doing this?
> >
> > Also... isn't there a way--using the report caching options--to have it
> > render all the pages, and anytime somebody calls the next page via the
> > SOAP
> > API, it doesn't have to rerender, but rather, grabs a cached copy of that
> > page?
> >
> > Thanks,
> >
> > --
> > Foober
>
>|||Doesn't seem like I can get that to work... however, the caching made a huge
difference in load time.
I've decided that to cut down on initial render time I'm going to use
snapshotting. Our clients don't need a 100% live report, so I'll write a
little snapshot client that will accept their requests to view a report, run
the CreateReportHistorySnapshot or BeginUpdateReportExecutionSnapshot
method... (probably the latter in order to call it asynchronously) and once
it is completed, return a link to the user that will load it into my report
viewer.
--
Foober
"Foober" wrote:
> Joel,
> I'll definitely have to try doing that (RS.LogonUser matched up with RS
> reportViewer); just by being able to bounce that off of somebody else gives
> me a little more pep towards trying it... of course, i'll leave my own
> reportviewer that I wrote intact.
> Re: caching... I realize I didn't word that question very well. I went
> directly into the report server and went to a particularly large report,
> turned on caching directly there, and then ran the report. Report takes ~3
> minutes to render (HUGE, nasty query) but after that, takes ~5 seconds from
> page to page (using my viewer) and time between pages is negligible using the
> built in URL access (under the report server itself). Caching is definitely
> a necessity for what i'm doing... so I just need to read up on how to enable
> it via the SOAP calls... (reason why I need to do it via SOAP calls is i
> wrote a dynamic report generator that generates the RDL and follows through
> to publish the report via SOAP calls);
> Re: paging in SOAP... unfortunately it doesn't provide an "Easy" way to
> determine how many pages a report contains, etc; you actually have to render
> the entire report, then count the number of <HR> in the result stream...
> that'll give you page count. You then proceed to rerender only page 1 to
> start, then let user change pages as necessary. Another method to acquire
> pages via the SOAP is to provide an actual textbox or something in the report
> header or footer that has GLOBALS!PageNumber (or whatever the heck it is)...
> you could render page 1, pull that down, and then let user change pages
> afterwards. Either way it is only a difference of microseconds (time to
> parse the result stream) between the two methods... especially if caching is
> enabled (thanks for the thought concerning that--glad to know it caches
> entire report and not only the page that had been viewed).
> --
> Foober
>
> "Joel Rumerman" wrote:
> > Foober,
> >
> > I believe your idea of wrapping the report viewer inside an application that
> > calls RS.LogonUser first and then if it is successful uses URL access would
> > work fine. I haven't done it exactly that way, but my application requires
> > the user to logon to it and then once it does I use URL access with an
> > embedded IE control to render the reports. Using RS.LogonUser would supplant
> > my custom login code.
> >
> > I'm not too clear on your second question, but if a report is setup to cache
> > its execution for a specific period of time, by altering the
> > properties->execution settings of the report to cache its execution, the
> > whole report should be cached, not just a page that has been viewed. My
> > belief is that because you're implementing paging yourself through the
> > methods you described, you are circumventing the cached report and
> > rerendering it somehow. I'm not too sure how you're accomplishing this, but
> > with URL Access I can tell you it isn't a problem. I guess using the SOAP
> > API is treating the paging differently.
> >
> > Hope this helps.
> >
> > - Joel
> >
> >
> > "Foober" <Foober@.discussions.microsoft.com> wrote in message
> > news:67CAA176-55FE-4E18-9E64-48C23FBB960B@.microsoft.com...
> > > The situation is... I have written my own little "report viewer" using the
> > > SOAP API, but it renders slower than the report viewer, and paging (i've
> > > tried both the "count <HR> then rerender" method, as well as the hidden
> > > text
> > > field method) is a real pain in the butt. The reason why I've gone with
> > > the
> > > SOAP API is for security purposes... I don't want to open the report
> > > server
> > > for anonymous access... using the SOAP API i can control security calls
> > > and
> > > logons.
> > >
> > > After reading around a little, I began to wonder if perhaps the report
> > > viewer could be inserted into a page... use URL access, but still have
> > > network credentials (or RS.LogonUser) accompany it to call the report. In
> > > that regard, I keep all the functionality of the report viewer/URL access,
> > > but still have my security.
> > >
> > > Has anybody ran into this, or have suggestions how to go about doing this?
> > >
> > > Also... isn't there a way--using the report caching options--to have it
> > > render all the pages, and anytime somebody calls the next page via the
> > > SOAP
> > > API, it doesn't have to rerender, but rather, grabs a cached copy of that
> > > page?
> > >
> > > Thanks,
> > >
> > > --
> > > Foober
> >
> >
> >