Skip Navigation

Building a redapp.xml File

This topic provides guidance for creating a redapp.xml configuration file and adding the components that are expected for Red Apps. The subtopics are organized as follows:

        Non-markup services, active listening for commands in Sabre Scribe scripts, and the EMU_RESPONSE markup service

An example of a complete redapp.xml file is shown at the end of this topic.

Additional Resources for redapp.xml are also included.

Registration of All Red Apps

  1. Create a single, blank redapp.xml file. The required name for the configuration file is redapp.xml.

  2. Add the file to the root location of your main Red App plug-in project within your Red App bundle.

        The main plug-in is the only plug-in within a Red App bundle that can use communications, therefore, only one configuration file is used. An example of a redapp.xml file in the root directory of a Red App plug-in is shown in the following figure.

xmlfileinprojectfolder

  1. In the file, add a CFBundle entity to the root location.

  1. Add the RedApp entity as a child of CFBundle. The RedApp entity contains information about the Red App.

  2. Add the id attribute to the RedApp entity. The value of id is your Red App ID. The Red App ID and the RequestorId in your Java code are always the same values. Sabre assigns a unique Red App ID when Sabre approves your Red App proposal.

<CFBundle>
  <RedApp id="12345678abc" >
</CFBundle>

  1. Encode your redapp.xml file as UTF-8. This is required for all Red Apps.

  2. Add all other data that the redapp_schema.xsd schema requires and validate your file against the schema. The XML file must be well-formed and valid; otherwise, Sabre cannot certify your Red App. The schema file is in the documentation folder in your target platform structure.

  3. When you are done creating your redapp.xml file, add the file to the bin.includes list in build.xml. This ensures that your redapp.xml file is included when you create an exported jar file.

  4. Use Eclipse to add <extension point="com.sabre.edge.cf.redapp" /> to plugin.xml in the main Red App plug-in project. The placement of this extension point in plugin.xml triggers SRWRuntime to search for redapp.xml.

Authorization to Access or Use Services

Add an Authorization component if your Red App uses SRWRuntime synchronous services or if your Red App uses services that other Red Apps register with SRWRuntime. Red Apps request authorization in the Authorization entity.

SRWRuntime synchronous services are listed below:

  • com.sabre.edge.cf.emu.ShowInEmulator

  • com.sabre.edge.cf.emu.ExecuteInEmulator

  • com.sabre.edge.cf.host.Communication

  • com.sabre.edge.cf.host.Locking

  • com.sabre.edge.cf.sws.SWS

  • com.sabre.edge.cf.host.SDS

  • com.sabre.edge.cf.sso.SsoService

This subtopic shows how to request the following:

To the RedApp entity, add one Authorization child entity for each service that your Red App accesses. Add the following attributes to Authorization.

  • name . This is the service context name that your Red App will access. All Red Apps that use communications services register a service context name with SRWRuntime. The service context name is passed in your Java code. Every service that is registered with SRWRuntime has a unique name.

  • (Optional) metric . This attribute is on Authorization, so the units of measure (tps or tpm) apply to all entries within a given Authorization tag. Metrics for the threshold cannot be mixed. Sabre Web Services Authorization and Authorization to Use All Other Services explain this in more detail.

  • threshold . Threshold is the quantity of operations on the service. This value is also passed in your Java code.

        The threshold value must comply with the requirements that Sabre establishes.

        In redapp.xml, you can add threshold to either Authorization or Action, depending upon the service that a Red App calls. The following paragraphs illustrate this use.

Sabre Web Services Authorization

In the name attribute of the Authorization entity, pass the generic service context for calling Sabre Web Services, com.sabre.edge.cf.sws.SWS.

  • metric . To specify transactions per minute, add the metric attribute to Authorization with a value of tpm. If you omit the metric tag, tps is assumed.

  • Action . Add the Action element as a child of Authorization.

  • name . Add the name attribute to Action. Pass a valid Sabre Web Services action code of a web service request.

        The SWS communications service executes a request to use only the Action name of the web service that is configured in redapp.xml. The same Action name is passed in the setAction method in the Java code.

        If you change the action name that your Red App requests, you need to change redapp.xml. If the Sabre Web Services action code in Action/name does not match the action code in the setAction method, the Bus returns the AUTH003 error.

  • threshold . Add the threshold attribute with a value.

Example 1

<Authorization name="com.sabre.edge.cf.sws.SWS" metric="tpm">
<Action name="OTA_AirAvailLLSRQ" threshold="3" />
<Action name="OTA_AirLowFareSearchLLSRQ" threshold="1"/>
</Authorization>

In Example 1, a Red App authorizes the use of two web services: OTA_AirAvailLLSRQ at the rate of 3 tpm and OTA_AirLowFareSearchLLSRQ at the rate of 1 tpm.

Example 2

<Authorization name="com.sabre.edge.cf.sws.SWS">
<Action name="OTA_AirAvailLLSRQ" threshold="1" />
<Action name="OTA_AirLowFareSearchLLSRQ" threshold="1"/>
</Authorization>

In Example 2, a Red App authorizes the use of two web services at the rate of 1 tps.

Authorization to Use All Other Synchronous Services

For all other services, it is optional to add the metric attribute to Authorization. The value can be either tpm or tps. Without the metric attribute, tps is assumed.

<Authorization name="com.sabre.edge.cf.host.Locking" threshold="2" metric="tpm" />

Registration of Services in Red Apps

Red Apps are required to register their own services with SRWRuntime, including the non-markup and markup services EMU_COMMAND and EMU_RESPONSE .

This topic shows how to do the following:

Register non-markup services.These are services that your Red App registers.

Register EMU_COMMAND for active listening in Sabre Scribe

Register the EMU_RESPONSE markup service

Registering a JavaScript Function as a Service

Important
 You cannot register a service or event listener with the ¶ character in action_code. Use the character in place of .

Registering Non-markup Services

Add a Service component if your Red App registers services that are not markup services. This is your own service.

To CFBundle, add one Service entity for each service that you are registering in your Red App bundle. For each Service entity, add the name, and handler_name attributes.

  • name . This is the name of the service context that identifies the service at runtime. This is the service that you are registering.

  • handler_name . This is the class name or executable that will be instantiated and used as the service. The class must implement the IService interface.

  • action_code . This is the prefix of the host command that your service registers with SRWRuntime. If your Red App uses the EMU_COMMAND service to intercept commands, add action_code with a command prefix. If you are using your own service, an action code is not needed.

  • (Optional) ignore . This is a list of command origins that won’t trigger Service registered. If ignore attribute is not present scribe command will be ignored to maintain backward compatibility. Currently, only commands posted by scribe and internally by Sabre Red 360 can be ignored. To ignore multiple command origins ignore attribute values needs to be separated by a colon. E.g:

    • ignore="" - Service will be executed on any command origin.

    • ignore="scribe" - commands posted by scribe won’t invoke service registered

    • ignore="scribe,internal" - commands posted by scribe and internally by SR360 won’t invoke service registered

    • no ignore attribute - commands posted by scribe won’t invoke service registered

        To send Sabre system special characters as action codes, you are required to encode your redapp.xml file as UTF-8. For more information, see Sabre System Special Characters.

Example 1:

<CFBundle>
      <Service name="com.mycompany.mycommunicationsservice"  handler_name="com.mycompany.mycommunicationsservice.ServiceClass" ignore="" />
</CFBundle>

In Example 1, a Red App registers its own service.

Example 2:

<CFBundle>
      <Service name="EMU_COMMAND" handler_name="com.sabre.redapp.example.cf.emu.bridge.CommandModificationService" action_code="1" />
</CFBundle>

In Example 2, a Red App registers its own non-markup service that listens for a command that begins with 1.

Registering EMU_COMMAND for Active Listening in Sabre Scribe

Add an EMU_COMMAND component if your Sabre Scribe script listens for commands.

To register a Sabre Scribe script that listens for a command, add the Service entity as a child of CFBundle. Each Service entity must have the name, action_code, handler_name, and target attributes.

<CFBundle>
  <Service name="EMU_COMMAND" action_code="1" handler_name="com.sabre.edge.app.emulator.scribe.ScribeListeningService" status="" desc="">
      <ExternalHandler target="SAMPLE_SCRIPT" />
  </Service>
</CFBundle>

 

  • Service . The required name is EMU_COMMAND .

  • action_code . Pass the Sabre GDS (host) command or a command prefix for which to listen. To send special characters, see Encoding Special Characters for Sabre Scribe Scripts.

  • handler_name . The required value is always com.sabre.edge.app.emulator.scribeScribeListeningService.

  • target child attribute of ExternalHandler is the name of your script.

  • (Optional) ignore . This is a list of command origins that won’t trigger Service registered. If ignore attribute is not present scribe command will be ignored to maintain backward compatibility. Currently, only commands posted by scribe and internally by Sabre Red 360 can be ignored. To ignore multiple command origins ignore attribute values needs to be separated by a colon. E.g:

    • ignore="" - Service will be executed on any command origin.

    • ignore="scribe" - commands posted by scribe won’t invoke service registered

    • ignore="scribe,internal" - commands posted by scribe and internally by SR360 won’t invoke service registered

    • no ignore attribute - commands posted by scribe won’t invoke service registered

In the redapp.xml declaration, you can only trigger scripts that are located in the same bundle.

For information about adding active listening to a Sabre Scribe script, see Triggering Sabre Scribe Scripts with Active Listening.

Registering the EMU_RESPONSE Markup Service

Add an EMU_RESPONSE component if your Red App registers a markup service.

Add one Service entity for each markup service that you are registering in your Red App bundle. Add the name, handler_name, and action_code attributes to each Service entity. The Service entities are added as children of CFBundle.

  • name . This is the service context name for the markup service. This value is EMU_RESPONSE. (For more information, see the description of the markup services.)

  • handler_name . This is the class name that is instantiated and used as the service. The class must implement the IService interface.

  • action_code . This is the prefix of the command that the markup service handles.

  • (Optional) ignore . This is a list of command origins that won’t trigger Service registered. If ignore attribute is not present scribe command will be ignored to maintain backward compatibility. Currently, only commands posted by scribe and internally by Sabre Red 360 can be ignored. To ignore multiple command origins ignore attribute values needs to be separated by a colon. E.g:

    • ignore="" - Service will be executed on any command origin.

    • ignore="scribe" - commands posted by scribe won’t invoke service registered

    • ignore="scribe,internal" - commands posted by scribe and internally by SR360 won’t invoke service registered

    • no ignore attribute - commands posted by scribe won’t invoke service registered

        To send Sabre system special characters as action codes, you are required to encode your redapp.xml file as UTF-8. For more information, see Sabre System Special Characters.

Example:

<CFBundle>
    <Service name="EMU_RESPONSE" handler_name="com.sabre.example.markup.MarkupClass" action_code="HOT" ignore="internal" />
<CFBundle>

 

Registering a JavaScript Function as a Service

If your web page Red App registers a JavaScript function as a service, add a Service entry to the CFBundle entity.

Add one Service entity for each markup service that you are registering in your Red App bundle. Add the name, action_code, and handler_name attributes. Add ExternalHandler as a child of Service with the target attribute.

Service

ExternalHandler

  • target .   You define the target. The format is the Editor ID or View ID + the JavaScript function that SRWRuntime calls within the browser + the function that JavaScript will call when it is done processing, separated with a colon (:).

  • force_focus .   This attribute of ExternalHandler handles focus behavior of an open web app.

  • (Optional) ignore . This is a list of command origins that won’t trigger Service registered. If ignore attribute is not present scribe command will be ignored to maintain backward compatibility. Currently, only commands posted by scribe and internally by Sabre Red 360 can be ignored. To ignore multiple command origins ignore attribute values needs to be separated by a colon. E.g:

    • ignore="" - Service will be executed on any command origin.

    • ignore="scribe" - commands posted by scribe won’t invoke service registered

    • ignore="scribe,internal" - commands posted by scribe and internally by SR360 won’t invoke service registered

    • no ignore attribute - commands posted by scribe won’t invoke service registered

The force_focus attribute determines if a web app should gain focus when a registered service is called.

  •         A value of true moves focus to your web Red App in an editor or view .

  •         A value of false does not move focus to the web app. Focus remains on Sabre emulator and the web app remains without focus unless the editor or view needs to be opened when the service is executed.

        If you omit the force_focus attribute, a value of true is assumed.

<Service name="EMU_COMMAND" action_code="HOT"
handler_name="com.sabre.edge.cf.webapp.services.WebViewForwardingService"  status="" desc="">
<ExternalHandler target=" com.sabre.redapp.example.cf.webapp.services.view:process:callback "force_focus=”false”/>
</Service>

For more information, see Registering JavaScript Functions as Services.

Event Publishing in Red Apps

The Event entity publishes a Red App event.

Add an event publishing component if your Red App publishes an event with SRWRuntime.

  • Event. To the RedApp entity, add one Event child entity for each Event ID that your Red App publishes. For information about event publishing, see About Event Publishing in Red Apps.

  • id. In the id attribute, pass the Event  ID. The naming convention for Event IDs that Red Apps publish is as follows:

        Plug-in ID + Event ID.

        Example : com.mycompany.myredapp.eventid

        This naming convention does not apply to Event IDs that Sabre publishes. Currently, the events that Sabre publishes are EMU_COMMAND and EMU_RESPONSE . Please note that EMU_EVENT_001 and EMU_EVENT_002 have been deprecated and EMU_COMMAND event should be used instead.

<RedApp>
  <Event id="pluginID_eventID"/>
</RedApp>

 

Event Listener Registration in Red Apps

Add an EventListener component if your Red App registers an event listener.

It is strongly recommended that you pass a command prefix in an action_code attribute for all event listeners in your Red App. When you add a command prefix, you provide a filter for the specific events of interest. Without a filter, your Red App is notified about every event for the registered event type, such as EMU_COMMAND . For more information about event listening, see About Event Listeners and Event Listening. For more information about action codes in event listening, see Filtering Event Listeners with Action Codes.

To send Sabre system special characters as action codes, you are required to encode your redapp.xml file as UTF-8. For more information, see Sabre System Special Characters.

Important
 You cannot register a service or event listener with the character in action_code. Use the § character in place of .

This topic explains the following:

Generic Asynchronous Event Listener registration

Registering Event Listeners in Web Apps Using JavaScript Functions

Registering Event Listeners with Action Codes to Filter Commands

 

Generic Asynchronous Event Listener Registration

Add an EventListener component if your Red App registers an event listener for the Sabre registered events EMU_COMMAND and EMU_RESPONSE, and for events that other Red Apps publish.

To CFBundle, add one child EventListener entity for each event listener in your Red App bundle. Add the event_filter, handler_class, and state attributes to each EventListener entity.

  • event_filter. Pass the name of the published event. This is either a Sabre published Event ID or an Event ID that a Red App publishes.

  • handler_class. Add the class or executable that is instantiated as the event listener. This class implements IEventListener.

  • state. The value is either PRE or POST. The value tells the communications bus to notify your listener either before or after the actual runtime call.

  • (Optional.) action_code. This is the prefix of the host command for which to listen.

  • (Optional) ignore . This is a list of command origins that won’t trigger Service registered. If ignore attribute is not present scribe command will be ignored to maintain backward compatibility. Currently, only commands posted by scribe and internally by Sabre Red 360 can be ignored. To ignore multiple command origins ignore attribute values needs to be separated by a colon. E.g:

    • ignore="" - Service will be executed on any command origin.

    • ignore="scribe" - commands posted by scribe won’t invoke service registered

    • ignore="scribe,internal" - commands posted by scribe and internally by SR360 won’t invoke service registered

    • no ignore attribute - commands posted by scribe won’t invoke service registered

        To send Sabre system special characters as action codes, you are required to encode your redapp.xml file as UTF-8. For more information, see Sabre System Special Characters.

Example:

<CFBundle>
    <EventListener event_filter="EMU_COMMAND"
    handler_class="com.sabre.example.event.ListenerClass"
    state="PRE" action_code="HOT" />
</CFBundle>

 

Registering Event Listeners in Web Apps Using JavaScript Functions

Add this component to register a JavaScript function as an event listener for a web app in an editor or a view. For the complete details about event listener registration with JavaScript, see Registering Event Listeners in Web Apps with Javascript.

Add the EventListener entity as a child of CFBundle. To EventListener, add the event_filter, handler_class, and state attributes. Add one ExternalHandler as a child element of EventListener, and add the target attribute.

  • event_filter . Pass the Sabre published Event ID or an Event ID that another Red App publishes.

  • handler_class . Pass the handler class for the default implementations of an editor or view.

        The values for handler_class and target vary, depending on whether the web app is in an editor or a view. (See Integrating a Web App Using the Default Editor or Integrating a Web App Using the Default View.)

  • state . Pass the state. This can be PRE or POST. For more information about the PRE and POST states in event listening, see About Event Listeners and Event Listening.

  • action_code . Pass the command prefix for event listening.

        To send Sabre system special characters as action codes, you are required to encode your redapp.xml file as UTF-8. For more information about special characters, see Sabre System Special Characters.

  • target . Pass the ID of the editor or view to open. Add the name of the JavaScript function to call after the colon character (:) in target.

  • force_focus .   This attribute of ExternalHandler handles focus behavior of an open web app.

        The force_focus attribute determines if a web app should gain focus when a registered service is called.

  • (Optional) ignore . This is a list of command origins that won’t trigger Service registered. If ignore attribute is not present scribe command will be ignored to maintain backward compatibility. Currently, only commands posted by scribe and internally by Sabre Red 360 can be ignored. To ignore multiple command origins ignore attribute values needs to be separated by a colon. E.g:

    • ignore="" - Service will be executed on any command origin.

    • ignore="scribe" - commands posted by scribe won’t invoke service registered

    • ignore="scribe,internal" - commands posted by scribe and internally by SR360 won’t invoke service registered

    • no ignore attribute - commands posted by scribe won’t invoke service registered

  •         A value of true moves focus to your web Red App.

  •         A value of false does not move focus to the web app. The app remains without focus unless the View or Editor needs to be opened when the service is executed.

        If you omit the force_focus attribute, a value of true is assumed.

Example

<CFBundle>
    <EventListener event_filter="Sabre published Event ID"
handler_class="handler class for default editor or default view" desc="" state="PRE" action_code="command prefix" >
      <ExternalHandler
target="com.sabre.redapp.example.browser.editor.SimpleBrowserEditor:alert"  force_focus="true"  />
    </EventListener>
</CFBundle>

 

Registering Event Listeners Using Action Codes to Filter Commands

Add this component if your Red App registers an event listener for a specific action code.

This applies to the following events:

  • EMU_EVENT_001

  • EMU_EVENT_002

  • EMU_COMMAND

  • EMU_RESPONSE

Registered listeners for EMU_EVENT_001, EMU_EVENT_002 and EMU_COMMAND are notified only for events that are generated for 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 event should be used instead.

Listeners for EMU_RESPONSE are notified when an event is generated after a response that begins with the prefix in action_code. To send Sabre system special characters as action codes, you are required to encode your redapp.xml file as UTF-8. For more information, see Sabre System Special Characters.

Example

The following example registers a listener for EMU_COMMAND events that are generated for commands that begin with HOT.

<CFBundle>
  <EventListener event_filter="EMU_COMMAND"
    handler_class="com.sabre.redapp.example.cf.event.HotelEventHandler"
    desc="" state="PRE" action_code="HOT" />
<CFBundle>

 

Example of a Complete redapp.xml File

 

<CFBundle>
  <RedApp id="12345678abc">
  <Authorization name="com.sabre.edge.cf.host.Communication" threshold="10" metric="tpm" />
  </RedApp>
  <EventListener event_filter="EMU_COMMAND"
    handler_class="com.sabre.edge.cf.webapp.events.listener.ForceOpenWebViewEventListener"
      desc="" state="PRE" action_code="1">
      <ExternalHandler target="com.sabre.redapp.example.browser.BasicCommunication:alert" />
  </EventListener>
  <EventListener event_filter="EMU_COMMAND"
    handler_class="com.sabre.edge.cf.webapp.events.listener.WebEditorEventListener"
      desc="" state="PRE" action_code="1">
      <ExternalHandler   target="com.sabre.redapp.example.browser.editor.SimpleBrowserEditor:alert" />
  </EventListener>
</CFBundle>

Additional Resources for redapp.xml