Dear All,
In the example below, any chance to keep yyteste1.p running after return command in the caller yyassincr.p?
Caller: yyassinc.p
define variable hRequest as handle no-undo.
define variable hServer as handle no-undo.
define variable lReturn as logical no-undo.
create server hServer.
lReturn =
hServer:connect(" -AppService as-hc-si -S 22015 -H tst -DirectConnect").
if lReturn then do:
run yyteste1.p on hServer asynchronous
(input "1")
/*set hRequest no-wait*/.
end.
else
message "Error to connect AppServer as-hc-si" view-as alert-box.
/*wait-for procedure-complete of hRequest.
.delete object hRequest no-error.
.hServer:disconnect().
.delete object hServer no-error.
*/
return.
Called: yyteste1.p
define input parameter pvc_param as character no-undo.
output to value("i_am_here." + pvc_param).
put string(time,"hh:mm:ss") skip.
if pvc_param <> "1" then
for each sod_det no-lock
:
put sod_nbr " "
sod_line " "
sod_part " "
sod_due_date " "
skip.
end.
else
for each pt_mstr no-lock:
disp pt_part
pt_desc1.
end.
put string(time,"hh:mm:ss") skip.
output close.
Thanks, Geraldo
Thanks Thomas. Errors are in server log file.
I may be missing something. But that is what running something asynchronous means. yyteste1.p will run on the server until it is finished. On the client side, life will just proceed on as usual. But usually, there is some UI on the client, so the user can keep on working and doing other things while the async routine is running on the server. Then at some point, the client will be notified that the async routine has finished, if you've set up an event handler for that (PROCEDURE-COMPLETE event).
In this case, the caller, yyassinc.p, is shutting down it's server connection after it makes the async RUN. Why is it doing that? Is the client-side application over? If not, what is happening on the client side? Does the client never want to know that the procedure completed? It doesn't necessarily need to know.
But with classic AppServer, I think when the client disconnects from the server, the server knows about it and generates a STOP condition, so the server procedure will generally not finish unless it handles a STOP condition and ignores it. In the new PASOE environment, I think it works differently, but I'm not sure how.
Hi,
yes, this is the point, when yyassin.p (client) disconnect the called yyteste1.p STOP without complete.
The purpose is, after a client request the caller should created a file with sales history for example and send it to the user by email.
I don´t want to keep connection alive while creating this file beucase can take time.
I can implement it create a table to control and start yyteste1.p looking at this table and creating / send the emails, but i would like to know if it possible to do using only asynchronous call.
Regards, Geraldo.
Queuing up a separately executed task is a much better idea. What are you going to do if the subprogram encounters an error and there is no place to report it?
Probably Thomas is correct. You could play around with catching the STOP that is generated and allow the program to keep going. But this seems kind of kludgy/iffy to me.
Thanks Thomas. Errors are in server log file.
yes, as Thomas is hinting about:
storing the request in a table ensures it is not forgotten. What if something happens on the server, and your client is already gone. Nobody will know that the request was either not at all executed, or just partially...
I guess, that's why almost every application I know of has some sort of batch-process that's working off a queue or requests. You can mark the request as successful, restart a request if needed, or mark it as failed and - if it was a system failure investigate why it failed; or if it was a business-logic triggered "reject" have the user fix the data-entity and resubmit another request...
Asynchronous calls - although appearing elegant, and a handy tool for other situations - are not a good solution for such features...