Communications in Red Apps Overview

It is likely that you will design a Red App to communicate with Sabre Red 360 and Sabre data stores, such as the Sabre GDS or Sabre emulator. Your Red App may also communicate with other Red Apps. (Sabre emulator is also referred to as Classic View, however, this documentation consistently uses the term "Sabre emulator.")

To make communications possible, Sabre Red 360 relies on a communications bus, called SRWRuntime. Red Apps use this communications bus to communicate with services that Sabre components and other Red Apps register, as well as to register event listeners for event listening. In addition, Red Apps can publish their own events. (The terms "SRWRuntime" and "communications bus" are synonymous. This document uses all of these terms, or sometimes simply "Bus.")

SRWRuntime is the single gateway between Red Apps and services that the Sabre Red 360 platform exposes. These services vary from intercepting Sabre emulator commands for markup, to communicating with Sabre Web Services.

You include communications services in your Red App that you want your Red App to expose. The Bus performs all interactions with underlying services on behalf of a Red App. The Bus uniformly applies common services to every request that it processes, such as authentication, authorization, connectivity, throttling, monitoring, orchestration, and logging. The Bus also supports both asynchronous and synchronous access patterns.

You can add any of the following types of communications to your Red App.

Synchronous services that Sabre data stores register, that third party Red Apps register, and services that Sabre provides for command intercept and markup
Event listeners and asynchronous event listening
Event publishing

Components in a Red App that implement communications include authorization, and registration in a redapp.xml configuration file. All communications must be present in the main Red App plug-in within a Red App bundle.

Synchronous Communications Services

SRWRuntime implements a Service Registry that allows both Sabre and Red Apps to register the services that they expose. When a Red App makes a request that is directed to one of the registered services, SRWRuntime does a lookup for the requested service in the registry, executes the service, and provides the information. SRWRuntime exposes only the relevant information and interfaces of the underlying services to the outside world.

You can add communications by writing Java code, or you can use the JS bridge to register for SRWRuntime communications functionality with a JavaScript function instead of Java methods. Both of these mechanisms require authorization in your redapp.xml file and an authentication token.

You can think about synchronous services as described below.

Synchronous services registered by Sabre. Sabre data stores register services with the SRWRuntime bus which all Red Apps can call. To call these synchronous services, specify the fully-qualified service name that Sabre registers with the bus. (See Request and Response Object Classes.) You will also request an authentication token in your code and request authorization to use these services in your redapp.xml file.
Synchronous services that third party Red Apps register. As Red App developers, you can create and register services that will be available for other Red Apps to call in the same way that your Red App calls services that Sabre registers. A Red App registers its third party services in redapp.xml.

In order to call a third party service, a Red App must know the service name. To obtain this information, Red App developers need to exchange this information. It is easier to call OSGi services than it is to use a third party service. Developers are familiar with OSGi services, how to use them, and how to find the names. For more information, see Access to OSGi Services.

Intercept and markup services that execute actions. These are the EMU_COMMAND and EMU_RESPONSE services. Although these are referred to as services, a Red App registers a callback function in redapp.xml to use these services instead of calling these services directly.

The command and response services call the callback function whenever an action occurs. Whenever a user is typing a command, SRWRuntime is executing these services, and these services are executing the callback functions.

For more information about EMU_COMMAND and EMU_RESPONSE , begin with About Emulator Command Intercept and Markup Services.

Sabre Registered Synchronous Services

Your Red App can call the following types of services:

Send information to Sabre emulator:

com.sabre.edge.cf.emu.ShowInEmulator service. This service sends commands to Sabre emulator. The command can be treated either as an emulator command or as a message.

com.sabre.edge.cf.emu.ExecuteInEmulator service. This service sends commands to the host through Sabre emulator.

com.sabre.edge.cf.host.Communication service, called Sabre GDS (Sabre host) communications service. Your Red App can use this service to send a single request or multiple, consecutive requests to the host.
com.sabre.edge.cf.sws.SWS service, called Sabre Web Services communications service. Your Red App can use this service to make a single service call or to send multiple, consecutive requests.
com.sabre.edge.cf.rest2sg.Rest2Sg service, called Sabre Web Services communications service. Your Red App can use this service to make a single service call or to send multiple, consecutive requests.
com.sabre.edge.cf.host.Locking service, called the Locking service. This service locks a TA session. Red Apps are required to use this service if they are using either the host communications, Sabre Web Services, or an SDS service to send multiple, consecutive requests within a single session.
com.sabre.edge.cf.host.SDS service, called the SDS service. This service sends commands to the Sabre GDS with SDS message format. Your Red App can make a single call or make multiple, consecutive requests to SDS in a single session.
com.sabre.edge.cf.emu.HighlightExtractorService This service allows extracting text highlighted in Sabre emulator.

Sabre Command Intercept and Markup Services

SRWRuntime services provide the following functionality that you can add to your Red App.

There are two names under which you can register services to intercept commands and add markup instructions. You can also define your own command using these services.

EMU_COMMAND
EMU_RESPONSE

Event Listeners and Asynchronous Event Listening

If you want your Red App to listen to events that are published by Sabre data stores or other Red Apps, add asynchronous event listening to your plug-in. Event listeners are notified about SRWRuntime calls. Listeners can receive notifications before or after an actual call to runtime. Notifications are asynchronous, and modifications to notification data do not affect the actual call.

Listening to Sabre emulator requests or responses, either before or after they are sent to the emulator, uses the following published events:

EMU_EVENT_001 with the PRE state. This is a Sabre emulator command request or response before markup changes. Please note that this event 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 this event 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 Sabre host and 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 Sabre host and should be used instead of EMU_EVENT_002 with the PRE state.
EMU_RESPONSE with the PRE state. This is a Sabre emulator command and response before markup changes.
EMU_RESPONSE with the POST state. This is a Sabre emulator command and response after markup changes.

Web apps can use JavaScript functions to implement complex event listening and event listening for action codes. These types of web apps can also register JavaScript functions as event listeners.

Event Publishing

SRWRuntime allows any Red App to "publish" events in response to an occurrence. This works asynchronously. When an event is posted by an event source to SRWRuntime, SRWRuntime calls listeners that are registered for the Event ID and event state.

Authentication, Authorization, and Registration

To use communications services that are registered with SRWRuntime, your Red App must authenticate and request authorization. To register your own services, event listeners, and events with the Bus, you include information in a redapp.xml configuration file. This file also registers services and passes your Red App ID to Sabre. For information, see Overview of Authentication, Authorization, and Registration.