The following figure shows a remote procedure executed asynchronously. As in the synchronous request example, the client is an event-driven GUI and the application sets a simple status flag (Done) to indicate that the remote request has completed.

Figure 1. Asynchronous requests


In this implementation, the client first executes async.p as an asynchronous remote procedure (1, specified by the ASYNCHRONOUS keyword on the RUN statement). The client immediately continues execution, until it reaches the WAIT-FOR statement to get events (2) at the same time that the server executes the remote request. Thus, at this point (1 and 2), the client and remote request are running in parallel. The client can continue to execute, calling additional asynchronous remote procedures on the same or a different server connection.

As each asynchronous request completes (like async.p at 3), the client handles the results in a specified event procedure (4). This event procedure, specified in the asynchronous RUN statement, is essentially a "trigger" that executes on the client in response to a PROCEDURE-COMPLETE event posted to the client when the associated asynchronous request completes.

As with user-interface events, the client can handle PROCEDURE-COMPLETE events in the context of a blocking I/O statement, such as the WAIT-FOR statement (4), or by executing the PROCESS EVENTS statement. The client session maps the PROCEDURE-COMPLETE event for each asynchronous request to the appropriate event procedure using a unique asynchronous request handle that is generated for each request (not shown). This handle provides the mechanism that you can use to monitor the status of each request.

Note that this asynchronous request example provides the same functionality as the previous synchronous request example. In fact, sync.p and async.p are identical, except for their names, which are changed for readability. The PAS for OpenEdge instance has no idea whether its procedures are being called synchronously or asynchronously. The type of request is entirely a function of the client and its implementation.

The main difference, is that the bStatus trigger in the asynchronous request example tests the status of the remote request and performs actions based on whether the request finished, rather than invoking the request itself, as in the synchronous request example. Thus, the synchronous bottleneck is removed. In all such cases, the synchronous bottleneck is avoided by handling the results asynchronously.