Exchange Shopping Request XML
This chapter provides detailed information about select portions of the XML request that may need additional explanation beyond what is described in general information and schema annotations, as well as sample Exchange Shopping requests for different business scenarios.
Note: This chapter is intended as a supplement to the Exchange Shopping schema definition available in Dev Studio.
|Attribute||Description||Exchange Shopping Path|
|XML version||Required in the XML schema||ExchangeShoppingRQ/@Version|
|Element||Description||Exchange Shopping Path|
|Header||Standard header information||ExchangeShoppingRQ/Header|
|One of the possible optional Header attributes|
|Default timeout override||Header element includes the attribute that allows the user to override the default timeout. When sent, this will be the time after which Exchange Shopping will try to stop processing the transaction. However, if the system is in the middle of processing in one of the subsystems, the timeout may occur after the timeout sent by the user.||ExchangeShoppingRQ/Header/@ttl|
|Request XML elements|
|Point of Sale (POS)||Point of sale and agent requesting the Exchange Shopping transaction. This data must match the data that will be used in the subsequent exchange transaction to ensure the cost of the exchange does not vary.||ExchangeShoppingRQ/POS|
|Ticketing provider code||Two-character code of the partition on whose behalf the Exchange Shopping transaction is performed. Agency customers should use the value “1S or 1B”||ExchangeShoppingRQ/TicketingProvider|
|Passenger information||Details about passengers and the flight documents to be changed||ExchangeShoppingRQ/PassengerInformation|
|Travel itinerary information||Details about the requested travel itinerary, including portions of travel (and related segments) that should remain unchanged (legs not shopped).||ExchangeShoppingRQ/OriginDestinationInformation|
|Travel preferences||Additional shopping criteria to be used when searching for alternate options. Optional qualifiers are described in “Optional Search and Pricing Parameters”||ExchangeShoppingRQ/TravelPreferences|
|Diagnostic||Reserved for internal Sabre use only||ExchangeShoppingRQ/Diagnostic|
Elements of the Exchange Shopping Request
This section provides more details about select portions of the Exchange Shopping request that may require additional explanation.
Point of sale
The following elements identifying the Point of Sale are required in the Exchange Shopping request. These elements are optional in the XML schema; however they are verified at the business rule validation layer.
|Element||Description||Example||Exchange Shopping Path|
|Pseudo||Three-letter pseudo city code||G7HE||ExchangeShoppingRQ/POS/Pseudo|
|Shopping path||Allows the point of sale to specify the attribute that is used to determine shopping rules selection. The value of request type attribute passed by Point of Sale identifies the Shopping rule that should be applied during Exchange Shopping transaction. If there is no specific Shopping rule that the Point of Sale wants to apply, it is recommended to send the value “TNEXC”.||TNEXC||ExchangeShoppingRQ/POS/ShoppingPath/@requestType|
This part of the Exchange Shopping XML request is used to specify details about the passengers requesting the change.
A maximum of nine (9) passengers may be included in a single Exchange Shopping request, which means up to nine repetitions of this data set are supported.
The PNR status will dictate the required data set.
Passenger with an Active PNR
The following elements are required when the passenger has an active PNR.
|Element||Description||Example||Exchange Shopping Path|
|PNR locator||All passengers in the request are not required to be booked in the same PNR, however the requested itinerary must match for all passengers in the request. If all passengers are not booked in the same PNR, it is the responsibility of the user to correctly handle the rebooking process. Not mandatory||YTRBDE||ExchangeShoppingRQ/PassengerInformation/PassengerWithPNR/@pnrLocator|
|Reference Number||Passenger reference number as reflected in the PNR. Not mandatory||1.1||ExchangeShoppingRQ/PassengrInformation/PassengerWithPNR/@referenceNumber|
|Passenger name||Full first and last name as reflected in the PNR. Mandatory||ADAM JONES||ExchangeShoppingRQ/PassengerInformation/PassengerWithPNR/@firstName ExchangeShoppingRQ/PassengerInformation/PassengerWithPNR/@lastName|
|Document number||Ticket number to be changed. If the document in the request is a conjunctive ticket, e.g. 1234567890-91, only the number of the first ticket should be passed in the request (e.g.1234567890). If the name in the request does not match the name on the provided document, the transaction will still be processed, and a warning will be added when returning the options. It will be at the user’s discretion to display the options to the customer or fail the transaction.||1231234567890||ExchangeShoppingRQ/PassengerInformation/PassengerWithPNR/DocumentNumber|
Passenger without an Active PNR
|Element||Description||Example||Exchange Shopping Path|
|This element is not currently supported and is planned for future versions of the service.||N/A||N/A||N/A|
Travel Itinerary information
This section of the XML request provides information about the requested travel itinerary and focuses on mandatory elements for specific business scenarios.
Types of Legs in the Exchange Shopping Request
There are three types of legs (O&Ds) which will require a different data set depending on what changes are requested:
- Not shopped
- Shopped with same connections
All three types of legs can be combined within a single Exchange Shopping request.
Exchange Shopping Xpath ExchangeShoppingRQ/OriginDestinationInformation
Not Shopped Leg
Full information about the segments in the PNR that should be included on the new ticket must be included in the request, as the Exchange Shopping service does not access the PNR to verify details.
Exchange Shopping Xpath ExchangeShoppingRQ/OriginDestinationInformation/@shopIndicator = “false”
Required Information for Not Shopped Leg
If the leg is not shopped, details about all related segments pertaining to this leg are required. If no flight segment information is provided for the leg, an error message will be returned, and the transaction will be terminated.
The following flight segment information elements from the PNR are required for the leg that is not shopped:
|Operating carrier||Two-character alphanumeric code for the operating carrier of the flight segment||XX||ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@operatingProvider|
|Marketing carrier||Two-character alphanumeric code for the marketing carrier of the flight segment||YY||ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@marketingProvider|
|Flight number||Numeric marketing flight number||6130||ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@marketingFlightNumber|
|Departure airport||Three-character departure airport of the flight segment||LHR||ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@startLocation|
|Arrival airport||Three-character arrival airport of the flight segment||PHL||ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@endLocation|
|Reservation booking class||Code for the reservation booking class||S||ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@bookingClass|
|Reservation status||Reservation status as in the PNR||HK||ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@reservationStatus|
|Departure date/time||Flight segments departure date and time||2017-05-20T12:40:00||ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@startDateTime|
|Arrival date/time||Flight segment arrival date and time||2017-05-20T15:25:00||ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@endDateTime|
|Booking date/time||Flight segment booking date and time||2017-05-10T04:08:00||ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment/@bookingDateTime|
Sample XML Request with Not Shopped Leg
The passenger would like to keep the first leg of the journey and exchange only the return (PHL-LHR), which means the outbound leg (LHR-PHL) is not shopped.
1 AA6130S 20MAY 6 LHRPHL HK1 1240 1525 /DCAA*NSSUOV /E
OPERATED BY BRITISH AIRWAYS
2 AA6129S 26MAY 5 PHLLHR HK1 1830 0635 27MAY 6
Details of not shopped leg in the Exchange Shopping request:
<ExchangeShoppingRQ xmlns=“http://services.sabre.com/sp/exchange/shopping/v2" xmlns:n0=“http://services.sabre.com/sp/exchange/shopping/common/types/v2" xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance" version=“2.2.0"> <STL_Header.RQ ttl=“300"> <OrchestrationID seq=“0">027364343467758035</OrchestrationID> </STL_Header.RQ> <POS> <Pseudo>G7HE</Pseudo> <Actual>DFW</Actual> <ShoppingPath requestType=“TNEXC" bookingChannel=“TN"/> </POS> <TicketingProvider>1S</TicketingProvider> <PassengerInformation> <PassengerWithPNR pnrLocator=“DNANZS" referenceNumber=“1.1" firstName=“MARK" lastName=“JONES"> <DocumentNumber>0017944161064</DocumentNumber> </PassengerWithPNR> </PassengerInformation> <OriginDestinationInformation shopIndicator=“false"> <DateTimeSelection> <DepartureDate>2017-05-20</DepartureDate> </DateTimeSelection> <StartLocation>LHR</StartLocation> <EndLocation>PHL</EndLocation> <RelatedSegment operatingProvider=“XX" marketingProvider=“YY" marketingFlightNumber=“6130" startDateTime=“2017-05-20T12:40:00" endDateTime=“2017-05-20T15:25:00" startLocation=“LHR" endLocation=“PHL" bookingClass=“S" reservationStatus=“HK" bookingDateTime=“2017-05-10T04:08:00"/> </OriginDestinationInformation> <OriginDestinationInformation shopIndicator=“true"> <DateTimeSelection> <DepartureDate>2017-05-26</DepartureDate> </DateTimeSelection> <StartLocation>PHL</StartLocation> <EndLocation>BWI</EndLocation> </OriginDestinationInformation> </ExchangeShoppingRQ>
Shopped Leg combined with “Use Same Connections” Parameter
If the leg is shopped AND the “Use Same Connections” parameter is used for this leg, only itinerary options for the indicated city pair and travel dates connecting through the same airports as already ticketed will be searched. Full details are required for related segments in the request.
Exchange Shopping Xpath ExchangeShoppingRQ/OriginDestinationInformation/@shopIndicator=“true” and ExchangeShoppingRQ/OriginDestinationInformation/@preserveConnectionsIndicator=“true”
Shopped Leg NOT combined with “Use Same Connections” Parameter
When a leg is shopped but the “Use Same Connections” search parameter is not applied, no related flight segment details are required. These details will be ignored if included in the request.
Exchange Shopping Xpath ExchangeShoppingRQ/OriginDestinationInformation/@preserveConnectionsIndicator=“false” or is not sent at all
Information on the Leg Level
The following elements need to be passed for the leg that is not shopped:
|Element| Description| Exchange Shopping Path| |Start Location| Three-letter airport or city code where portion of travel should begin| ExchangeShoppingRQ/OriginDestinationInformation/StartLocation| |End Location| Three-letter airport or city code where portion of travel should end ExchangeShoppingRQ/OriginDestinationInformation/EndLocation| |Departure or arrival date or date and time| Departure or arrival date or date and time when portion of travel should start or end. |ExchangeShoppingRQ/OriginDestinationInformation/DateTimeSelection/DepartureDate ExchangeShoppingRQ/OriginDestinationInformation/DateTimeSelection/DepartureDateTime ExchangeShoppingRQ/OriginDestinationInformation/DateTimeSelection/ArrivalDate|
Note: All other search and pricing parameters are optional.
Maximum Number of Legs vs. Maximum Number of Segments
The maximum number of legs (O&Ds) supported is ten (10). The maximum number of segments supported is sixteen (16). If a leg is shopped and the “Use Same Connections” parameter is not applied, that leg is counted both as one leg and one segment.
Exchange Shopping Xpath for Leg ExchangeShoppingRQ/OriginDestinationInformation
Exchange Shopping Xpath for Segment ExchangeShoppingRQ/OriginDestinationInformation/RelatedSegment