How to Filter Sabre PNRs by PCC Without Client-Side Overhead

by

Summary

A developer attempted to retrieve a specific subset of Passenger Name Records (PNRs) created by a single Pseudo City Code (PCC) using the Sabre Trip_SearchRQ API. The implementation failed because the developer’s attempt to use ReservationCriteria and PosCriteria resulted in zero matches, while using EmailCriteria returned an unfiltered, massive dataset that bypassed other logical constraints. The goal was to find a way to filter strictly by HomePseudoCityCode without incurring the massive overhead of fetching all data and filtering client-side.

Root Cause

The failure stems from three distinct technical misunderstandings regarding the Sabre GDS search engine logic:

  • Filter Precedence and Logic Disjunction: In many GDS SOAP APIs, applying multiple criteria (like Email + PCC) often acts as an OR operation or follows a hierarchy where the most specific/intensive filter (Email) takes precedence, effectively nullifying the restrictive filters (PCC/Date).
  • Attribute Mismatch: The developer attempted to use <Source> within <ReservationCriteria> to represent the PCC. In Sabre’s schema, Source and HomePseudoCityCode are not interchangeable; Source typically refers to the entry medium or specific booking channel, not the originating PCC.
  • Schema Misapplication: The Trip_SearchRQ is designed for “Trip Discovery” (finding a passenger’s journey) rather than “Inventory Auditing” (finding all records owned by a specific office). Using a search tool for an auditing use case leads to inefficient query planning on the server side.

Why This Happens in Real Systems

This is a classic case of Schema Impedance Mismatch. In complex, legacy-integrated distributed systems:

  • Overloaded APIs: Single endpoints are often designed to serve multiple personas (Travel Agents, End Users, and Aggregators). A filter that works for a “Search by Email” use case is optimized for different database indexes than a “Search by PCC” use case.
  • Implicit Filtering Rules: Documentation often fails to specify whether criteria are joined by AND or OR logic. When the underlying engine sees an EmailCriteria, it may pivot to a global index that ignores the narrower PosCriteria to ensure “completeness” for the user.
  • Index Selectivity: Databases prioritize high-selectivity indexes (like Email). If the engine decides the Email index is the primary entry point, it may return the full result set of that index before applying the secondary, low-selectivity filters like PCC.

Real-World Impact

  • Performance Degradation: Attempting to “filter client-side” after receiving a billion records leads to OOM (Out of Memory) errors and massive latency.
  • Increased Operational Costs: In cloud-native environments, the egress costs for transferring massive, unnecessary XML payloads can be astronomical.
  • Data Inconsistency: Relying on Async table views without understanding the eventual consistency model can lead to “missing” PNRs in reports, as the async buffer might not be fully hydrated at the time of the request.

Example or Code (if necessary and relevant)

The problematic XML structure identified in the postmortem:


  
    
  
  
    {{PCC}}
  
  
    {{COMPANY_EMAIL}}
  
  
    {{PCC}}
  
  
    
      HEADER
      NAME

How Senior Engineers Fix It

A senior engineer would move away from the “Search” paradigm and toward the “Reporting/Auditing” paradigm:

  • Identify the Correct Service: Instead of Trip_SearchRQ (a discovery API), they would look for Agent Activity Reporting or Queue Management APIs specifically designed to track PCC-originated transactions.
  • Use the Correct Identifier: They would verify if the API supports a direct HomePCC filter or if the data must be extracted via a Data Warehouse/ETL process rather than a real-time transactional API.
  • Implement Pagination and Batching: If a search is mandatory, they would ensure the request uses strict Pagination tokens and enforces a hard limit on the server-side to prevent massive payload returns.
  • Validate Logic via Mocking: Before deploying, they would test the XML against a sandbox to confirm if the logic is AND or OR by sending overlapping and non-overlapping criteria.

Why Juniors Miss It

  • Literal Interpretation of Documentation: Juniors tend to assume that if a field is provided in the schema, adding it to the request will act as a strict AND filter.
  • Focusing on Syntax over Semantics: They spend time fixing the XML structure (syntax) rather than questioning whether the API is the right tool for the business requirement (semantics).
  • Ignoring System Constraints: They often assume “the cloud can handle it,” attempting to fetch large datasets and filter them in application code, which ignores the network latency and memory overhead of processing large XML blobs.

Leave a Comment