How PNRQueueAndRetrieve eBL Works

PNRQueueAndRetrieve eBL receives one or multiple queue numbers (up to 10) for PNR/BF's on the that have not been end-transacted, in the form of an XML document. The request is initially validated against the request schema, then each queue is sent to the appropriate host system to QEP a PNR. Upon successful completion of the QEP, the PNR is retrieved and returned to the client, and expanded into the AAA. The PNR is saved and displayed.

The response XML document contains the PNR/BFs in the same order as they appeared in the request. If an error occurs for any queue, an error message replaces the queue information in the response for that queue.

PNRQueueAndRetrieve eBL Request

The request is a list of flights that are sent as an XML document. The basic high-level detail is as follows:

PNRQueueAndRetrieveRequest

queue

queueNumber

queueNumber

...

Additional requested queues are listed as necessary.

Flight Information eBL Response

The response is an XML document that displays the requested PNR/BFs in the order of the request. The PNR/BF data is then either "real-time" or "scheduled". An attribute named “source” on each <Flight> element in the response contains the code of the airline that supplied the data, if the data is real-time flight information. If the data is only schedule information, then this attribute contains the word “schedule”. Scheduled information is returned if the link with the airline is down or busy or if that airline is not supported.

Many airlines do not update their gate information, so that field is often empty or non-existent.

If any flights incurred an error, the error is listed in the position of the flight. Errors are formatted in the standard GWS error format. The basic high-level detail is as follows:

Flights

Flight

Airline

Number

Origin

Destination

Date

Source

Departure and arrival time variances and reasons

Gate information

Intermediate stop information

Meal information

Equipment type

Free-form message text as provided by the host

For flight

For cities

Error – embedded as applicable in position where flight information would have existed had an error not been encountered

Additional flights/errors repeated as necessary

Decode section

Decoding

The Flight Information eBL response contains a decoding section at the end of the XML document. This section lists all codes in the response and their decoded text. Decoding is performed by calling the Travel Codes Translator. All airlines, cities, and aircraft types are decoded and included in the decode section at the bottom of the request. The client can then correlate the decoded items in this section to the codes in the Flight Information eBL response. Duplicate codes only appear once in the decode section. For example, if you are requesting flight information for three different Air Canada flights, Air Canada is decoded once in the decode section.

Profiles

The user sends two profiles in the request, one for Apollo and one for Galileo. Flight Information eBL contains the business logic to determine which profile to use for which airline. Users that have a profile for only one host, or neither, are given a Flight Information-only profile for the hosts, to which they do not already have regular access.

Flight Information-only profiles are specific to Flight Information eBL and cannot be used with XML API or Reservation Builder. However, if customers have a Host Access Profile (HAP), that profile can be used for Flight Information eBL.