Low Fare Shopping (Asynchronous)

AirReqRsp.xsd

Low Fare Shopping (Asynchronous)

An asynchronous Low Fare Shopping call can be made as an alternative to a synchronous Low Fare Shopping call. In the asynchronous call, responses from providers are returned as they become available, instead of waiting until all provider data is obtained to return the entire response.

The asynchronous request allow the client application to process responses as they are returned without waiting for the complete response. After the search is initiated, all search results can later be retrieved using RetrieveLowFareSearchReq (v49.0 and earlier).

Asynchronous Low Fare Shopping requests are often used in conjunction with Point-to-Point shopping, but can be used in a standard LFS request.

Note: Because asynchronous Low Fare Shopping is called similarly to synchronous Low Fare Shopping, see the Low Fare Shopping (Synchronous) topic for details on the request and response elements below.

Schema

See the following transactions for Asynchronous Low Fare Shopping:

Request

  1. Enter the minimum required data for the LowFareSearchReq in the LowFareSearchAsynchReq (v49.0 and earlier) to send an Asynchronous Low Fare Shopping request.
  2. Set @SolutionResult="false" to request Air Price Points (AirPricePointList) in the response. The default is "false" .

    3. Note: The prices in the response are the same, regardless of whether AirPricePointList or AirPricingSolution is returned. See Low Fare Shopping by Air Price Points for details.

    The request is routed to each of the provisioned (default) or specified providers. In addition, for content hubs such as ACH and RCS, the request is routed to the respective suppliers (Low Cost Carriers and rail distributors).

    In all other respects, the asynchronous request and response function the same as the synchronous Low Fare Shopping.

Response

The response is returned in LowFareSearchAsynchRsp (v49.0 and earlier).

The asynchronous Low Fare Search response data has the same structure as the synchronous response, except it includes identifiers for each discrete response that is returned from a provider or supplier.

Provider responses are returned to the client application with a SearchId, a list of providers (ProviderCode), and MoreResults attributes. If MoreResults is "true", a Retrieve Low Fare Search request should be sent.

The AsyncProviderSpecificResponse indicates the total number of responses returned from an individual provider. For example, the following indicates one response from Worldspan, three supplier responses from ACH, and one response from Galileo:

<AsyncProviderSpecificResponse ProviderCode="1P" TotalParts="1"/>

<AsyncProviderSpecificResponse ProviderCode="ACH" TotalParts="3"/>

<AsyncProviderSpecificResponse ProviderCode="1G" TotalParts="1"/>

Rich Content and Branding can be inhibited for Worldspan and ACH providers in the Low Fare Shopping and Asynchronous Low Fare Shopping responses by setting LowFareSearch(Asynch)Req @ReturnBrandedFares="false". If a request contains both ReturnBrandedFares="false" and ReturnUpsellFare="true" for providers 1P, or ACH, the ReturnUpsellFare value is ignored and a warning is returned.

Next Steps

All responses are cached for data retrieval. To retrieve subsequent response data, send a Retrieve Low Fare Search request and include the SearchID and ProviderCode from the Asynchronous Low Fare Shopping response.

Exceptions

Worldspan does not support Air Price Points functionality. See Low Fare Shopping by Air Price Points and AirPricingSolution in Low Fare Shopping (Synchronous) for more details.

Direct Access or neutral availability. Neutral availability is the default, which means the Worldspan provider applies its default availability logic. With neutral availability, Worldspan first accesses the supplier using the highest level of participation contracted between Worldspan and that supplier. For suppliers that maintain a Direct Access relationship with Worldspan, the first attempt to access a supplier will be through Direct Access. If Direct Access is desired, set @AllowDirectAccess="true" in SearchAirLeg/AirLegModifiers. AllowDirectAccess can be set in any AirLegModifiers element, but the first element is preferred. If AllowDirectAccess is not set or is false, neutral availability is used.

  • ACH does not support PermittedBookingCodes or ProhibitedBookingCodes in AirSearchModifiers. If these modifiers are used, a warning message is sent in the response.
  • ACH does not support search modifiers at the Air Leg level. If any AirLegModifiers are sent in an ACH request, a warning is returned and the request is processed without the modifiers. The exception is AirLegModifiers/PreferredCabins, which, when sent, applies the cabin preferences to all legs in the request.
  • ACH carriers require a host token in Low Fare Shopping requests to identify a transaction session. At least one of UniversalRecordLocatorCode, ProviderLocatorCode, or CarrierLocator code must be provided in AirExchangeModifiers.
  • In Air v35.0 and later, the @ConsolidateFareRemarks attribute, when set to True, provides a consolidated list of fare remarks instead of returning an individual fare remark for each fare. Available only for Air Canada.

See Rail Low Fare Shopping for rail-specific details.