Asynchronous Behavior › Async Action Statements › GET ASYNC RESPONSE › Conditional Clauses (WHEN)

Conditional Clauses (WHEN)

The optional set of WHEN clauses on the GET ASYNC RESPONSE statement, give you processing control that is not available with a synchronous cooperative flow. For example, you may not want to interrupt the application's current processing if an error is detected during the handling of an asynchronous request. Compare this with the processing of a synchronous cooperative flow, where errors are handled by the runtime servicing the flow, and the processing of the initiating PStep is aborted if the runtime detects an error in either the handling of the request or in the actual processing of the target PStep code (that is, an XFAL).

As an application developer, you may want control of the various processing conditions that may occur when servicing an asynchronous flow. Alternatively, you may prefer that the runtime process errors in the same way as they are handled for existing synchronous flows. The behavior of the GET ASYNC RESPONSE statement can be modified, depending on which of the WHEN clauses you include in the statement.

When executing the GET ASYNC RESPONSE statement, the process flow gives control to an applicable WHEN clause, if it is present. When the block of code associated with the WHEN clause has completed, processing continues with the statement immediately after the GET ASYNC RESPONSE statement. All of the WHEN clauses are included in the code when the GET ASYNC RESPONSE statement is constructed by the PAD editor. You can delete any of the WHEN clauses, as required.

Control is passed to the associated WHEN clause under the following circumstances:

• WHEN successful—Control is passed to the WHEN successful block of code if the response identified by the specified ASYNC_REQUEST view is available, and has successfully resulted in the runtime populating the specified view (specified by the WHICH EXPORTS clause). The outstanding request is considered complete as a result of successfully executing the GET ASYNC RESPONSE statement.

  If the statement is not present, processing continues with the statement following the GET ASYNC statement.

• WHEN pending—The behavior of the GET ASYNC RESPONSE statement varies depending on whether the WHEN pending clause is present. If present, active polling is used, and the response identified by the specified ASYNC_REQUEST Work Set view is not available, control is passed to the WHEN pending block of code. That is, the outstanding request remains outstanding, and the execution of the GET ASYNC RESPONSE statement operates as a non-blocking operation.

  If the WHEN pending clause is not present, passive polling is used, and the GET ASYNC RESPONSE statement causes the application to block until the response is available. Processing is returned to the application only when the asynchronous request is completed. The appropriate WHEN clause is driven when processing the completed request.

• WHEN invalid ASYNC_REQUEST ID—If the specified request identifier does not correspond to an outstanding request, processing continues at the first statement contained in the WHEN Invalid ASYNC_REQUEST ID.

  If the WHEN invalid ASYNC_REQUEST ID is not present, processing continues at the default error handling code generated for this statement. Processing exits the currently executing code. This may be handled differently if within a GUI event or within an action block.

  Note: For more information, see the Distributed Processing – Overview Guide.

• WHEN server error—If this clause is present, and the response returned from the server contains a server failure (that is, an XFAL buffer), control passes to the first statement contained within the WHEN server error clause.

  If the WHEN server error clause is not present, the CA Gen runtime continues at the default error handling code generated for this statement. That is, the currently executing code is exited. This may be handled differently if within a GUI event or within an action block.

  Note: For more information, see the Distributed Processing – Overview Guide.

• WHEN communications error—If this clause is present, and the processing of the asynchronous flow encounters a problem in either the transport of the request or receipt of the response (that is, an XERR buffer), then processing is passed to the first statement contained within the WHEN communications error clause.

  If this clause is not present, control is passed to the default error handling code generated for this statement. This default code causes the processing to exit the currently executing code. This may be handled differently if within a GUI event or within an action block.

  Note: For more information, see the Distributed Processing – Overview Guide.