The RESPONSE_HANDLING clause is used to set Asynchronous requests as POLL requests or NOTIFY EVENT requests.
A RESPONSE HANDLING clause specified as POLL communicates, to the supporting runtime code, that the application will ask for response information rather than expect to receive it automatically. The application will complete an outstanding request using a GET ASYNC RESPONSE statement or by using an IGNORE ASYNC RESPONSE statement. The GET ASYNC RESPONSE statement supports both active and passive polling, as described in the Processing Options for Async Requests section.
A RESPONSE HANDLING clause specified as NOTIFY EVENT indicates that the application is notified when a response to an event is received by the supporting runtime. The event notification is handled in a similar way to existing window events. You must first specify that the application wishes to be notified, by specifying a value of NOTIFY EVENT for the RESPONSE HANDLING clause on the USE ASYNC statement. Additionally, you must associate an event handler with each asynchronous request that specifies an event be raised. The event handler name is supplied via the RESPONSE EVENT clause on the requesting USE ASYNC statement. A unique event type is created for each given instance of the USE ASYNC statement. This unique event type is associated with the specified event handler that has been specified using the RESPONSE EVENT clause.
When you add a NOTIFY EVENT type USE ASYNC statement, you can create a new EVENT ACTION block, or select an existing EVENT ACTION already associated with the PStep.
Note: The runtime only provides notice that the request has completed. This does not imply that the request completed successfully.
As with other window events, the PStep can only receive a given event when it has at least one open window. The open window is needed to send the event to the event action block that has been defined to handle the specified event type. If the window is closed, the event notification is ignored, and the response is retained or discarded depending on the response scope of the call. That is, the response is discarded if the response scope is PSTEP, and retained if the scope is GLOBAL. For more information, see Response Scope.
It is the responsibility of the application designer to determine if the request fulfilled the desired actions, and to obtain any requested data. The application may also, periodically, poll for completion status. However, any given outstanding request can only be completed once.
If an application attempts to complete a given outstanding request from more than one area of processing logic (for example, from the Action Diagram or an event handler), each statement should expect that the designated request has already been completed.
For example, the logic doing the polling may complete the request prior to the event handler being scheduled. The logic in the event handler, assuming it attempts to complete the request, must be coded to cope with the fact that the request that causes the event handler to be driven might, in fact, already be complete.
No Response
Response handling set to NO RESPONSE indicates that the application is not interested in retrieving the corresponding response of the request. Additionally, no error conditions are reported to the client. Once accepted, no indication of how the request was processed is returned to the requesting client application.
|
Copyright © 2014 CA.
All rights reserved.
|
|