Terminal messages are used to end communication round-trips between client and server. There are three terminal-message types:
- Terminal 1 messages:
- This is the most straightforward message-termination method. Terminal 1 messages are always initiated by the client. An example
is the client asking the server, “The user just pressed this button, what should I show in the UI?” The server then responds
with the requested answer and terminates the exchange with a Terminal 1 message.
- Terminal 2 messages:
- Sometimes, communication between client and server is more complicated. For example, if the client says, “The user just pressed
this button, what should I show in the UI?” but the server needs more information from the client before it can provide an
answer. The server responds with a Terminal 2 message, asking something like, “What is the state of option button XYZ?” If
the client has a prepared, scripted response for this request, it will provide the answer to the server’s question and end
communication with a Terminal 2 message. The server will then provide a scripted response to the client’s original question
and end the communication with a Terminal 1 message.
- This type of exchange can be illustrated as follows:
- Request from client (Terminal 1, Out Body tab)
- Request from server (Terminal 2, In Body tab)
- Response from client (Terminal 2, Out Body tab)
- Response from server (Terminal 1, In Body tab)
- Terminal 3 messages:
- Indicates that the server has spontaneously initiated a Get call requesting a value from the client. These are requests that
are not initiated by the client. Example: The server says, “I have emptied my cache, please tell me the value of option button
XYZ again.” The client then needs to respond with the appropriate answer and terminate communication with a Terminal 3 message.
- Terminal 3 messages sometimes result in replay-script breakage. Because these server requests are unanticipated, the client
can only provide a default answer, such as null. If the server accepts the default answer provided by the client, for example
if the server does not really need a specific answer to its Get call, then replay will continue (this is often the case).
If however the server finds the default response to be unacceptable, you must manually script an
OraFormsSet and an
OraFormsOnMessageGet function to prepare the correct response for the server’s Get call.
- Example:
OraFormsSetRectangle("VISIBLERECT", 0, 0, 119, 24, ORA_SET_TYPE_MESSAGEGET);
OraFormsOnMessageGet("LINE_CUSTOMER_ITEM_DSP_0"); // Requested Item
OraFormsMouseClick("LINE_CUSTOMER_ITEM_DSP_0", 70, 18, 0); // Requested Item
- Terminal -1 messages:
- Indicates an error in communication between client and server. Replay has failed because the server has received an unacceptable
answer to its request.