Multiple page requests with NetWebClient

[Devan]

I have a small Clarion applet which runs a NetWebClient Fetch() against a web service.  Sometime only one page, but often 3 or 4 pages depending on the results of a SQL query.

I have the Fetch()es in a loop, i.e.

Code: [Select]

Loop
  Next(SQLFile)
  If Error() Then Break.
  ThisNetWebClient.Fetch('http://mywebservice.com/getarecord?id=' & SQL:SomeID)
End
I thought with asynchronous Fetch()es, that the ThisNetWebClient.PageReceived will be called each time a Fetch() returned some data, but it doesn't seem to be doing that.  So far, I trace multiple Fetch() calls going out, but only one PageReceived() being called - for the first Fetch() only.

What is the best way to queue up multiple concurrent Fetch() calls?

Thanks,
Devan

[Bruce]

Hi Devan,

the comms is indeed asyncronous, but that doesn't mean that you have multiple connections - and so the "pipe" between you and the server can only handle one request/response at a time.

In other words you
a) do 1 Fetch
b) in PageReceived you get the Page and
c) trigger the next fetch

b1) you also need to handle errorTrap in case the page is not received for some reason. You can choose the next FETCH, retry the same one, or abandon the whole loop, whatever you prefer.

With regard to the SQL, I'd probably pre-load the requests into a Queue, then "getting the next fetch" is as simple as reading the next queue record. Of course if you have a sequence number you could just do a NEXT on the SQL table to get the next item to fetch.

As I recall a good example of this is the WebClient "WebStrain" example. That loads a bunch of fetches into a queue (from a TPS table) and then executes them one at a time.

cheers
Bruce

[Devan]

Thanks Bruce,

I did as you suggested and split the routine up into two parts, i.e. populate a queue from the SQL database, then run a process to 'run down' the queue and perform the fetches.

It still needed some deft timing to ensure that the processing didn't start a race condition.  I tried using the ThisNetWebClient.Busy property within the loop to see if the previous Fetch() was still working but didn't seem to have much luck with that, so I ended up creating a local BYTE variable called LOC:Busy which I set upon calling the Fetch() routine and cleared when ErrorTrap() and PageReceived() were called, and that seemed to work fine for my needs.

Cheers,
Devan