Skip Navigation

About Event Listeners and Event Listening

An event is the occurrence of a condition that is important to one or more components of Sabre Red 360. Red Apps and other components of Sabre Red 360 can register as listeners for events that are of interest to them. When the condition for an event is met, the event source (the component where the event occurred) creates an event object and publishes it to SRWRuntime. SRWRuntime then dispatches the event to all the registered listeners. This prevents a direct coupling between the event publishers and event listeners. All event processing is asynchronous, where SRWRuntime calls the listener, but it does not block for a response from the listener. A Red App then executes some functionality when an event is raised.

If you want your Red App to listen to events that Sabre data stores or other Red Apps publish, you must add asynchronous event listening to the main Red App plug-in in a Red App bundle. A Red App can register a set of event listeners that listen for one or more events, and other Red Apps can leverage events to influence their processing. Red Apps that listen for events register an event listener in the redapp.xml file.

Your listener can also register for EMU_RESPONSE events that return multiple responses to a given request.

When an event is published by an event source to the Bus, for example, when an agent types a command in Sabre emulator, the Bus sets the event state to PRE and calls listeners that are registered for the PRE state of the event. These listeners are invoked before the workflow for that particular event is invoked. After the workflow is executed, the Bus dispatches the event to all listeners that are registered for POST processing of that event. If no workflow is defined for an event, then the Bus does not invoke any workflow. The PRE and POST transaction event listeners are called in succession.

Creating EventListener Classes and Handling Events

EventListener is a class that registers for a specific set of events. This class is notified when the specific event is triggered.

A Red App implements the IEventListener interface to create an EventListener class, as shown in the following example:

public class HotelEventHandler implements IEventListener

The IEvent interface defines the methods that are required for an Event class. The published event information is passed to the EventListener object in the handleEvent() method. The information is contained in an IEvent object. The Red App uses this information to perform business logic.

Sabre Published Event IDs

Sabre has published the following Event IDs:

  • EMU_EVENT_001 with the PRE state. This is a Sabre emulator command request or response before markup changes. Please note that EMU_EVENT_001 has been deprecated and EMU_COMMAND should be used instead.

  • EMU_EVENT_002 with the POST state. This is a Sabre emulator command request or response after markup changes. Please note that EMU_EVENT_002 has been deprecated and EMU_COMMAND should be used instead.

  • EMU_COMMAND with the PRE state. This event is generated before sending a command to the Sabre host. This event should be used instead of EMU_EVENT_001 with the PRE state.

  • EMU_COMMAND with the POST state. This event is generated after sending a command to the Sabre host. This event should be used instead of EMU_EVENT_002 with the POST state.

  • EMU_RESPONSE with the PRE state. This event contains both the Sabre emulator command and response content before markup changes. When a Red App receives a response from Sabre host, SRWRuntime generates the EMU_RESPONSE event. You cannot modify content in the response.

  • SCRIBE_SCRIPT_STARTED with the POST state. It is triggered, when Scribe script execution was started. This event contains a map in its data field. Inside this map, there is a script name, which can be obtained using "scriptName" key. Please note that if multiple scripts are executed in chain, using SPAWN or CHAIN command, only the first one triggers this event.

  • SCRIBE_SCRIPT_COMPLETED with the POST state. It is triggered, when Scribe script execution was completed. This event contains a map in its data field. Inside this map, there is a script name, which can be obtained using "scriptName" key. Please note that if multiple scripts are executed in chain, using SPAWN or CHAIN command, only the last one triggers this event.

  • SR360_START with the POST state. Event is triggered on Sabre Red 360 start when application is ready to accept requests.

  • SR360_STOP with the POST state. Event is triggered on Sabre Red 360 close.

Filtering Event Listeners with Action Codes

Red Apps can register listeners for events that are filtered by host commands. It is strongly recommended that you add a filter for commands to any event listener. This is especially useful for web apps.

When Java-based apps or web apps that are based on JavaScript register event listeners for emulator commands, the event listener function is notified every time a command is typed in the emulator. No distinction is made for a particular command. Java apps typically have filtering logic in an event listener so that the desired command is filtered and other commands are ignored.

Sabre Red 360 Software Development Kit_ has enhanced the event listener mechanism by enabling registration for specific command or response events. A command prefix is registered in an action_code attribute in redapp.xml. When you register a command prefix, your JavaScript function is notified only about the particular command or response that you register.

You can use this functionality with the following events:

EMU_EVENT_001

EMU_EVENT_002

EMU_COMMAND

EMU_RESPONSE

For EMU_EVENT_001, EMU_EVENT_002 and EMU_COMMAND, SRWRuntime notifies listeners that register only for events generated by commands that begin with the prefix in the action_code attribute. Please note that EMU_EVENT_001 and EMU_EVENT_002 have been deprecated and EMU_COMMAND should be used instead.

For EMU_RESPONSE, listeners are notified when an event is generated after a response to commands that begin with the prefix in action_code.

Note
To maintain compatibility with previous releases, you can omit the action_code attribute, however, if this attribute is not present in redapp.xml, the listener is registered for all events of the specified type, for example, EMU_COMMAND.

Scenario for EventListening with Java

If you are using Java to code your Red App and your event listener registers EMU_COMMAND with an action_code of 1, your event listener method is called every time it detects the registered command in the emulator. To handle this, your Java event listener code has filtering logic to filter for the command that you want and ignore all other commands.

Scenario for EventListening with Action Codes Using Javascript

When you are using JavaScript and you register a web event listener for EMU_COMMAND, your JavaScript function is notified about every command that is typed in the emulator, which is the same as Java. However, JavaScript opens the browser to inform your Red App every time a command is typed in the emulator. This creates large overhead and is annoying to end-users.

To reduce this inefficiency, your app registers an event listener JavaScript function for a specific command or a specific response by using an action code. Your app is notified only for the specific command or response, for example, if you register a command for hotel selling, you will not be notified about other commands such as vehicle selling, fair quotes, etc.

Sabre System Special Characters

Java-based Red Apps that register an event listener use the DisplaySpecialCharacters class to send Sabre system special characters, and they map special characters in action_code in redapp.xml.

Red Apps that are written in other development languages and that register an event listener, map Sabre system 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

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.

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.

Constraints on EMU_RESPONSE Events

Your listener can register for EMU_RESPONSE events that return multiple responses to a given request or action_code.

When a Red App registers a listener for the EMU_RESPONSE event with a command that typically results in multiple responses, the listener is notified only about the first response from the host. Because you want your Red App to be notified about subsequent responses, the SRWRuntime communications bus notifies registered listeners about all responses. The bus does not correlate subsequent responses with the corresponding request, and the host does not identify whether a response is last.

Therefore, we cannot completely assure you that any response is correctly matched to its corresponding request, and we cannot assure you when a response is the last response.

For an explanation about processing host commands with multiple responses, see #Registering_for_Multiple_Responses in "About Emulator Command Intercept and Markup Services."

Registering Event Listeners for Published Events

Red Apps can publish their own events with SRWRuntime. Other Red Apps may then register event listeners for these published events.

Syntax for Registering Event Listeners

For the syntax to register event listeners in redapp.xml, see Listener Registration in Red Apps.

Types of Red Apps That Can Register Event Listeners

Red Apps that use the following technologies and functionality can also register event listeners. For more information, see the referenced topics.