Separate VB app to talk back to a Web Service

  • Thread starter Thread starter Larry Bud
  • Start date Start date
L

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.
 
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
 
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.
Click to expand...

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


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.
Click to expand...

Wouldn't you have to keep hitting the database to see if the file was
created successfully?
 
Back
Top