Overview

An orchestrated API easily automates the process of a commonly performed business function or workflow. Sabre’s Orchestrated APIs bundle several functions/operations into a single web service call. This type of API consists of transactions that are mapped to individual web services, and executed either sequentially, in parallel, or both.

An example of how a single orchestrated service request is fulfilled by executing multiple web service requests is illustrated in the following execution model of an orchestrated service.

A single service request call will provide you with a response that retrieves your content and performs the processing seamlessly.

By using orchestrated services, customers can develop client applications faster and may see an improvement in the overall response time to offer a better customer experience.

Benefits of Orchestrated Sabre APIs

• Applications can be deployed to production quickly. By using pre-bulit workflow functions that have been architected and designed to work together, development time and quality assurance is reduced; shortening the time to place an application into production.

• Integration costs are lowered. Orchestrated services reduce development complexity, letting clients accomplish more with a single service call.

• The learning curve is shortened. Those new to the travel industry or web services can use these services more easily than low-level services.

• Gain access to content and business logic across multiple Sabre data sources. Orchestrated APIs obtain content from multiple sources and orchestrate business logic, shielding clients from making multiple points of entry to various systems.

• Improved response time. By avoiding the round-trip latency inherent with multiple individual low-level service calls to perform a function, responses are faster.

• Improved bandwidth utilization. The HTTP overhead associated with multiple low-level web service calls are avoided, which results in an improved use of bandwidth.

• Improved end-to-end performance. An orchestrated web service gives clients an oppurtunity to optimize existing applications.

• Ability to adapt changing market needs quickly. Build new products and services faster by integrating an orchestrated service versus multiple service calls.

• Most of the operations available in an orchestrated API are optional. You have the flexibility to control which operations are to be executed, allowing you to mix and match functions to meet your specific needs.

• The client application that is consuming orchestrated services has the flexibility to control the error/exception processing during the execution of the low-level services within the orchestrated service. Client applications can halt the executon of subsequent service operations by setting the HaltOnError attribute at the root request element.

• Each orchestarted request and response is designed so that individual calls are delineated by an st:element, which can be used to associate with XML nodes and specific low-level calls. Client applications can then easily identify the offending node using the st:element returned in the error message.

Orchestrated APIs Overview

Message Processing

EnhancedAirBookRQ and PassengerDetailsRQ offer clients several options for controlling what happens when errors are encountered:

1. …/HaltOnError flag
2. …/IgnoreOnError flag

HaltOnError Flag

This flag defaults to false. The HaltOnError flag takes the form of the …/HaltOnError attribute located at the root element of the request message. This attribute controls whether or not processing of the orchestrated service is stopped if an error is encountered while an operation processes.

Request Example (Child)

In this request, the client application opted to set the …/HaltOnError attribute to true.

This means that if any operation fails during invocation, the orchestration engine will recognize the failure and halt any subsequent requests/processing.

IgnoreOnError Flag

The client application can utilize the …/IgnoreOnError element/attribute pair to ignore the entire transaction if an error is encountered during the process.

Notes:

• The …/IgnoreOnError flag works only when the transaction is stopped due to an error, hence it is combined with the …/HaltOnError attribute.
• It is possible that the ignore operation may fail, so the client application needs to check the response to ensure that it is succeeded.

IgnoreAfterFlags

When IgnoreAfterFlags are set to true, the API ignores the whole transaction at the end of the flow. The API then utilizes the IgnoreTransactionLLSRQ API when an error or warning is encountered, and are merged into application results. By default, this value is false.

Recovery From Previous Entry Active Error

Sometimes asynchronous processing in Sabre or airline backend systems may not finish in a timely manner. In such situations the host replies with a PREVIOUS ENTRY ACTIVE error.

Orchestrated services detect this error and retry requests. Three (3) retry attempts are made in one second time intervals.

Fatal Errors

There are two kinds of fatal errors which stop the processing regardless of the values set via the …/HaltOnError attribute or the …/IgnoreOnError@Ind element/attribute:

Timeout: Each Orchestrated Sabre API is set to time out at two (2) minutes. The timeout can be decreased by defining the soap-env:Envelope/soapenv:Header/eb:MessageHeader/eb:MessageData/eb:Timeout value in the request (in seconds). However, we do not recommend that clients utilize this functionality, because it could cause premature errors if the back-end content systems are slow to respond.

Internal Error: When an error occurs outside of the operations specified in the Orchestrated API message, it is considered to be an internal error. A good example of this sort of error would be a connection refused error encountered when the orchestration engine is communicating with back-end content systems.

Internal Vs Provider Error / Warning

Whenever a scenario occurs where the application needs to inform the user of any errors or warnings encountered, the processing will be as follows:

There will always be a single error tag within the response:

There can be multiple warning tags:

There can be two types of errors/warnings: SP.PROVIDER_ERROR or SP.INTERNAL_ERROR.

Internal error points to an issue within the SP application itself, whereas Provide errors always points to issues from within the low-level (LLS) APIs the orchestration API calls.

Enhanced End Transaction

The below APIs have an internal call to EndtransactionLLSRQ implemented:

 - PassengerDetailsRQ
 - CreatePassengerNameRecord
 - AirTicketRQ
 - ExcahngeBookingRQ

The orchestrator will attempt to recover from the ET errors using the following logic:

1. When EndTransactionLLSRQ returns DIRECT CONNECT MESSAGES RECEIVED, - ENTER *A OR *IM, the orchestrator will call SabreCommandLLSRQ to send *IM.

The below warning messages will be appended to the final response payload to inform the user of this activity:

WARN.SWS.HOST.WARNING_RESPONSE - EndTransactionLLSRQ: DIRECT CONNECT MESSAGES RECEIVED - ENTER *A OR *IM WARN.SP.BUSINESS_WARNING - Required request to display itinerary messages.

2. When EndTransactionLLSRQ returns with any other error message, the orchestrator will send a second EndTransaction request omitting the Source/@ReceivedFrom element to attempt to bypass the error/warning.

A warning message will be appended to the final response payload to inform the user of this activity:

WARN.SP.PROVIDER_ERROR - Unable to perform first end transaction.

3. If the second call succeeds, the flow is continued.

4. If the second call fails, the orchestrator will return the error back to the user.