[quoted text, click to view]
What I do not understand is why a sample code like that isn't to be =
found somwhere as a standard example on MSDN.
<<

I have a lot of opinions on that subject, not all of them printable =
<shrug>. =20

FWIW a young developer I work with came up against something similar =
(not SSIS-related) and I just sat down and wrote him an appropriate =
example. I couldn't find anything that would clearly show him what he =
needed to do to move up from COM-based http requests to .NET objects in =
a simple, direct, manner. =20

That's why I said you were lucky -- I needed to do (most of) it anyway =
<g>. =20

The work I've been doing integrating SSIS and reporting actually has =
nothing to do with URL access or pulling reports through SSIS, but I =
thought that, given your request, it might be interesting to see if it =
was possible, because I might add that in to the SSIS package I'm =
writing. And it *was* indeed possible, so thank you for bringing it up =
as a challenge!

[quoted text, click to view]
I will test this later today, or possibly during the weekend.
<<

Before you test, I did find later (in a different context, while working =
out that example) that I may have had to do that silly cast because I =
was using System.Net.HttpWebRequest and using System.Net.WebRequest =
would have worked much better. So you may want to look at that.

[quoted text, click to view]
Taking this a few more steps forward, I could possibly stop printing =
invoices from the accounting software, and just have it write "invoice =
printing requests" to a table SSIS will be watching and then delivering =
to a print queue. That's where I start having some doubts about if SSIS =
will deliver the printouts quick enough.=20
<<

I can't comment on the performance issues here because performance would =
vary by too many different parameters in any scenario. In your specific =
scenario I am not even sure this is the correct way to handle the base =
requirement, which AFAICS is: how to add an external reporting layer =
onto a legacy application. =20

I realize that you are comfortable with SSIS and that's a factor in its =
favor, but here it really sounds as though you have a hammer so =
everything looks like a nail <sigh>.

As a general architecture question, here is what concerns me: you have a =
"push" from the DOS application into the table, and then a "pull" by =
SSIS to read the table and trigger the printing. That approach =
generally doesn't make sense. It almost always makes more sense to have =
the DOS application directly trigger the behavior on user demand, even =
though the DOS application is not directly handling the printing and =
reporting chores. It is both more efficient and more like expected =
behavior from the user's POV while working in the DOS application -- =
even though the DOS application is actually spinning off or triggering =
another process.

If you think it is impossible to do what I just said... think again <g>. =
Obviously I have no idea what the capabilities of the "integrated =
programming language" in your accounting software are. But I have done =
this numerous ways, using DOS applications as the client triggering such =
activity, and would be happy to discuss this with you if you want to =
discuss it -- I don't think this forum is the correct place, but you can =
e-mail me and we could brainstorm.

[quoted text, click to view]



[quoted text, click to view]
Thank you so very, very much Lisa !

Yes, lucky me that you were so eager and interested. This does save me =
a lot of time and I really appreciate it. Don't hesitate to email me if =
you think I can help YOU with something. I'm in over my head in SSIS =
these days, so if you are having any problems it is always a chance that =
I can contribute something.=20

I will test this later today, or possibly during the weekend.

What I do not understand is why a sample code like that isn't to be =
found somwhere as a standard example on MSDN. This is something that =
expands the usage of SSIS quite a bit, at least in my case.

And while we are at it, I'd be curious to have your opinion about =
possibly extended usage of something like you have been writing for me.

In my company there is a legacy accounting software. Included in the =
software is an integrated programming language that have been used =
heavily to change the software to suit our needs. The programming =
language is quite ok for programs, forms and database access but in =
regards to reporting it's terrible. All development done in a DOS =
application and no GUI so while users require more fancy reports, the =
development team has more problems :-)

On top of that, printing from the application is slow and clients hate =
waiting for a slow printout of invoices etc.

So, using the idea behind your solution, my idea is to have SSIS watch =
for printing requests of various forms. The first that comes to mind is =
sending transactions overview to customers. Using your solution will =
handle that nicely, writing a request to some table SSIS will be =
watching with enough parameters to find everything needed and deliver =
the report printout to the customer.

Taking this a few more steps forward, I could possibly stop printing =
invoices from the accounting software, and just have it write "invoice =
printing requests" to a table SSIS will be watching and then delivering =
to a print queue. That's where I start having some doubts about if SSIS =
will deliver the printouts quick enough.=20

Any comments on those thoughts ?

And Lisa, thanks again for your help.

Regards,
Palli

[quoted text, click to view]
OK, it wasn't that bad. And lucky you I've been kinda working on =
integrating SSIS with some reporting stuff anyway... so I was curious =
about how this would work...

Below is some sample script that you could use inside SSIS**. Just =
remember that, where I've hard-coded a sample report URL , you will =
actually be building it up based on package variables. And that =
includes your params. =20

** Caveat: it works as-is in SSIS except that I had to do something =
that looked really silly as an explicit cast, and I've included that as =
a comment because I'm not sure it's necessary.
Notice how the URL includes a query string representing the path of =
the report and two options (in this case, rs:Command and rs:Format). =
These are arguments that belong to the report engine, and you can see it =
because of their rs: prefix. =20

But if you had (say) a parameter for this report such as =
PopulationGreaterThan (the report in my example URL is based on a table =
of cities in the MySQL standard sample database), you could add this =
right onto the end of the URL:

[quoted text, click to view]
completes the printout all the way to the printer, without the user =
having to press the Print button, then I can see no problem with going =
that way

Did you actually plan to have the SSIS task print the documents? Or was =
saving them out to PDF or Excel the end of the line for SSIS? If the =
latter, then you're imposing an extra burden on the DOS app compared to =
SSIS -- although I still say it's possible <g>.

[quoted text, click to view]
Hi Lisa and thanks again for your precious input!

Who knows what I'll do in the next few days. Maybe I'll even email you =
some brainstorming material !

[quoted text, click to view]

I think your'e absolutely right on this one. A quite many things do =
look a lot like nails these days :-)

[quoted text, click to view]
though the DOS application is not directly handling the printing >and =
reporting chores. It is both more efficient and more like expected =
behavior from the user's POV while working in the DOS application ->- =
even though the DOS application is actually spinning off or triggering =
another process.

This is possible from the legacy application and I will give it a go =
and try it out. Allthough I'm quite familiar with SSIS, I'm not that =
deep into SSRS yet, but I suppose if you can have the legacy app invoke =
a process that completes the printout all the way to the printer, =
without the user having to press the Print button, then I can see no =
problem with going that way. I suppose that is possible and even simple =
to do in SSRS, so I'm in for some testing the next few weeks.

Best regards and thanks,

Hi Lisa and thanks again for your precious input!

Who knows what I'll do in the next few days. Maybe I'll even email you =
some brainstorming material !

[quoted text, click to view]

I think your'e absolutely right on this one. A quite many things do look =
a lot like nails these days :-)

[quoted text, click to view]
a "push" from the DOS application into the table, and then a "pull" >by =
SSIS to read the table and trigger the printing. That approach =
generally doesn't make sense. It almost always makes more sense to have =
[quoted text, click to view]
though the DOS application is not directly handling the printing >and =
reporting chores. It is both more efficient and more like expected =
behavior from the user's POV while working in the DOS application ->- =
even though the DOS application is actually spinning off or triggering =
another process.

This is possible from the legacy application and I will give it a go and =
try it out. Allthough I'm quite familiar with SSIS, I'm not that deep =
into SSRS yet, but I suppose if you can have the legacy app invoke a =
process that completes the printout all the way to the printer, without =
the user having to press the Print button, then I can see no problem =
with going that way. I suppose that is possible and even simple to do in =
SSRS, so I'm in for some testing the next few weeks.

Best regards and thanks,

[quoted text, click to view]
was saving them out to PDF or Excel the end of the line for SSIS? If =
the >latter, then you're imposing an extra burden on the DOS app =
compared to SSIS -- although I still say it's possible <g>.

Well.... I hadn't reached that milestone yet as I was just receiving the =
code from you <g>

And, as I had the hammer, I must confess that the thought crossed my =
mind as the process seemed to nail-ish from afar <g>

The end-of-the-line for my first project will actually be email, which =
is easy to do in SSIS. What I thought of for the later steps, having the =
hammer and all, was to let SSIS deliver (probably) PDF to some kind of a =
spool folder. But, I hadn't thought it all through through, so maybe =
it's something better left alone.=20

The bottom line is that if it will save time on the client, and speed =
things up, then every available and doable possibility will be =
considered.

[quoted text, click to view]
things up, then every available and doable possibility will be =
considered.

That's the spirit <s>. (Although I did max(rofl) at your nail-ish line =
<g>.)

Look, seriously: Email shouldn't be much of a challenge either way. =20

You have two appropriate avenues, even in your first, e-mail only, =
project:

*1 -- set up an architecture that will fit as many channels as you =
expect to need, so that the mechanism of pulling the report on-demand =
doesn't have to be in multiple places. Allow that architecture to get =
instructions associating one or more target channels with a run. Only =
build one channel, e-mail, for now.

*2 -- create a component that does the actual pull-on-demand as a =
separate library DLL, which you can call from SSIS and from the process =
that will be called directly by your app later on. Only worry about =
invoking it from SSIS for your first project, but ascertain that you =
have put this core functionality somewhere where multiple clients can =
access it.

Which choice you make is largely a matter of development style. I would =
probably do up-front research and work leaning towards choice #1. You, =
having SSIS as your hammer and concentrating on this first project, =
might lean toward choice #2.

Either choice will get you there eventually. There is also a third =
choice, which I would hope you see is entirely inappropriate considering =
that you already know you have additional goals:

*0 -- just embed the code in SSIS and worry about architecture later. =
Sure, the code I gave you (please do check out the WebRequest thing I =
mentioned in my followup) will get you to that point. But if you =
already know you have to use that functionality for multiple goals, =
you're creating an extra burden for yourself later. This is because, =
when you re-build it properly, you are going to want to retro-fit that =
first project to use it later. That means re-developing it. And if you =
*don't* retrofit, you are leaving a maintenance burden to others who =
have to manage and maintain the multiple channels later on.

[quoted text, click to view]
was saving them out to PDF or Excel the end of the line for SSIS? If =
the >latter, then you're imposing an extra burden on the DOS app =
compared to SSIS -- although I still say it's possible <g>.

Well.... I hadn't reached that milestone yet as I was just receiving =
the code from you <g>

And, as I had the hammer, I must confess that the thought crossed my =
mind as the process seemed to nail-ish from afar <g>

The end-of-the-line for my first project will actually be email, which =
is easy to do in SSIS. What I thought of for the later steps, having the =
hammer and all, was to let SSIS deliver (probably) PDF to some kind of a =
spool folder. But, I hadn't thought it all through through, so maybe =
it's something better left alone.=20

The bottom line is that if it will save time on the client, and speed =
things up, then every available and doable possibility will be =
considered.

Hi Lisa !

Well, I've done my homework :-)

I've tested and made a few modifications to your sample. Your original =
sample is at the bottom. One of your notes about the sample was:

[quoted text, click to view]
working out that example) that I may have had to do that silly cast =
because I >was using System.Net.HttpWebRequest and using =
System.Net.WebRequest would have worked much better. So you may want to =
look >at that.

These three links seem to indicate that a mixture of HttpWebRequest and =
WebRequest is the way to go:
http://msdn2.microsoft.com/en-us/library/system.net.httpwebrequest(vs.71)=
..aspx
http://msdn2.microsoft.com/en-us/library/system.net.httpwebrequest.proxy(=
VS.71).aspx
http://www.c-sharpcorner.com/UploadFile/sushil%20saini/ReadingWebPageSour=
ces11262005020220AM/ReadingWebPageSources.aspx

So, my line reads approximately like the following:
Dim ox As System.Net.HttpWebRequest =3D _
CType( System.Net.WebRequest.Create _
("http://localhost/reportserver/?/Report+Project1/TestCity&rs:Command=3DR=
ender&rs:format=3DEXCEL") ,HttpWebRequest)

That is, using WebRequest to create the request and casting it to =
HttpWebRequest afterwards. Any comments ?

My second minor change relates to HTTP proxy problems. Our inhouse setup =
requires us to use automatic proxy configuration script reference in our =
browsers, and .NET doesn't like that at all! It just throws Protocol =
violation errors. So, instead of having to adjust the proxy on the =
machine running SSIS, I just reset it in the script, bypassing the proxy =
for this process only. The protocol violations are only thrown if there =
is an auto proxy script, so I could just as well make it go directly to =
the proxy server, but that's an overkill in my particular case as =
everything is on the LAN, no proxy needed. The following line bypasses =
the proxy:
ox.Proxy =3D GlobalProxySelection.GetEmptyWebProxy

My final change is regarding the output format. In my case the report =
will be emailed, so my first thought was a PDF format. Running my test =
report 10 times (via refresh button) in a browser, took approx 30 =
seconds. Rendering the same report via SSIS to PDF and emailing each (10 =
emails) took approx 3 minutes.

By changing the output format to MHTML, and have the output file name =
"x.mhtml" and emailing as an attachment is noticeably faster. 20 reports =
+ emailing each (20 emails) all took less than one minute.

My conclution is that MHTML is the way to go. Will I have any problems =
with missing links for a user receiving the report outside of the LAN ?

Palli





The original code sample follows:
***************************************************************

' substitute the following line when working in SSIS=20
' for the instantiation of the HttpWebRequest object you see below:

' Dim ox As System.Net.HttpWebRequest =3D =
CType(System.Net.HttpWebRequest.Create _
' =
("http://localhost/reportserver/?/Report+Project1/TestCity&rs:Command=3DR=
ender&rs:format=3DEXCEL"), HttpWebRequest)

Dim ox As System.Net.HttpWebRequest =3D _
System.Net.HttpWebRequest.Create _
("http://localhost/reportserver/?/Report+Project1/TestCity&rs:Command=3DR=
ender&rs:format=3DEXCEL")=20
'just substitute &rs:Format=3DPDF for &rs:format=3DEXCEL in the line =
above for a PDF

ox.UseDefaultCredentials =3D True
' the line above may not work for you, you may have to provide =
credential information with more work

Dim oy As System.Net.HttpWebResponse =3D ox.GetResponse()
Dim raw As System.IO.FileStream =3D New =
System.IO.FileStream("c:\temp\x.xls", IO.FileMode.Create)
' for a PDF, change the extension in the line above, along with changing =
its
' name and folder based on (obviously!) more package vars
Dim buffer(1024) As Byte
Dim rs As System.IO.Stream =3D oy.GetResponseStream()
Dim read As Integer =3D rs.Read(buffer, 0, buffer.Length)
While (read > 0)
raw.Write(buffer, 0, read)
read =3D rs.Read(buffer, 0, buffer.Length)
End While
oy.Close()
raw.Close()
raw.Dispose()
rs.Close()
rs.Dispose()
oy =3D Nothing
ox =3D Nothing
raw =3D Nothing

I love it when a plan comes together <g>. Thanks for coming back here =
with your results.

Thank you for the links -- which match pretty much what my tests =
indicate. (Except for the c-sharpcorner one -- did you send a list to =
the wrong article by any chance?)

On the proxy situation... you would definitely know this better than I =
but I really thought setting up the appropriate credentials was the way =
to go on that. =20

As far as the Protocol violation errors go... could you maybe have set =
the WebPermission to handle this? See requirements note at the end of =
the =
http://msdn2.microsoft.com/en-us/library/system.net.httpwebrequest.proxy(=
VS.71).aspx page you sent me to and refer to =
http://msdn2.microsoft.com/en-us/library/system.net.webpermission(VS.71).=
aspx.

Re MHTML: I have some concerns about your using this format to users =
without knowing what their capabilities are. I agree that RS PDF output =
is slow, and it is also somewhat inflexible (we'll have to take that =
discussion off-line). But MHTML is sort of weird as far as standards =
go. While I think MS proposed it as a standard, it isn't universally =
accepted. Firefox will only "open" an MHTML file by invoking IE and =
Safari probably won't even do that. So you have to know your audience.

Additionally, an MHTML file is probably going to include javascript, =
which means that some of your recipients may have the attachment excised =
as potentially unsafe by their mail server, even if that javascript is =
stripped (empty) functions only, which might be the case in the MHTML. =
You will need to provide some sort of disclaimer and "what to do" =
message in the Comments for this email for cases where that happens.

This does not directly answer your question about whether or not the =
recipients will have "missing links" outside the LAN. The best way to =
find out is to open one of your MHTMLs and View Source. Are there image =
links? What do they look like? Etc.

In short: while PDF is slower, it is also probably safer... unless you =
offer a recipient preference field permitting users to opt for PDF if =
they find that MHTML does not work for them.

HTH,

[quoted text, click to view]



[quoted text, click to view]
Hi Lisa !

Well, I've done my homework :-)

I've tested and made a few modifications to your sample. Your original =
sample is at the bottom. One of your notes about the sample was:

[quoted text, click to view]
working out that example) that I may have had to do that silly cast =
because I >was using System.Net.HttpWebRequest and using =
System.Net.WebRequest would have worked much better. So you may want to =
look >at that.

These three links seem to indicate that a mixture of HttpWebRequest =
and WebRequest is the way to go:
=
http://msdn2.microsoft.com/en-us/library/system.net.httpwebrequest(vs.71)=
..aspx
=
http://msdn2.microsoft.com/en-us/library/system.net.httpwebrequest.proxy(=
VS.71).aspx
=
http://www.c-sharpcorner.com/UploadFile/sushil%20saini/ReadingWebPageSour=
ces11262005020220AM/ReadingWebPageSources.aspx

So, my line reads approximately like the following:
Dim ox As System.Net.HttpWebRequest =3D _
CType( System.Net.WebRequest.Create _
=
("http://localhost/reportserver/?/Report+Project1/TestCity&rs:Command=3DR=
ender&rs:format=3DEXCEL") ,HttpWebRequest)

That is, using WebRequest to create the request and casting it to =
HttpWebRequest afterwards. Any comments ?

My second minor change relates to HTTP proxy problems. Our inhouse =
setup requires us to use automatic proxy configuration script reference =
in our browsers, and .NET doesn't like that at all! It just throws =
Protocol violation errors. So, instead of having to adjust the proxy on =
the machine running SSIS, I just reset it in the script, bypassing the =
proxy for this process only. The protocol violations are only thrown if =
there is an auto proxy script, so I could just as well make it go =
directly to the proxy server, but that's an overkill in my particular =
case as everything is on the LAN, no proxy needed. The following line =
bypasses the proxy:
ox.Proxy =3D GlobalProxySelection.GetEmptyWebProxy

My final change is regarding the output format. In my case the report =
will be emailed, so my first thought was a PDF format. Running my test =
report 10 times (via refresh button) in a browser, took approx 30 =
seconds. Rendering the same report via SSIS to PDF and emailing each (10 =
emails) took approx 3 minutes.

By changing the output format to MHTML, and have the output file name =
"x.mhtml" and emailing as an attachment is noticeably faster. 20 reports =
+ emailing each (20 emails) all took less than one minute.

My conclution is that MHTML is the way to go. Will I have any problems =
with missing links for a user receiving the report outside of the LAN ?

Palli





The original code sample follows:
***************************************************************

' substitute the following line when working in SSIS=20
' for the instantiation of the HttpWebRequest object you see below:

' Dim ox As System.Net.HttpWebRequest =3D =
CType(System.Net.HttpWebRequest.Create _
' =
("http://localhost/reportserver/?/Report+Project1/TestCity&rs:Command=3DR=
ender&rs:format=3DEXCEL"), HttpWebRequest)

Dim ox As System.Net.HttpWebRequest =3D _
System.Net.HttpWebRequest.Create _
=
("http://localhost/reportserver/?/Report+Project1/TestCity&rs:Command=3DR=
ender&rs:format=3DEXCEL")=20
'just substitute &rs:Format=3DPDF for &rs:format=3DEXCEL in the line =
above for a PDF

ox.UseDefaultCredentials =3D True
' the line above may not work for you, you may have to provide =
credential information with more work

Dim oy As System.Net.HttpWebResponse =3D ox.GetResponse()
Dim raw As System.IO.FileStream =3D New =
System.IO.FileStream("c:\temp\x.xls", IO.FileMode.Create)
' for a PDF, change the extension in the line above, along with =
changing its
' name and folder based on (obviously!) more package vars
Dim buffer(1024) As Byte
Dim rs As System.IO.Stream =3D oy.GetResponseStream()
Dim read As Integer =3D rs.Read(buffer, 0, buffer.Length)
While (read > 0)
raw.Write(buffer, 0, read)
read =3D rs.Read(buffer, 0, buffer.Length)
End While
oy.Close()
raw.Close()
raw.Dispose()
rs.Close()
rs.Dispose()
oy =3D Nothing
ox =3D Nothing
raw =3D Nothing

Don't mess too much with the proxy stuff if you have something working =
for you. (As you know, I'm betting that you won't end up doing it =
through SSIS anyway, so ... besides this is definitely not my area, I =
don't want to lead you astray.)

If you're running a proxy server on Linux though... you gotta take that =
MHTML standard-or-not thing seriously. It would be different if your =
company, or your expected report consumers, were a Microsoft-only shop, =
but clearly they're not <g>.

Have fun,

[quoted text, click to view]


[quoted text, click to view]
Hi Lisa !

It was just a small part of the c-sharpcorner link had me thinking of =
TypeCasting I ended up doing:
[quoted text, click to view]

Reading this part of the link made me look further in that direction, =
and then I found the msdn articles. Otherwise it wasn't related, sorry =
:-)

Thanks for your notes on MHTML. I obviously will have to look further =
into the audience thing. Probably PDF is the way to go for the long run, =
and will be far less problamatic... allthough slow.

Regarding the proxy issue, I will have to experiment later with that. =
I did have some issues on my laptop deploying reports to the report =
server and giving the same protocol violation errors, which were solved =
by changing the proxy settings not to use autoproxy script. The proxy =
server runs on Linux (Squid) and doesn't have integrated security =
available and authentication is required by company policy. It does seem =
that the authentication by itself is ok, as the SSIS to SSRS works by =
deactivating the auto proxy and just have the proxy servers ip address =
in the settings. I found some links about turning of the auto proxy and =
that seamed to work, so I didn't look further on that occation.

Palli

[quoted text, click to view]
I love it when a plan comes together <g>. Thanks for coming back =
here with your results.

Thank you for the links -- which match pretty much what my tests =
indicate. (Except for the c-sharpcorner one -- did you send a list to =
the wrong article by any chance?)

On the proxy situation... you would definitely know this better than =
I but I really thought setting up the appropriate credentials was the =
way to go on that. =20

As far as the Protocol violation errors go... could you maybe have =
set the WebPermission to handle this? See requirements note at the end =
of the =
http://msdn2.microsoft.com/en-us/library/system.net.httpwebrequest.proxy(=
VS.71).aspx page you sent me to and refer to =
http://msdn2.microsoft.com/en-us/library/system.net.webpermission(VS.71).=
aspx.

Re MHTML: I have some concerns about your using this format to =
users without knowing what their capabilities are. I agree that RS PDF =
output is slow, and it is also somewhat inflexible (we'll have to take =
that discussion off-line). But MHTML is sort of weird as far as =
standards go. While I think MS proposed it as a standard, it isn't =
universally accepted. Firefox will only "open" an MHTML file by =
invoking IE and Safari probably won't even do that. So you have to =
know your audience.

Additionally, an MHTML file is probably going to include javascript, =
which means that some of your recipients may have the attachment excised =
as potentially unsafe by their mail server, even if that javascript is =
stripped (empty) functions only, which might be the case in the MHTML. =
You will need to provide some sort of disclaimer and "what to do" =
message in the Comments for this email for cases where that happens.

This does not directly answer your question about whether or not the =
recipients will have "missing links" outside the LAN. The best way to =
find out is to open one of your MHTMLs and View Source. Are there image =
links? What do they look like? Etc.

In short: while PDF is slower, it is also probably safer... unless =
you offer a recipient preference field permitting users to opt for PDF =
if they find that MHTML does not work for them.

HTH,

[quoted text, click to view]



[quoted text, click to view]
Hi Lisa !

Well, I've done my homework :-)

I've tested and made a few modifications to your sample. Your =
original sample is at the bottom. One of your notes about the sample =
was:

[quoted text, click to view]
working out that example) that I may have had to do that silly cast =
because I >was using System.Net.HttpWebRequest and using =
System.Net.WebRequest would have worked much better. So you may want to =
look >at that.

These three links seem to indicate that a mixture of =
HttpWebRequest and WebRequest is the way to go:
=
http://msdn2.microsoft.com/en-us/library/system.net.httpwebrequest(vs.71)=
..aspx
=
http://msdn2.microsoft.com/en-us/library/system.net.httpwebrequest.proxy(=
VS.71).aspx
=
http://www.c-sharpcorner.com/UploadFile/sushil%20saini/ReadingWebPageSour=
ces11262005020220AM/ReadingWebPageSources.aspx

So, my line reads approximately like the following:
Dim ox As System.Net.HttpWebRequest =3D _
CType( System.Net.WebRequest.Create _
=
("http://localhost/reportserver/?/Report+Project1/TestCity&rs:Command=3DR=
ender&rs:format=3DEXCEL") ,HttpWebRequest)

That is, using WebRequest to create the request and casting it to =
HttpWebRequest afterwards. Any comments ?

My second minor change relates to HTTP proxy problems. Our inhouse =
setup requires us to use automatic proxy configuration script reference =
in our browsers, and .NET doesn't like that at all! It just throws =
Protocol violation errors. So, instead of having to adjust the proxy on =
the machine running SSIS, I just reset it in the script, bypassing the =
proxy for this process only. The protocol violations are only thrown if =
there is an auto proxy script, so I could just as well make it go =
directly to the proxy server, but that's an overkill in my particular =
case as everything is on the LAN, no proxy needed. The following line =
bypasses the proxy:
ox.Proxy =3D GlobalProxySelection.GetEmptyWebProxy

My final change is regarding the output format. In my case the =
report will be emailed, so my first thought was a PDF format. Running my =

Hi Lisa !

It was just a small part of the c-sharpcorner link had me thinking of =
TypeCasting I ended up doing:
[quoted text, click to view]

Reading this part of the link made me look further in that direction, =
and then I found the msdn articles. Otherwise it wasn't related, sorry =
:-)

Thanks for your notes on MHTML. I obviously will have to look further =
into the audience thing. Probably PDF is the way to go for the long run, =
and will be far less problamatic... allthough slow.

Regarding the proxy issue, I will have to experiment later with that. I =
did have some issues on my laptop deploying reports to the report server =
and giving the same protocol violation errors, which were solved by =
changing the proxy settings not to use autoproxy script. The proxy =
server runs on Linux (Squid) and doesn't have integrated security =
available and authentication is required by company policy. It does seem =
that the authentication by itself is ok, as the SSIS to SSRS works by =
deactivating the auto proxy and just have the proxy servers ip address =
in the settings. I found some links about turning of the auto proxy and =
that seamed to work, so I didn't look further on that occation.

Palli

[quoted text, click to view]
I love it when a plan comes together <g>. Thanks for coming back here =
with your results.

Thank you for the links -- which match pretty much what my tests =
indicate. (Except for the c-sharpcorner one -- did you send a list to =
the wrong article by any chance?)

On the proxy situation... you would definitely know this better than I =
but I really thought setting up the appropriate credentials was the way =
to go on that. =20

As far as the Protocol violation errors go... could you maybe have =
set the WebPermission to handle this? See requirements note at the end =
of the =
http://msdn2.microsoft.com/en-us/library/system.net.httpwebrequest.proxy(=
VS.71).aspx page you sent me to and refer to =
http://msdn2.microsoft.com/en-us/library/system.net.webpermission(VS.71).=
aspx.

Re MHTML: I have some concerns about your using this format to users =
without knowing what their capabilities are. I agree that RS PDF output =
is slow, and it is also somewhat inflexible (we'll have to take that =
discussion off-line). But MHTML is sort of weird as far as standards =
go. While I think MS proposed it as a standard, it isn't universally =
accepted. Firefox will only "open" an MHTML file by invoking IE and =
Safari probably won't even do that. So you have to know your audience.

Additionally, an MHTML file is probably going to include javascript, =
which means that some of your recipients may have the attachment excised =
as potentially unsafe by their mail server, even if that javascript is =
stripped (empty) functions only, which might be the case in the MHTML. =
You will need to provide some sort of disclaimer and "what to do" =
message in the Comments for this email for cases where that happens.

This does not directly answer your question about whether or not the =
recipients will have "missing links" outside the LAN. The best way to =
find out is to open one of your MHTMLs and View Source. Are there image =
links? What do they look like? Etc.

In short: while PDF is slower, it is also probably safer... unless you =
offer a recipient preference field permitting users to opt for PDF if =
they find that MHTML does not work for them.

HTH,

[quoted text, click to view]



[quoted text, click to view]
Hi Lisa !

Well, I've done my homework :-)

I've tested and made a few modifications to your sample. Your =
original sample is at the bottom. One of your notes about the sample =
was:

[quoted text, click to view]
working out that example) that I may have had to do that silly cast =
because I >was using System.Net.HttpWebRequest and using =
System.Net.WebRequest would have worked much better. So you may want to =
look >at that.

These three links seem to indicate that a mixture of HttpWebRequest =
and WebRequest is the way to go:
=
http://msdn2.microsoft.com/en-us/library/system.net.httpwebrequest(vs.71)=
..aspx
=
http://msdn2.microsoft.com/en-us/library/system.net.httpwebrequest.proxy(=
VS.71).aspx
=
http://www.c-sharpcorner.com/UploadFile/sushil%20saini/ReadingWebPageSour=
ces11262005020220AM/ReadingWebPageSources.aspx

So, my line reads approximately like the following:
Dim ox As System.Net.HttpWebRequest =3D _
CType( System.Net.WebRequest.Create _
=
("http://localhost/reportserver/?/Report+Project1/TestCity&rs:Command=3DR=
ender&rs:format=3DEXCEL") ,HttpWebRequest)

That is, using WebRequest to create the request and casting it to =
HttpWebRequest afterwards. Any comments ?

My second minor change relates to HTTP proxy problems. Our inhouse =
setup requires us to use automatic proxy configuration script reference =
in our browsers, and .NET doesn't like that at all! It just throws =
Protocol violation errors. So, instead of having to adjust the proxy on =
the machine running SSIS, I just reset it in the script, bypassing the =
proxy for this process only. The protocol violations are only thrown if =
there is an auto proxy script, so I could just as well make it go =
directly to the proxy server, but that's an overkill in my particular =
case as everything is on the LAN, no proxy needed. The following line =
bypasses the proxy:
ox.Proxy =3D GlobalProxySelection.GetEmptyWebProxy

My final change is regarding the output format. In my case the =
report will be emailed, so my first thought was a PDF format. Running my =
test report 10 times (via refresh button) in a browser, took approx 30 =
seconds. Rendering the same report via SSIS to PDF and emailing each (10 =
emails) took approx 3 minutes.

By changing the output format to MHTML, and have the output file =
name "x.mhtml" and emailing as an attachment is noticeably faster. 20 =
reports + emailing each (20 emails) all took less than one minute.

My conclution is that MHTML is the way to go. Will I have any =
problems with missing links for a user receiving the report outside of =
the LAN ?

Palli





The original code sample follows:
***************************************************************

' substitute the following line when working in SSIS=20