Separate VB app to talk back to a Web Service

Customer sends XML data to our Web Service. Web Service does some
data transformation and puts the data into a special format that
another application uses. That data is in a file.
This other application continuously polls a folder for these data
files and processes them. It eventually creates a PDF out of the
data with a unique file name.
Web service needs to know when this other application is done
processing this data so I can send a URL of the created PDF back to
customer.
What would be the best way to do this? I don't want to sit there and
poll a folder for the output file, as we may have up to 40,000
requests / day.look at windows workflow or sqlserver broker services.
-- bruce (sqlwork.com)
"Larry Bud" wrote:

> Customer sends XML data to our Web Service. Web Service does some
> data transformation and puts the data into a special format that
> another application uses. That data is in a file.
> This other application continuously polls a folder for these data
> files and processes them. It eventually creates a PDF out of the
> data with a unique file name.
> Web service needs to know when this other application is done
> processing this data so I can send a URL of the created PDF back to
> customer.
> What would be the best way to do this? I don't want to sit there and
> poll a folder for the output file, as we may have up to 40,000
> requests / day.
>
In addition to Bruce's suggestion - what I have done in the past is have a
method that allows the client to check a DB value against each created file
using the number they are given on submission. For me it was word files
converted to PDF and a succesful creation triggered a DB update and then
stored the output URL - cleaning up after a 24 hour period. Because its
only a small request with a single return value it was cheap for the client
to check the webservice for a success flag and then get the URL. This
didn't massively impact throughput and could be hosted on a different app
server entirely.
Regards
John Timney (MVP)
http://www.johntimney.com
http://www.johntimney.com/blog
"bruce barker" <brucebarker@.discussions.microsoft.com> wrote in message
news:7BFFAD45-86AA-48B5-AFB1-42DB21056491@.microsoft.com...
> look at windows workflow or sqlserver broker services.
> -- bruce (sqlwork.com)
>
> "Larry Bud" wrote:
>
On Feb 11, 4:37=A0pm, "John Timney \(MVP\)"
<xyz_j...@.timney.eclipse.co.uk> wrote:
> In addition to Bruce's suggestion - what I have done in the past is have a=[/color
]
> method that allows the client to check a DB value against each created fil=[/color
]
e
> using the number they are given on submission. =A0For me it was word files=[/color
]
> converted to PDF and a succesful creation triggered a DB update and then
> stored the output URL - cleaning up after a 24 hour period. =A0Because its=[/color
]
> only a small request with a single return value it was cheap for the clien=[/color
]
t
> to check the webservice for a success flag and then get the URL. =A0This
> didn't massively impact throughput and could be hosted on a different app
> server entirely.
>
Wouldn't you have to keep hitting the database to see if the file was
created successfully?
Yes, but it doesn't have to be the same database, or even the same database
server!
Regards
John Timney (MVP)
http://www.johntimney.com
http://www.johntimney.com/blog
"Larry Bud" <larrybud2002@.yahoo.com> wrote in message
news:e2449b23-38af-4876-88c5-df0f10f77278@.s8g2000prg.googlegroups.com...
On Feb 11, 4:37 pm, "John Timney \(MVP\)"
<xyz_j...@.timney.eclipse.co.uk> wrote:
> In addition to Bruce's suggestion - what I have done in the past is have a
> method that allows the client to check a DB value against each created
> file
> using the number they are given on submission. For me it was word files
> converted to PDF and a succesful creation triggered a DB update and then
> stored the output URL - cleaning up after a 24 hour period. Because its
> only a small request with a single return value it was cheap for the
> client
> to check the webservice for a success flag and then get the URL. This
> didn't massively impact throughput and could be hosted on a different app
> server entirely.
>
Wouldn't you have to keep hitting the database to see if the file was
created successfully?