Skip Navigation

About Synchronous Services

A service is a component that provides specific functionality, implements the IService interface, and can be accessed by other Red Apps. A service must be registered with SRWRuntime, and the calling Red App must be authorized to access the service. Service requests are synchronous in nature, where the calling client blocks for a response from the service.

SRWRuntime is a single point of access for all registered services that are provided by both Sabre systems and Red Apps.

Services are registered with the Bus during the startup of Sabre Red 360 or the plug-in. Plug-ins or apps that need service information to communicate with the Bus use service processing APIs.

Using Registered Services in Red Apps

The IService interface class has one method, process(), that you must override. To use synchronous services from SRWRuntime, a Red App creates and instantiates ServiceContext, and uses the ISRWRuntime process method by providing IServiceContext information. The ServiceContext object passes the required service context information to the Bus. (The com.sabre.edge.cf.model plug-in has the default implementation of ServiceContext.) The process() method takes only one parameter of type IServiceContext , which holds the request and response objects. The value for the handler_name attribute must be the fully-qualified name of your IService implementation.

IServiceContext holds the following information, and shares this information among all plug-ins while processing the requested operation:

  • ContextName is the name of the service that a Red App will execute. Service context provides information about the service, such as service context name, and the request that sends the selected service.

  • Request object. This object contains all information for the requested service name.

        You create a request object and call a process() method on the SRWRuntime object in which you pass the service context.

        Each service that is registered with the Bus can use a different type of request, however, some services share the same request class. The procedures in the topics that discuss the synchronous services note the request class to use.

  • Status provides status information after executing the requested service. This field informs the Red App about either successful execution of the service or error conditions.

  • Response object. Upon successful execution of a requested service, the Response object contains all response information for the service.

        You receive the response from the Sabre host in the same context object (context.getResponse()). You then add your business logic, such as printing the response on the UI.

  • Error. If SRWRuntime receives an error while executing the requested service, the Error object contains the error information.

  • RequestorId holds the unique Red App ID of the Red App that is requesting the service. (The RequestorId is the Red App ID, a unique identifier that Sabre assigns to every Red App when a Red App proposal is approved.) The value that you pass in RequestorId also maps to the id attribute of the RedApp entity in redapp.xml.