What is the Progress AppServer asynchronous request mechanism?

What is the Progress AppServer asynchronous request mechanism?
Why is it useful to use AppServer asynchronous request?

The Progress AppServer asynchronous request mechanism is an asynchronous remote procedure call (RPC) mechanism. It allows the client to continue processing while the AppServer request is executed on the server, where for a synchronous request the client will wait until the request has finished. When implemented correctly, asynchronous requests will boost the overall performance of the application.

Using asynchronous requests requires an event-driven approach - since it becomes impossible to predict when the remote request will finish compared to the state of the client an effective procedural approach becomes impossible as the client would have no reliable way to identify when a request is completed.

The client should take this into account and have the proper event handling in place, meaning there should at least be WAIT-FOR or PROCESS EVENTS statement somewhere in the code to trap the events raised when the request completes.
Without either statement, the client cannot process the events which are sent by the AppServer each time an asynchronous request is completed. Consequently, without either statement, the client cannot tell the AppServer to go on to the next request and finally gives the impression that the AppServer is frozen.

To handle data being returned by the request, a callback procedure can be implemented.


The behavior of asynchonous requests also depends on the AppServer operating model:

- In State-aware, State-reset and Stateless operating modes,  If a client runs multiple asynchronous requests these will be queued and run sequentially in the order in which they are requested.
The main benefit here is that the client does not block while the AppServer is working. Another effect is that the order in which responses will be received is predictable.

- In State-free/Session-free, the asynchronous requests will be executed in parrallel, spread over multiple agents.
The extra benefit here is that the client can have multiple agents working for it at the same time, and thus get more work done in the same time. In this case, the order of responses becomes unpredictable: if one request takes a long time, shorter request that are started after it may finish sooner.
It's up to the application to collect and synchronize the responses.

 

• The AppServer asynchronous request mechanism is not intended to be a message queuing mechanism.  If the goal is to build an architecture where an application can queue up a bunch of requests and then go away while those requests are running, there are a few options:
  • Use SonicMQ:  This is exactly what it is designed for.
  • Send a bunch of requests to an AppServer for which a disconnect procedure is already registered:
  • In the AppServer, business logic queues up the requests in some application-specific way. For example, put them in a temp table or a database. When the client disconnects, fetch requests from wherever they are queued and run them in the disconnect procedure.  NOTE: This requires a state-aware or state-reset AppServer to make this work. In these modes, the disconnect procedure runs after the end-user is disconnected from the AppServer. In stateless mode, the disconnect procedure runs before the client is actually disconnected from the AppServer.
  • Build some peer-to-peer model (not using AppServer) where the messages are sent to a peer using an application-specific protocol:
    • For example, use a database as a message queue or send messages using sockets. Both of these types of models have been used by some Progress ISVs.
• It is not possible to execute synchronous requests if there is an asynchronous request outstanding on the same appserver.  Attempting to do this will result in error 9004:
  • SERVER <name> has outstanding asynchronous requests.  Cannot RUN. (9004)
  • The appserver broker maintains an internal count that tells it how many asynchronous requests are outstanding, and it won't accept any other type of request until the count is zero.  If it's necessary to run both synchronous and asynchronous requests on the same appserver simultaneously, then the requests will have to be made via separate appserver connections.

References to Written Documentation:

OpenEdge Application Server: Developing AppServer Applications