Capacity Planning

All capacity planning decisions should initiate from the projected scope and requirements of the client application. Capacity relates to the functionality of three basic components:

• The design and required functionality for the client application.

• The size and type of network connection.

• The expected volume of Web Service calls is the key factor in capacity planning. Issues for determining expected volume include:

• The expected look-to-book ratio between requests to Universal API and actual bookings.

• The expected number of sessioned vs. session-less transactions.

• The types of Web Service calls planned, and their expected message sizes.

Client Application

All capacity planning decisions should initiate from the projected scope and requirements of the client application. Answering the following questions may assist in formulating capacity requirements:
 

What is the expected volume of Web Service calls?

The anticipated number of transactions with Universal API directly influences the number of Web Service calls. The following questions can help to determine the expected volume.
 

What is the expected look-to-book ratio, i.e., the number of requests made to Universal API before a customer actually makes a reservation?

The actual look-to-book ratio for a client application can vary greatly depending on a number of design and business factors. For example, the ratio for leisure web sites with public access is typically much higher than for a proprietary corporate application because users may be more likely to shop extensively for low fares and to receive less direct user support.
 

What are the type of web service calls planned, and their expected message sizes?

The type of transaction directly affects the message size. For example, flight availability and faring transactions require significantly more data than car availability and pricing transactions. The average message sizes may vary greatly depending on the business requirements for a client application.
 

What is the average duration of individual transactions?

In addition to the message size, the expected duration of a particular transaction can affect capacity planning. As with message sizes, the typical duration of a transaction can vary greatly depending on the business requirements and usage of a client application. The duration of a given transaction can be affected by a variety of factors, including: network connection times, processing time by Universal API, processing time by the provider, and (when applicable) the internal processing time processing time by a supplier.

The effect of these extended-duration transactions can potentially skew the average duration of transaction times, and significantly impact specific transaction times during peak transaction times for that supplier. Therefore, sufficient research and testing should be made to include potential supplier-specific concerns for transactions that rely on a direct link to supplier data.

Calculating Message Charges

Travelport counts message charges by request. The number of solutions in a response does not affect the transaction count.

For example, search for journeys on Qantas:

Journey 1: SYD to MEL, Sun 7 Oct 2013

Journey 2: MEL to SYD, Mon 8 Oct 2013

Journey 1 has 26 available flights, and each flight has four available fares.

Journey 2 has 34 available flights, and each flight has four available fares.

If the itinerary is found and priced using the Air Availability Search (AvailabilitySearchReq) request and then a follow-on Air Pricing request (AirPriceReq), each air availability call is counted and then each pricing call is counted.

This means 242 API calls are counted:

• Two AvailabilitySearchReq calls, one for each journey.
• 240 AirPriceReq calls, one for each fare for each flight.

If the itinerary is found and priced using Low Fare Shopping (LowFareSearchReq), two API calls are counted: one for Journey 1 and one for Journey 2. The example could be sent as two one-way requests or one round trip (one for each journey at Tier 1).