Separate VB app to talk back to a Web Service

[Larry Bud]

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.

 

[bruce barker]

look at windows workflow or sqlserver broker services.

-- bruce (sqlwork.com)

 

[John Timney \(MVP\)]

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

 

[Larry Bud]

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?

 

[John Timney \(MVP\)]

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

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?