Terminal Messages

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:
  1. Request from client (Terminal 1, Out Body tab)
  2. Request from server (Terminal 2, In Body tab)
  3. Response from client (Terminal 2, Out Body tab)
  4. 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.