Sabre Emulator API to Native API: Migration Guide
Background
The Sabre Emulator API solution was based on .dll file that acted as a bridge between SRW 2.0 and external applications. The Sabre Red 360 uses Native API, which introduces a message-based approach. Native API uses Java Message Service queues (ActiveMQ) to allow communication between external applications and the Sabre Red 360. For the client application, this means sending messages to one queue and listening for SR360 responses on another queue, rather than calling methods provided in .dll file.
How to Move from Sabre Emulator API to Native API
To use Native API, you will need to create a simple Red App that tells the Sabre Red 360 to create dedicated queues for the external applications. The Red App consists of only a few configuration files. Instead of an authentication token, your Red App ID will be used for authentication and authorization purposes.
For details on how to create the Red App used for connection, please have a look here.
If you want to see a sample for Red App or Client you can look here.
APIs Mapping
Despite the technology and protocol changes, new solution offers the same functionality with additional enhancements. Main functionalities present in the Sabre Emulator API are still available in the Native API. Below is the mapping of how the old API methods correspond to the new messages:
| Sabre Emulator API | Native API |
|---|---|
sendCommandToHost |
SendHostCommandRQ |
sendCommandToEmulator |
ExecuteInEmuRQ |
sendMessageToEmulator |
ShowInEmuRQ |
sendReceiveMsg |
SendHostCommandRQ |
beginSabreTrafficListener |
EventSubscriptionRQ |
Not available |
GetSessionSecurityTokenRQ |
More information here.
Monitoring Sabre Red 360 Startup and Shutdown
Startup
Due to a different architectural approach with the Native API, there is no notification mechanism for the client applications when the Sabre Red 360 starts up. A client needs to connect to a running instance of the Sabre Red 360. However, if a client tries to connect to the Sabre Red 360 before it is ready, the following java exception may be thrown:
Due to a different architectural approach with the Native API, the only way for a client to verify whether or not the Native API broker is running, is to try to establish connection to it. If the connection fails, the following exception may be thrown in the client application (assuming it is written in Java):
javax.jms.JMSException: Could not connect to broker URL: tcp://localhost:61616. Reason: java.net.ConnectException: Connection refused: connectIf this happens, it is advised to periodically retry establishing the connection to the Native API broker, since it might not have started yet.
Shutdown
There is no message based notifying mechanism for the client to indicate shut down of the Native API broker. If the Native API broker closes while the client is connected, the following exception may be thrown in the client application (assuming it is written in Java):
javax.jms.IllegalStateException: The producer is closed