About Emulator Command Intercept and Markup Services

A Red App can be notified about commands that an end-user enters in Sabre emulator, and then modify the command before sending it to the Sabre GDS (informally referred to as "the host").

A Red App can use the emulator intercept and markup services to do any of the following:

Intercept a command in Sabre emulator before sending the command to the host, make changes to the command that fulfill the needs of the business, and then send the command to the host
Modify a response from the host before displaying the response in Sabre emulator
Listen for a particular command, apply business logic to substitute or modify the original command, and then use a communications service to send the command to the host
Listen for a particular command, and then perform processing within the Red App to prevent the command from being sent to Sabre emulator. This option lets you define your own command.
Register a command that returns multiple responses, and receive all responses

In order to use these markup and emulator services, you must register your services using a ContextName of EMU_COMMAND or EMU_RESPONSE, and then add all your code in the process() method of the service implementation.

To communicate with Sabre emulator, your Red App can use the following synchronous services:

EMU_COMMAND
EMU_RESPONSE

These services rely on an action code parameter. An action code is a host command, or any variation of a host command, that SRWRuntime uses to distinguish the service that registers the name EMU_COMMAND or EMU_RESPONSE.

The action code that the SRWRuntime markup services use is the command for which the Red App's service name is listening. The service registers this command with the Bus.

Example: A Red App modifies the HOT command, and specifies the EMU_COMMAND with an action code of HOT.

Sabre System Special Characters

To include Sabre system special characters in a host command or response, use the D isplaySpecialCharacters Java class and map special characters in action_code in redapp.xml. The redapp.xml file must be encoded as UTF-8. For more information, see Sabre System Special Characters.

Constraints

Restrictions on Characters in Action Codes

You cannot register a service or event listener with the ¶ character in action_code. Use the § character in place of the ¶ character. This applies to EMU_COMMAND, EMU_RESPONSE, event listeners, and your own services.

The action code in EMU_RESPONSE cannot start with or end with the § character.

AG Command and Masking of Passwords

Red Apps are not permitted to listen for the AG command. Red Apps that listen for AG will fail certification. Red Apps can listen for all commands with an empty action_code, however, if passwords are returned, they will be masked with the xxxxxx characters.

EP Command

The SRWRuntime communications bus does not pass the EP command to the following:

EMU_COMMAND services
EMU_RESPONSE services
Event listeners. This includes active listeners from Sabre Scribe scripts.

Registering Multiple Services with Different Action Codes

You can register multiple services with different action codes, however, the service that is executed is the service that registers an action code with the closest match to the command that the end-user enters last.

Example: Two services are registered with the following action codes:

Service A registers action code 1LASLAX.

Service B registers action code 1.

If the last or most recent command that the end-user types is 1LASLAX, Service A is called. However, if the user command is 1LASMIA, Service B is called.

Registering for All Commands

Your Red App cannot register for all responses, however, it can register for all commands. If another Red App registers for a specific command, the service in the other Red App is called.

Caution! If you register a service solely with EMU_COMMAND, and another service registers EMU_COMMAND with action_code of 1 at a later date, you will stop receiving responses, because multiple Red Apps cannot search for the same command.

Registering for All Responses

You cannot register a service that consists solely of EMU_RESPONSE. If you register a service solely with EMU_RESPONSE, the service will never be called.

Registering for Multiple Responses

Some host commands always return multiple responses. Commands that require greater than average time for a host response may return an initial response that is similar to "Please wait while we calculate your response," and return the actual data in a subsequent response. End-users can also continue typing commands because the keyboard is not locked.

The host responses do not include information about whether a response is first or last, or whether more responses will follow. In addition, the host response does not indicate the command to which it is related. Further, the responses may be in any order, out of sequence, and inconsistent. The order varies every time the host sends responses to a given command. When end-users continue typing commands, this complicates the handling of responses further.

For these reasons, it is difficult for developers to match a command with the correct and desired response.

When a Red App registers a callback function for the EMU_RESPONSE service with a command that typically results in multiple responses, the callback function is notified only about the first response from the host. Because you want your Red App to be notified about the response that follows, the SRWRuntime communications bus delivers all responses. Subsequent responses do not include information about the corresponding request, however, the bus attempts to match the last response to the correct request and attaches the request to the last response.

Note that we cannot completely assure you that any response is correctly matched to its corresponding request.

Processing Time versus Wait Time

If the processing time is less than the waiting time that is set in Sabre emulator, the markup instructions are sent to Sabre emulator.