Sunny Cars CarRentalAgentService Version 2.0 - SDK

June 2009, Lorenz Christian

Table Of Contents

1. Introduction
• Target Audience
• Prerequisites
• Requirements
• Code Samples
2. Getting Started
• Web Service Structure Overview
• The Service Component
• The Interface Component
3. Service Procedures
• Authenticate
• Locate
• Evaluate
• Delineate
• Operate
4. Appendix
• Error & Warning Codes
• Notes

Introduction

This is the common Web Service interface for car rentals provided from Sunny Cars. You can use this Web Service to integrate car rental offers into your applications as well as submitting and managing car rental reservations from and to Sunny Cars.

This Web Service is intended to be used by Sunny Cars Partners, Tour Operators, Travel Agencies and third party booking engines. The CarRentalAgentService is a protected Web Service. Consumers of this service will have to subscribe to it. For detailed information about a service subscription please contact the Sunny Cars IT Division:

Sunny Cars AG - IT Division, Paul-Gerhardt-Allee 42, D-81245 Munich, Telephone: +49 - 89 - 82 99 33 90, Email: it@sunnycars.com

Using CarRentalAgentService, you can find car rental locations, query services for specific car rental locations, query car rental rates, create car rental reservations and manage car rental reservations.

Target Audience

The primary audience for this SDK are developers and managers from tourist industry, who are interested in integrating Sunny Cars products into their services, web site or business application.

Prerequisites

In order to use the Web Service discussed and described in this SDK, you should verify that following prerequisites and system requirements are met:

Requirements

The CarRentalAgentService interface supports two seperate technical communication protocols consumers can utilize interface functionality:

Moreover, the client consuming the Web Service should be able to consume the resulting Web Service responses programmatically. In case you are going to use SOAP communication, it is most likely that your programming language or environment supports the SOAP protocol.

Alternatively, you may use the HTTP-POST communication to utilize the Web Service. For this your client environment should be able to communicate through HTTP1.0/1.1 protocol and be able to parse and process an XML response.

Some methods of the CarRentalAgentService require cryptographic security. To safely implement the security techniques required to communicate with the Web Service, your client programming language/environment must be able to:

Code Samples

All code samples in this SDK are written in C# using the Microsoft .NET Framework 1.1. You might want to use a different implementation language. Naturally, all languages have different syntax, classes and environments. Nevertheless, the samples herein should give you a good understanding on how this Web Service works and what tasks are neccessary to implement a client for it.

Getting Started

Web Service Structure Overview

First, it is essential to understand the Web Service structure and its parts before starting to implement a client. The CarRentalAgentService is implemented as Microsoft .NET (Framework 1.1) Web Service. In general, it consists of two major components (assemblies, or just simply namespaces):

• SunnyCars.Services.CarRentalAgent.WebService - This is the service component of the Web Service. The service component denotes the front-end of this Web Service and is designed as a single class. To consume the functionality, you will be using the methods of this class, called CarRentalAgentService.
• SunnyCars.Interfaces.CarRentalAgent.WebServices - This is the interface component of the Web Service. The interface component defines types and classes the service component uses. More specifically, the interface component has a number of classes which define requests, responses and data structures used to communicate with the service component.

The Service Component

As mentioned before, the service component is the front-end of this Web Service. All functionality exposed by this service is integrated within this single component (or class). Consequently, you only need to utilize the one and only class in this namespace, called CarRentalAgentService. This class has methods you can use to:

The above procedures list serves as base for all activities and processes you can perform using this Web Service. A more detailed discussion of all procedures is decribed later in this document.

All procedures consist of a set of methods. The methods of the service component follow a specific convention. If you have a closer look at all method names, you might have noticed that the're two types of method signatures. This distinction is reasoned by the means of passing parameters to a specific Web Service method. This Web Service accepts so called "complex types" as input parameters as well as "simple types". A complex type is an object instance of a class, whereas a simple type is an instance of a base type (strings).

To summarize, the service component provides you everything you will need to query rates and reservations as well as performing and managing reservations at Sunny Cars.

The Interface Component

Second, the interface component is a definition on how your client implementation will have to communicate with the service component. Its namespace contains a set of classes for general request/response communication as well as all data structures representing business entities (i.e. Locations, Rates or Vehicles). It is dependent on your client implementation and language how these entities are represented on your client side. If you are going to use the SOAP protocol for example, it is most likely that your SOAP language implementation/extension/component will create proxy classes based on the WSDL description for each class defined in the interface component. However, if you prefer or are required to use the HTTP-POST protocol, it is up to your client implementation on how the interface classes will appear and what properties they will have.

As for the business entity classes, it is important to understand which part of data they are representing. This SDK gives you detailed information on each business entity class to become familiar with their functionality and meaning. Furthermore, it is helpful to realize their purpose in a specific business process context. Again, this SDK will illustrate the most important business processes as well as their workflows to help you find the most suitable client implementation according to your individual business needs.

Service Procedures

Authenticate

The first service procedure discussed here, the authentication procedure, is probably the most important procedure of all. Since you can only use all other procedures when you have identified and authenticated your client properly, this procedure is essential for your client implementation.

Methods For Authentication Procedure

The authentication procedure is built upon following methods:

The correct usage of these methods is defined by the authentication procedure itself. The CarRentalAgentService uses a procedure which is very similar to the Kerberos authentication procedure. In detail, the authentication is done using a challenge/response mechanism, which in turn uses cryptographic methods (TripleDES) for secure identification.

From client's perspective, the complete procedure is divided into three steps:

1. Obtain a ticket granting ticket - The ticket granting ticket is required to initialize the authentication procedure on service side as well as providing client with nessessary information to perform the authentication procedure.
2. Create a response secret - Based on the data from ticket granting ticket, the client decrypts the secret from ticket granting ticket and encrypts it again using the client encryption policy.
3. Obtain a service ticket - After having created a response secret, the client sends the token from ticket granting ticket as well as the newly created response to the service for verification. If verification succeeds, a valid service ticket is being returned. The authentication procedure is completed.

Step 1: Obtain a ticket granting ticket

The client calls GetTicketGrantingTicket with his operator key and thereby initiates the authentication procedure.

First, the service checks the operator key for validity and integrity. Afterwards, the operator’s (client’s) pass phrase is being obtained. The service passes over this pass phrase to the cryptography service to generate a secret.

To create a valid secret, the cryptography service first creates a random integer number. Then, this number is being encrypted with TripleDES (CBC/192bit) using the MD5 digest hash of operator’s pass phrase. The encrypted bytes are converted to a string using BASE64-coding. The resulting secret is passed back to the client along with a token (transaction-id).

Both secret and token are assembled to a ticket granting ticket. This ticket granting ticket is the first object you'll get from the web service.

Step 2: Create a response secret

To create a valid response secret, the client first reads the secret from ticket granting ticket obtained in step 1.

Afterwards, the client will have to extract the random number from the secret. Therefore, the secret must be first decoded using BASE64-coding. The result of this operation is a set of plain encrypted bytes (byte-array) of the secret. Those bytes will have to be decrypted with TripleDES (CBC/192bit) using the operator pass phrase's MD5 hash.

In result of the decryption, the client obtains the random integer number the service has created in step 1. The client increases this number by one (n = n + 1).

Now the client will have to create a new secret, called the response secret. To achieve this, the increased number will be encrypted again with TripleDES (CBC/192bit) using the MD5 digest hash of operator's pass phrase. The encrypted bytes are converted to a string using BASE64-coding.

Finally, the client has successfully created the response secret and can proceed to the last authentication procedure step (step 3).

Step 3: Obtain a service ticket

In this last step, the client requests a service ticket. The service ticket is required for all subsequent method calls (using the functionality of the service). The ticket request consists of the ticket granting ticket token and the response secret created in step 2.

After having processed these steps, you are able to use the complete functionality of the Web Service for the period of time the service ticket is valid.

Example: How to perform a valid authentication procedure

[C#]
// STEP 1: Obtain a ticket granting ticket
// In this first step, we request a ticket granting ticket and
// decrypt the secret of the ticket in order to make a valid response secret.
// By the way, we locally store the token for later use.

// Web Service Reference
CarRentalAgentService service = new CarRentalAgentService();

// Our operator data
string opKey = "000000";
string opPassPhrase = "passphrase";

// prepare request
TicketGrantingTicketRequest rq = new TicketGrantingTicketRequest();
rq.OperatorKey = opKey;

// call service and get response
TicketGrantingTicketResponse rs = service.GetTicketGrantingTicket(rq);

// save the token for later use
this.tgtToken = rs.TicketGrantingTicket.Token;

// extract the secret from response
string secret = rs.TicketGrantingTicket.Secret;

// Now the decoding/decryption of the secret will have to be performed
// First we get the plain encoded bytes by converting the BASE64 secret
byte[] decodedSecret = Convert.FromBase64String(secret);

// Second, we create an MD5 hash of our passphrase which will serve as 
// base data for the decryption.
// Note that in C# the md5 hash creation requires a byte array as input.
// The pass phrase is required to be a UTF8-encoded string, so we use
// the UTF8 encoding to convert to plain bytes.
MD5CryptoServiceProvider md5 = new MD5CryptoServiceProvider();
byte[] md5PassPhraseHash = md5.ComputeHash(Encoding.UTF8.GetBytes(opPassPhrase));

// Now we have to prepare the TripleDES decryption. TripleDES requires us
// to pass a key and initialization vector. We use the 128bit md5 hash as key.
// The initialization vector is created with the leading 8 bytes (first 64bit)
// from the md5 hash.
byte[] cKey = md5PassPhraseHash;
byte[] cIV = new byte[8];
Array.Copy(cKey, cIV, 8);

// Decrypt with TripleDES
TripleDESCryptoServiceProvider tdes = new TripleDESCryptoServiceProvider();
tdes.Key = cKey;
tdes.IV = cIV;

byte[] decryptedSecret = null;
using (MemoryStream ms = new MemoryStream()) 
{
    using (CryptoStream cs = new CryptoStream(ms, tdes.CreateDecryptor(), CryptoStreamMode.Write)) 
    {
        cs.Write(decodedSecret, 0, decodedSecret.Length);
        cs.FlushFinalBlock();
        cs.Close();
    }

    decryptedSecret = ms.ToArray();
}

// finally convert the decrypted bytes back to a UTF8 encoded string
string decryptedResult = Encoding.UTF8.GetString(decryptedSecret);

.
.
.

// STEP 2: Create a response secret
// In this step, we take the decrypted secret, convert it to a number,
// increase the number by 1 and encrypt that number again.

// Increase number by 1
string stringResponse = Convert.ToString(Convert.ToInt64(decryptedResult) + 1);

// Take the string and convert it to plain bytes for encryption
byte[] encodedResponse = Encoding.UTF8.GetBytes(stringResponse);

// Encrypt with TripleDES
tdes = new TripleDESCryptoServiceProvider();
tdes.Key = cKey;
tdes.IV = cIV;

byte[] encryptedResponse = null;

using (MemoryStream ms = new MemoryStream()) 
{
    using (CryptoStream cs = new CryptoStream(ms, tdes.CreateEncryptor(), CryptoStreamMode.Write)) 
    {
        cs.Write(encodedResponse, 0, encodedResponse.Length);
        cs.FlushFinalBlock();
        cs.Close();
    }

    encryptedResponse = ms.ToArray();
}

// Finally take the encrypted response and convert it to BASE64-string
string response = Convert.ToBase64String(encryptedResponse);

.
.
.

// STEP 3: Obtain a service ticket
// At last, we take the encrypted response secret and the token from
// ticket granting ticket (from step 1) and ask the service for a
// valid service ticket
    
// Prepare ticket request
TicketRequest rq = new TicketRequest();

// Set request data with encrypted response and tgt token
rq.TicketGrantingTicket = new TicketGrantingTicket();
rq.TicketGrantingTicket.Secret = response;
rq.TicketGrantingTicket.Token = this.tgtToken;

// Request ticket
TicketResponse rs = service.GetTicket(rq);

// This is our valid service ticket token
string ticketToken = rs.Ticket.Token;

Locate

The location service procedure is a fundamental step towards a valid car rental. Naturally, renting a car requires a location where the car is picked up and the customer can depart to start his trip. Consequently, when customer is finished travelling around with his rented car, he arrives at a location where he drops off the car.

Departure And Arrival Locations

Of course this sounds very easy and obvious. However, renting a car, especially by electronic means, is often more complicated as described above. One of the drawbacks in car rental is finding a suitable departure and arrival location for the rental. This is not only reasoned by the geographical position of the locations rather than additional circumstances like desired vehicle category and special equipments, for example.

To fully understand the potential complexity of location selection, a look into the basic requirements might be helpful. First of all, it must be clear that every car rental has a departure and arrival location. Even if the departure and arrival locations are the same (which is a common/standard rental) - both departure and arrival locations have their own treatment. Therefore it is required to electronically process both departure and arrival locations.

Finding Locations

Second, the process of finding a location will have to follow a certain flow. The most intuitive and easy way finding a location is to have perform a location selection by user interaction. However, a location selection between thousands of locations is neither easy nor practical. Therefore, a set of locations are geographically grouped into regions. A region is a geographical area where car rental locations are provided. This grouping limits the selection of car rental departure/arrival from thousands to hundreds - but even this grouping may not practical enough. To make distinction and selection between those hundreds of regions easier, regions are again grouped into higher level regions. Consequently, a tree-node-like datastructure (composite) is being created.

Location Operation Times

As mentioned before, a suitable car rental location is not only defined by finding the correct geographical departure and arrival positions. Car rental locations have certain characteristics which have to be taken into account upon selection.

One of the most obvious properties to consider is the operation time of a location. It is clear that a car rental will be upon request if the desired location is closed upon desired departure or arrival date and time. By default, the CarRentalAgentService will return all possible locations regardless of the operation time of requested location(s).

Note   Attention!

If desired rental time is not within the operation times for a location, the location is not disqualified for car rental. A reservation is possible even if the rental time effectively is out of hour for the desired location.

Location Meetings

Moreover, every car rental location has a set of services provided to meet with the customer for car rental pickup or dropoff. From an abstract perspective, a location meeting is a property or physical service of the location. In simple words, location meetings define how the customer will pick up or drop off his car. As for the locations provided by this Web Service, three basic types of meetings are defined:

Based on customer preference, some of above listed meeting types may be required to fulfill customer's needs. For example, a customer may want to begin his car rental at Munich Airport and would like to finish his rental in Ingolstadt. For this constellation, the departure location (Munich Airport) will have to support meeting at airport. The arrival location (Ingolstadt) will have to support at least meeting at counter, and may optionally support meeting at a special address.

The CarRentalAgentService offers you two methods to perform a location meeting check:

1. Providing a location meeting preference - By providing a preference for location meetings, you automatically cause the Web Service to check for the given preference and let the Web Service only return those locations which match the given preference.
2. Perform a manual location meeting check - Every location returned also has the LocationMeetingsSupported element with AtAirport, AtCounter, AtSpecialAddress properties indicating whether these basic meeting types are supported by the location. In consequence, a client may perform a manual check based on this data.

Location Equipments

In certain cases, a car rental customer may want to order additional equipments along with his car rental. For example, a customer who plans to spent his winter holidays in St. Moritz will probably order snow tires/chains as additional equipment. Every car rental location offers a different set of those additional equipments - in most cases in return for an additional fee. For every location query, the CarRentalAgentService will return the available equipments of a location as Equipments property of the location, if the WithEquipments switch is set to true.

This way, your client implementation is able to offer or check against the available equipments and find a suitable location for the customer.

Methods For Location Procedure

The location procedure is built upon following methods:

Location Procedure Scenarios

When it comes to the implementation of the location procedure, several possibilities (scenarios) are supported by the CarRentalAgentService. As discussed earlier, the regional structure allows you to find a location by narrowing the area of interest. This method usually is implemented on the client side by "user guidance". In particular, the client asks the user to specify his departure location by selecting a country or region where he wants to start his car rental.

Before discussing all location finding possibilities in detail, a brief list and description follows:

A second possibility would be to ask the user directly for his departure location by letting him enter the city where he wants to depart. In that case, the client implementation requests regions whose name match the city name provided by user.

Another common use case scenario would be to find a car rental location by airport. Since the majority of travellers arrive by airplane, this scenario is probably a frequently used option. To accomplish this task, the client first queries the supported airports and provides the list for user selection. After having the user select his departure airport, a region query is performed to find a suitable region for that airport.

It is important to recognize that all scenarios utilize regions to find a suitable car rental location. This fact will become very important when the evalutation procedure (requesting car rental rates) is discussed later. As for now, it is sufficient to know that the regional structure is designed to find locations.

In addition to the regional location finiding, the service offers direct location query capabilities. You may directly query locations using an IATA three letter airport-code for example.

Evaluate

The third service procedure discussed here is the evaluation service procedure. In context of the entire car rental process, evaluating means to query vehicles, their details and features as well as rates, condition and coverage information.

To get started with this service procedure, it may be useful to summarize the prerequisites required before the evaluation service procedure can be utilized:

Once you met all those prerequisites, you are able to start the evaluation service procedure.

Vehicles, Vehicle Types and Preferences

Within this service procedure, Vehicles and VehicleTypes are elementary entities you will work with. A Vehicle defines and describes the car available for rental at a location. It provides you with base information such as code, name, type, door and passenger count, picture references and features. In most cases, a car rental location offers several types of cars within their fleet. Those types (or categories) are reflected using the VehicleType entity. There's a fixed number of types for all vehicles offered by Sunny Cars.

If you perform a rate request for example, you can specify a valid VehicleTypeId to limit the rate search result to the specified type (i.e. "Convertible").

Rates and Rate Service Types

Second, you will most likely request rates during this service procedure. A Rate is the price for a Vehicle depending on a specific car rental request. The rate price always relies on a Currency, its assigned Vehicle and RateServiceType.

The interesting depedency here is the rate service type. To understand this dependency, a definition of a rate service type is helpful:

Following this definition, this simply means that Sunny Cars offers several different packages of conditions and coverages for one vehicle. A real-life example helps to clarify this circumstance:

Sunny Cars offers car rentals at Miami Airport, in particular a Chevy Metro with automatic gear shifting and air conditioning. This "small size" vehicle is available with two different rate service types:

1. A standard rate service type, named "Standard Cover" - This rate service type includes
   • unlimited mileage
   • airport service charges
   • liability insurance
   • local taxes
2. An extended rate service type, name "Super Cover" - This rate service type includes
   • unlimited mileage
   • airport service charges
   • liability insurance
   • local taxes
   • carfree personal protection insurance
   • additional drivers free of charge
   • first tank of fuel

It's obvious that the "Standard Cover" rate service type includes less coverages than "Super Cover" rate service type. In consequence, the same vehicle is available with both rate service types and therefore different rate prices.

The rate service type is being returned in every rate request, so you can offer your customer both "Coverage Packages" for selection.

"Best Offer" Rate Calculation aka Regional Rate Query

The best offer rate calculation feature is probably one of the most exciting ones of this Web Service. Before diving into the usage details of this feature, it is essential to understand the difference between a Location and a Region.

A Location is a distinct geographical point where car rentals are offered - more simply: it's just a car rental office.

A Region is a set or collection of Locations, grouped together by means of geographic position - more simply: it's a set of car rental offices located nearly to eachother.

Now imagine following scenario: Your customer wants to rent a car at Frankfurt, Germany. He's near the center of the city at day of car rental, so he decides to pick up the car directly in the car rental office (a location providing counter services). Sunny Cars offers several city offices in Frankfurt. Let's just pick 2 city offices for this example:

• Frankfurt Center City Office, and
• Frankfurt North City Office.

Both city offices offer mid-range, business-class vehicles (let's say it's a BMW 525, air conditioned), which perfectly matches your customer's preference.

Now there's one major difference between both city offices. While Frankfurt Center City Office offers the desired car for € 469,-/week, Frankfurt North City Office offers the same vehicle category for € 419,-/week - a difference of € 50,-! In traditional booking engines, your customer would have to select the desired location first, and afterwards get the fleet and rates for the selected location. Assuming this "classic style", your customer would most probably have chosen Frankfurt Center City Office and have seen it's desired car for € 469,-/week.

This is where the best offer rate calculation comes into the game.

In terms of the CarRentalAgentService, Frankfurt is equal to a deep-leveled, location-assigned Region and the city offices mentioned above are Locations of that Region.

In case you would now perform a request with Region Frankfurt on GetRates, the Web Service automatically would perform a rate and vehicle check on all Locations assigned to the region and would compare the resulting rates on same vehicle categories. Using this real-time comparison, the region-based rate query would return the best offer from all locations.

"Best Offer" Consequences in Overall Process

The best offer calculation and result is a very handsome method to offer the customer the most suitable vehicles upon his preference. However, using the best offer calculation scheme affects the overall car rental process significantly. In detail, the best offer rate query results in a shift of location selection. A comparison of both (location vs. regional rate query) rate calculation schemes reveals the difference:

In consequence to above listed differences, the overall process of car rental changes. This is mainly reasoned in the fact, that you only can perform a car rental Reservation if you have determined departure and arrival locations as well as the location meeting types desired by customer. You won't be able to perform a reservation without exactly specifying which locations and meeting types the customer wants for his car rental.

As you can see, the process towards a valid car rental reservation is different for both approaches. It is up to you to decide which process is the best for your business needs. However, Sunny Cars recommends you to use the regional-based rate query approach because it delivers best service to the customer.

Finally, following a list of the Web Service methods which apply to the evaluation service procedure:

Regular Prices & Special Prices

The Rate entity already has been discussed in previous chapters. Until now, it's assumed that a Rate is a representation of a car rental price for a specific vehicle and rental request. However, sometimes Sunny Cars has special offers for certain locations or vehicles. These special offers result in discounted (lower) prices for a specific request.

This is both fine for Sunny Cars's partners as well as the end customer. Nevertheless, the fact of having a discounted rate for a vehicle is not directly visible to customer. To eliminate this disadvantage, the Rate element has a special attribute called BaseValue. This attribute only contains a value if the Value attribute represents a discounted price.

A typical scenario for such a constellation is the following example: A customer wants a car rental in Munich. It's October, and the famous "Oktoberfest" is happening in Munich. For this 2 weeks lasting Mega-Event, Sunny Cars offers special, discounted prices. If you know perform a rate query on Web Service matching the Oktoberfest dates, you'll get the BaseValue filled with the standard pricing as well as the Value filled with the discounted pricing back as response for a certain vehicle.

If you'd perform the same request a month later, only the Value attribute would be returned. Since the Oktoberfest ist not happening anymore, there's no special offer. In result, the standard pricing applies. In this case, the Value attribute represents the standard pricing.

Delineate

The delineation service procedure is more a client-based procedure rather than a server-based procedure. To be presicely, "delineation" means to provide the customer with essential information regarding the product (which is the car rental or vehicle rate) and second, to gather required infromation from customer to perfrom a valid car rental Reservation.

The first responsibility - providing product information - is just simply to provide the customer the condition and coverage information for the selected Rate. This is achieved by calling the following methods which support this service procedure.

The latter responsibility - gathering customer information - is a pure client-based procedure. In this case, it is very important to gather all information depending on the type of car rental reservation you are going to perform. A detailed description about the possible types on the reservation creation process is provided later in the operation service procedure section of this document.

Nevertheless, there's basic information about a car rental which is common to all types of reservation. Following a table of the fundamental car rental reservation infromation which is mandatory:

Operate

The last service procedure in the overall car rental process is the operation service procedure. This procedure is used to create and manage car rental reservations at Sunny Cars. Following a list of supported methods for this procedure:

The most important and complex part of this procedure is the creation of a car rental Reservation. Naturally, in order to create a reservation you must have passed all preceding service procedures. In consequence, you already have gathered all required informations such as

• car rental begin and finish date / time,
• car rental departure and arrival locations,
• car rental departure and arrival location meertings preferred,
• preferred vehicle, rate and rate service type,
• essential driver data,
• essential customer data if payment and/or document dispatching is via customer.

The existance of all required information is the first step towards a valid car rental reservation. In addition, a car rental reservation and their consequences to business process and workflow may differ on how the reservation is being created. Therefore, this Web Service categorizes those differences as reservation types.

To completely understand all parameters as well as type differences within reservation creation, a look into the main business roles might be helpful:

Business Roles

In addition to these three fundamental business roles, the Driver is another essential entity representing a person. A Driver is the person effectively consuming the car rental. In most cases, the Driver is equal to the Customer.

However, in some rare cases, the Driver may be another person than the Customer. Consider a simple example: Your customer's father is going to holiday this summer with his new wife. To make him a valuable present, your customer uses your business service (and effectively this Web Service) and searches for a car rental for his father. Your customer would be the Customer of the car rental, while his father would be the Driver.

Reservation Types

In dependence of above methioned roles, the're a number of different ways to create a reservation. In result, several reservation types are possible.

In consequence to those reservation types, you will have to gather different sets of information to create reservations of different types. However, a car rental reservation has fundamental "core" data, which is required for all types of reservations. The fundamental elements of a reservation are listed below.

Fundamental Reservation Data

In addition to these core data elements, you will have to gather extended information depending on the type of reservation you are going to create. The concrete data to gather is dependent on four so called "type switch" properties. The type switch properties of CreateReservationRequest are essential in creating a valid reservation. Before discussing the extended data and their requirements, a closer look to the type switch properties and their meaning might be useful.

Reservation Type Switch Properties

Reservation Creation & Status

After determining which reservation type is the best suitable for your process, you fill in the required data into the CreateReservationRequest object and call the CreateReservation method. If everything works out well, the response will contain a Reservation object representing the car rental reservation. The most important attributes of this element are Id and Status. The Code is the unique reservation number identifying the reservation in Sunny Cars's database. At the same time, this id is the reference for all activities on that reservation after the creation process.

The second attribute Status represents the status of the reservation at creation time. The status is always temporary and may change at later time.

Reservation Cancellation

After you have created a reservation, you are also able to cancel a reservation using the reference reservation id returned from the creation process.

Appendix

Error & Warning Codes

Error Codes

Warning Codes

Namespace hierarchy

Classes

---