Enhanced Air Ticket - REST

Enhanced Air Ticket - SOAP

The AirTicketRQ API allows client applications to:

• Issue multiple Air Tickets and EMDs within a single call
• Issue multiple PQRs in one call
• Issue more than one PTC in the same transaction with installments
• Integrate printer address designation/un-designation
• Manage sessions on behalf of the client application
• Manage error handling to ensure the successful issuance of an Air Ticket
• Return newly issued ticket numbers together with additional details pertaining to specific documents
• Handle Context change/AAA (modify target city)
• Delete air accounting lines prior to ticketing

Workflow

The API performs several steps to issue a single ticket or multiple tickets:

1. Performs an ignore transaction to ensure that the AAA is clear.
2. Handles context change/AAA (modify target city).
3. Validates the existence of an AUTOEND/AUTOER TJR flag.
4. Designates printers.
5. Retrieves an existing reservation using the record locator provided within the payload.
6. Deletes accounting lines prior to ticketing, and issues a single ticket (ETR/EMD/PQR) or multiple tickets.
7. Ends transaction and commits the tickets to the face of the PNR (this step is omitted when the AUTOEND/AUTOER TJR flag present).
8. Retrieves newly generated ticket details.
9. Undesignates printers.
10. Performs ignore transaction after the transaction to ensure that the AAA is clear.

Single Call Strategy

A single ticketing instruction (single call to AirTicketLLSRQ) is generated by sending a single instance of /AirTicketRQ/Ticketing.

The API follows the workflow below:

1. Sends a single call to low level service, AirTicketLLSRQ.
2. If the TJR setting is on (AUTOEND/AUTOER), the issued ticket is automatically committed to the PNR. The EnhancedEndTransactionRQ call is omitted.
3. Attempts to retrieve the newly issued ticket details by calling the low-level API, TicketingDocumentServicesRQ.
4. When all ticket details have been collected, attempts to undesignate all previously designated printers, ignores the transaction (to clean the session), and reverts the target city if previously specified within the request payload.

Refer to the diagram below for more details:

Issuing Multiple Tickets

To issue multiple tickets/ticket types, send the …/AirTicketRQ/Ticketing element within the request payload as many times as there are tickets are to be generated.

The AirTicketRQ API will then perform a single ticket issuance (as described in the above paragraph) and attempt to perform the steps below:

1. Ignores the transaction to clear session data.
2. Retrieves the reservation.
3. Performs a single call to the low-level service, AirTicketLLSRQ.
4. If the TJR setting is on (AUTOEND/AUTOER), the issued ticket is automatically committed to the PNR. The EndtransactionLLSRQ call is omitted.

If there is more than one ticket to issue, the above steps are repeated for each …/AirTicketRQ/Ticketing element within the request payload. When the process is completed, the API attempts to retrieve the newly issued ticket details by calling TicketingDocumentServicesRQ.

See the diagram below for more details:

Handling Mask Scenarios

There are a number of mask scenarios that can be triggered during ticket issuance. The ones that are handled by the Orchestrated Ticketing API are:

UNABLE TO TICKET STORED FARE - PQ EXPIRED – handled by /AirTicketRQ/PostProcessing/@actionOnPQExpired

VERIFY TKT TTL (*) TICKET – handled by /AirTicketRQ/PostProcessing/@acceptPriceChanges

UNABLE TO TICKET STORED FARE - NEGOTIATED FARE STORED – handled by /AirTicketRQ/PostProcessing/@acceptNegotiatedFare

UNABLE TO TICKET STORED FARE - PQ CONTAINS BACK DATE PRICE - handled by /AirTicketRQ/PostProcessing/@actionOnBackDatePrice

Note: If you do not specify an action on any of the above scenarios, the system will automatically accept price changes and/or reprice the booking if a mask is triggered.

Error Handling

The AirTicketRQ API will attempt to recover from minor errors, but if it encounters a critical error, the service responds with the following message:

This message means that all low-level AirTicketLLSRQ calls (or one, in the event of a single ticket transaction) failed, and that the application was not able to issue any tickets.

Additionally, the orchestration engine will collect error messages coming from low-level services to indicate which specific ticketing transaction (a specific instance of /AirTicketRQ/Ticketing) failed and which low-level service triggered it:

There is a possibility that all AirTicketLLSRQ calls are successful (all tickets were issued), but the application was unable to receive a successful response from TicketingDocumentServicesRQ (newly created ticket details could not be retrieved).

In this case, the API will return:

To remedy this, retrieve the reservation using UpdateReservationRQ to check if the new tickets are within the PNR.

If there are errors from low-level services that did not prevent the API from collecting new ticket details, these errors are passed within the Warning element.

Understanding "Simultaneous Changes" Message

During the commit stage (when a newly issued ticket is in the process of being pushed onto the face of the PNR) the warning message SIMULTANEOUS CHANGES TO PNR - USE IR TO IGNORE AND RETRIEVE PNR may appear.

When this warning is returned, the system did not immediately update the PNR with the ticket data. If the system is able to retain it, the API will update the PNR with the ticket information approximately 15 minutes after the message occurs.

We recommend reviewing the agency audit trail (using DailySalesReportLLSRQ) and validating the PNR information (using GetReservationRQ). If the ticket number does not appear in the GetReservationRQ response, but displays in the agency audit trail (DailySalesReportLLSRQ response), we recommend voiding and re-issuing the ticket.

Ghost Ticket Validation

Starting with version 1.2.1, Enhanced Air Ticket validates the existence of ghost tickets.

Ghost tickets occur when, after ticket issuance, newly created tickets are not pushed to the Sabre reservation system (PNR). Because the Sabre and airline databases are not synchronized, the customer's reservation may not show any new documents, but they do exist in the airline database. This may result in Advance Debit Memos issued by the carrier against an agency.

In order to avoid ghost tickets, Enhanced Air Ticket has introduced two strategies:

Sleep Mechanism

Adds a sleep mechanism for common scenarios that may drive the creation of ghost tickets. Common scenarios include things like issuing multiple price quote records in one transaction, issuing from F line, and more.

In these cases, the system adds a delay prior to committing new tickets to the reservation. This additional time allows both databases to synchronize.

This is an automatic process not controlled by the user.

Reservation Display Validation

Introduces reservation display validation, which checks if newly issued documents appear on the face of the PNR.

This process is controlled by the user via the /AirTicketRQ/PostProcessing/GhostTicketCheck/@waitInterval and @numAttempts attributes.

Both attributes are meant to control the number of reservation redisplays and time intervals that happen in-between. After exhausting the specified redisplay limit, the response will indicate whether the document has been found in the Sabre reservation by means of setting AirTicketRS/Summary/@committed to true.