Asynchronous (ASYNC) Processing
Asynchronous processing allows a requesting application component to be given control immediately after a flow request is made, so that it can continue with other processing while the target server is processing an outstanding request.
cagen
1515903
11106
ASYNC_exception_condition
1515906
15029
15030
USE_ASYNC_fld_Identified_By
15031
15032
1515907
ASYNC_Work_Set
Asynchronous Processing
Asynchronous processing can also initiate cooperative flows without any obligation to process the corresponding response, thus allowing a fire and forget capability in
Gen
applications.This type of processing contrasts with Synchronous processing, the type of flow behavior found in versions of COOL:Gen before 6.0. In Synchronous processing, application behavior is restricted to request and wait on a reply, effectively blocking further processing by the requesting application until retrieving a reply.
Applications that use asynchronous flows are complex, as the logic necessary to request that the services of a target procedure are separate from the logic that is involved in retrieving the response, requiring strict adherence to good asynchronous design practices. The developer is given the opportunity to provide the logic for handling errors that may occur. For more information, see Asynchronous Processing.
Asynchronous flows can be modeled for either Client-to-Server or Server-to-Server flows.
To add ASYNC statements to a
Gen
model, do the following:- From theGenModel Window, highlight the Design Menu and select Action Diagram.
- From the Action Diagram Names dialog box, highlight a procedure step and click OK.
- Highlight the line in the code that immediately precedes where you want to add the ASYNC logic.
- From the Action Diagram Edit Menu, select Add ASYNC Statement.
- Select the desired ASYNC statement from the first four options.
- For help with constructing an ASYNC statement, see the topic with that ASYNC statement name (USE ASYNC, GET ASYNC RESPONSE, CHECK ASYNC RESPONSE, IGNORE ASYNC RESPONS).
ASYNC Work Set
Asynchronous processing requires a new work set, ASYNC_REQUEST, which is present in every Advantage Gen 6.5 model and subsequent models.
A view of the ASYNC_REQUEST Work Set provides a method of communication between USE ASYNC and the other ASYNC statements. The returning data includes information relating the status of the USE ASYNC. An instance of an ASYNC_REQUEST view identifies a given outstanding ASYNC request. The ID field is populated as a result of initiating a flow with the USE ASYNC statement. Once initiated, a specific outstanding ASYNC request is identified to the other ASYNC statements (GET ASYNC RESPONSE, CHECK ASYNC RESPONSE, IGNORE ASYNC RESPONSE) by specifying the instance of the ASYNC_REQUEST view that contains the ID value that is returned on the USE ASYNC statement.
Unlike other workset views, the ASYNC_REQUEST view is modified by the runtime to communicate the request ID and the error message back to the application.
If a single instance of an ASYNC_REQUEST view is used for multiple, potentially simultaneous asynchronous flows, it is the responsibility of the application designer to track and maintain the request IDs as returned from the USE ASYNC statement. A second usage of the USE ASYNC statement, using the same ASYNC_REQUEST view, results in the loss of the request ID returned from the first USE ASYNC unless the application takes explicit steps to save that first request ID.
The attributes of the new work set, ASYNC_REQUEST, follow:
Name | Domain | Length | Description |
ID | NUM | 8 | Set by runtime and is the unique ID. |
REASON_CODE | TXT | 8 | Reserved for future use. |
LABEL | Mixed Text | 128 | Optional. Can be set to identify a request in a more user-friendly way. |
ERROR_MESSAGE | Mixed Text | 2048 (max) | Set by the runtime and contains the text of what happened when an error occurred. |