1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Run appserver process from Webspeed

Discussion in 'WebSpeed' started by kreutzer, Nov 11, 2013.

  1. kreutzer

    kreutzer New Member

    Hi to everybody!

    Is it possible to run an appserver process from webspeed? I have been looking through the posts and I can not find the way. I have looked on the Progress' knowledge but the result is the same.

    I am creating a Website where there are a lot of processes that takes a lot to finish, and I want to create a pool for all these processes. My idea is use an appserver to manage the pool independently from webspeed.
    Can i do that? Do you know another method to do it?

    Thanks a lot!
     
    Last edited: Nov 11, 2013
  2.  
  3. lee.bourne

    lee.bourne Member

    You can definitely kick off an appserver from webspeed. You just run CREATE SERVER like you normally would. You could then use http-equiv="refresh" in your http headers to check if the appserver has finished.

    Lee
     
  4. kreutzer

    kreutzer New Member

    Thank you!

    I've just tried and for me it's a good beginning. :)
     
  5. RealHeavyDude

    RealHeavyDude Well-Known Member

    You can connect to an AppServer from within any ABL session - which includes WebSpeed. But - there is no multi-tasking available in the ABL. Although you can have ansynchronous AppServer calls, I found no way in having them run in parallel when being invoked within the same ABL session ( WebSpeed agent ).

    The idea of having the AppServer as a susbitute for the missing mult-tasking in the ABL is around for a long time. So for I have not seen anybody succeed. But maybe somebody did and may step in here. If that's the case I am very curious on how this could work.

    Heavy Regards, RealHeavyDude.
     
  6. Stefan

    Stefan Active Member

    At what point did you not succeed? We use asynchronous calls for returning paged report results. The fun part is that the user interface can remain active, the user can also do other things (even start other asynchronous reports) and just keep working. The 'old fashioned' way was to start an extra client if one was busy with a report.

    The 'core' is 'simply':

    Code (progress):
    1.  
    2. RUN onserver.p ASYNCHRONOUS SET p_hw EVENT-PROCEDURE "HandleResults":U (lccontext_input, OUTPUT lccontext_output).
    3.  
    There is quite a bit of plumbing around this for cleaning out requests - and in this case it is not really multi-tasking since a requests for subsequent pages are fired sequentially. There is usually an order in which things need to be done due to dependencies.

    Also beware that the asynchronous calls cannot use dataset-handles. We (de)serialize to longchars. At which point, beware of the various bugs in in various versions concerning write-xml and read-xml. read-json and write-json seem to be behaving quite nicely (if you disregard the stack blowup on extents - planned to be solved in 10.2B08, not an issue in 11.2.1) but you cannot include the schema with one parameter to the method. At which point you could use write-xml-schema and read-xml-schema - but these suffer the various bugs in various versions. :)
     
  7. RealHeavyDude

    RealHeavyDude Well-Known Member

    I did not succeed with the "quite bit plumbing" in a AppServer agent. I guess it's time to try it again ...

    Thanks, RealHeavyDude.
     
  8. Stefan

    Stefan Active Member

    Oh yes, I may have forgotten the essential bits ;-) You need to create a new AppServer connection for every thing you want to run async. You cannot just use your 'synchronous' connection and you will need a new 'aynsch' appserver connection for every request if you want them executed in parallel. If you don't then all asynch requests will be queued on the single aynch AppServer - making it a bit pointless.
     
  9. RealHeavyDude

    RealHeavyDude Well-Known Member

    Stefan, indeed, that does make sense. I am wondering why this did not occur to me in the first place.

    Thanks and Best Regards, RealHeavyDude.
     

Share This Page