[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ftpapi] Asynchronous XML Request



Peder,

I've read what you mention before that it can be "more" than one job.
When you mention that, I already thought that I should have controller job, so the job submitted not more than the limit number that have been setup before (so the it wont consume too much CPU).
I only curious if there is another way, so then I only need 2 jobs (1 for sending, 1 for process the reply message).
Because with only 2 jobs (separating function between sending and process reply), it will be much convenient that way.

Thanks and Regards,
Randy

Pada Kamis, 6 Februari 2020 15.17.19 WIB, Udesen, Peder <peder.udesen@xxxxxxxxxxxxxxx> menulis:


It looks like you didn’t see that I wrote that one or more programs could listen to the request data queue.

My solution 25 years ago was that I had a program that controlled how many unprocessed entries remained
in the request data queue. If more than a certain amount remained then the controlling program simply

submitted a new job to process the entries. Of course there were a limit so you didn’t have 1000s of jobs submitted.

After some time the processing job ended if there were nothing to do. No need to take up unnecessary resources.

The controlling job checked to see if the submitted job were still active.

Thus it knew if more jobs could be submitted or a message should be sent to the operator/HelpDesk to check if
something is wrong.

 

I think with this solution your program can send a lot of requests, continue processing and then at some point check to
see if a response has been received for these requests. Of course you need some way to match the request and response
but that is fairly simple using either an universally unique identifier (UUID) or job information and a timestamp or another
thing that is unique.

Mvh/Peder

 

Fra: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx <ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx> På vegne af Randy Susanto
Sendt: 6. februar 2020 07:14
Til: FTPAPI/HTTPAPI mailing list <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Emne: Re: [Ftpapi] Asynchronous XML Request

 

Peder,

 

Thanks for your suggestion.

But there is still a job that need to do both send request and wait respond.

If I want to have more than one message request at one time, it only can process one message at one time (need to wait the respond before can process other message request).

What I want to achieve is the job can send request without waiting the reply so it can process and send other requests.

I read in internet there is "callback" function, is there some function in HTTPAPI that have the same usage as "callback"?

 

Thanks and Regards,

Randy

 

Pada Rabu, 5 Februari 2020 19.05.48 WIB, Udesen, Peder <peder.udesen@xxxxxxxxxxxxxxx> menulis:

 

 

One way of doing it could be to have two data queues – one for request and one for replies.

 

Then you have one ( or more jobs ) listening to the request data queue and send the request to whatever
target and wait for the results to be returned. When it is returned the result is sent to the result data queue.

This means this program handles the communication with the target.

 

The other program or programs send the request to the request data queue continues processing and at some point

checks if any data are returned in the data queue for replies.

If you are using the job information from the job where this job is running as a key then you can distinguish between

the different jobs sending requests when waiting for the reply having the matching key.

 

Take a look in the documentation for QSNDDTAQ, QRCVDTAQ and CRTDTAQ.

I actually made something similar with data queues 25 years ago.

 

Regards

Peder

 

Fra: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx <ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx> På vegne af Randy Susanto
Sendt: 4. februar 2020 15:46
Til: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Emne: [Ftpapi] Asynchronous XML Request

 

Hi All,

 

Is it possible to implement Asynchronous Request XML with Scott's HTTPAPI?

What I mean with "Asynchronous" is sending request and receiving the reply with different job/session.

So, the sending request session not need to wait the reply, and can process other requests. 

Other session will specifically handle that reply.

 

Thanks and Regards,

Randy

 

This email and any files transmitted with it may be confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender.

--
_______________________________________________
Ftpapi mailing list
Ftpapi@xxxxxxxxxxxxxxxxxxxxxx
http://scottklement.com/mailman/listinfo/ftpapi



This email and any files transmitted with it may be confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender.

--
_______________________________________________
Ftpapi mailing list
Ftpapi@xxxxxxxxxxxxxxxxxxxxxx
http://scottklement.com/mailman/listinfo/ftpapi
-- 
_______________________________________________
Ftpapi mailing list
Ftpapi@xxxxxxxxxxxxxxxxxxxxxx
http://scottklement.com/mailman/listinfo/ftpapi