Skip Navigation

About Sabre Host Communications Services

Host communications services give Red Apps the ability to execute Sabre GDS commands to support business needs. (In this document, the Sabre GDS is informally referred to as the "Sabre host," and the com.sabre.edge.cf.host.Communication service is informally referred to as the "host communications service.") The host communications service needs to share the Terminal Address (TA) session in Sabre emulator, but the host communications service does not share TA session information with a Red App. A Red App can execute either a single command or a sequence of commands. When executing a sequence of commands, the host communications service provides the ability to acquire a lock on the TA session for a specific period of time. During this period, other Red Apps within the Sabre Red 360 environment cannot access the TA session. After the final command in the sequence is executed, the Red App must unlock the TA session to make the session available to other Red Apps.

com.sabre.edge.cf.host.Communication Service

The host communications service sends commands to the host and receives a response. If a Red App sends a single command in a single session, the host communications service handles the following on behalf of the Red App:

  • Verifies locked status for the TA session

  • Locks and releases the TA session

If a Red App sends multiple commands in one session to the host communications service, the Red App must handle the locking and releasing of the TA session using the com.sabre.edge.cf.host.Locking service (informally referred to as the "locking service").

The locking service context gives a Red App the ability to gain temporary and exclusive access to a Sabre emulator Terminal Address (TA) session.

Note
 You can send a command to the Sabre host with the special SDS message format. The command must be supported by SDS. A Red App uses the locking service, and then sends a set of commands to the host or SDS communications service. The host responds in the native SDS response format, which is the case whether you receive SDS commands via SRWRuntime or otherwise. If multiple SDS commands are sent in a session, a Red App also handles the locking and releasing of the TA session using the locking service. For more information about SDS, contact your Sabre Account Manager.

Constraints

The host communications service com.sabre.edge.cf.host.Communication cannot be used with actions on the first run of a plug-in because the API is not initialized when the firstrun extension point is processed.

If you are using the com.sabre.edge.cf.host.Communication service on the Microsoft  Windows  7 platform,you must run Eclipse as an administrator. Right-click eclipse.exe, and choose Run as an Administrator.

Sabre System Special Characters

Use the DisplaySpecialCharacters Java class to include Sabre system special characters. For more information, see Sabre System Special Characters.

Dependencies and Classes

Both Eclipse and Sabre Red 360 have defined some dependencies and classes for host communications that are required to send Sabre commands to the host. These requirements follow.

Minimal Dependencies

  • com.sabre.edge.cf.core

  • com.sabre.edge.cf.model

  • com.sabre.edge.cf.host

Classes

  • If your Red App does NOT contribute to the UI, your Activator must extend AbstractEdgeBaseNonUIPlugin .

  • If your Red App contributes to the UI, your Activator must extend AbstractEdgeBasePlugin.

  • You must use the getServiceReference() method to get a reference to the token.

  • Invoke the process() method on an instance of SRWRuntime to use a communications service.

Each service that is registered with the Bus can use a different type of request, however, the services that access the host share the same HostCommand request class.

Services that access the locking service share the same LockRequest request class.