Developer's Guidelines

 


This page contains information that we believe is pertinent to successfully developing an application using the Amadeus API.  It will be updated in a timely manner and will include recommendations on the usage of different functions.

 


 


Table of Contents

 

 
A UML Example Of a Travel Booking Engine using the Amadeus API

This presentation describes an example UML (Unified Modeling Language) design for a multi-user, multi-threaded Travel Booking Engine using the Amadeus APIv2.

The design purposely concentrates on the interaction between the Application Provider’s software and the conversation management aspect of APIv2 Proxy library.
   Download the UML Example of a Travel Booking Engine.ppt file locally, Or browse the HTML equivalent

 
Mixing flavours - applies to pre 2.1.19.1 APIv2 Proxies only

"Client applications should work with only one flavour of the Proxy at a time."
Client applications should not mix flavours of the Proxy during the lifetime of a Conversation.

For example:
Open a Conversation using the C-Container flavour, and SendAndReceive , or Close the Conversation using the XML-C flavour of the Proxy would be considered illegal and may result in unpredictable behaviour.

Since version 2.1.19.1 of the API Proxy, C-Container and C-XML flavors are delivered in the same library dll on Windows, and so this restriction no longer applies


Eumerated types
It is strongly recommended to use the enumerated types provided instead of hard coded numerical values in your code.
                                                           December 2002

Error management

There are essentially two types of function calls provided by the API Proxy. Technical function calls, such as those dealing with conversation management, memory management and diagnostics, and application function calls providing access to the range of Amadeus Central System travel products.

Examples of technical function calls are CAI_openConversationByCorporateId or CAI_setTrace.

Examples of application functional calls are CAI_sendAndReceiveXml (this is the only one in the C-XML flavour) or CAI_PoweredAirMultiAvailability (infact there is one for each Amadeus Central System product in the C-Container flavour).
For the complete page please click on the following link:  Error management

                                                           December 2002

End of Data Indicator

The Cryptic interface and the function GetScreen opens up the possibility to execute an Amadeus cryptic host command using the Amadeus API.  

It is therefore possible using the <CrypticgetScreen> command to identify whether there is more pending data screens.


'If the last line starts with a 'less than' sign i.e. '>'- then there are no more lines.
Likewise, if the last line STARTS with a 'bracket' followed by a 'less than' i.e. ')>'-
then there are more data lines to be displayed
                                                            January 2003
Numeric Fields and leading Zero's
It should be noted that leading zeros entered into a numeric field will be surpressed

For example
Before:
<creatorIataCode>00385125</creatorIataCode>

After:
<creatorIataCode>385125</creatorIataCode>
                                                           July 2003 (Source PTR # 01104733)
Understanding CContainer flavor MetaStructures 

In the CContainer flavor of the API, query messages are constructed from an arrangement of C Containers containing C structures.
The C Container definitions, and the structures they will contain are described in the header files interfaceName dic.h.


For example, the file PoweredAirdic.h contains all C Container and C structures necessary to build all possible query messages in the PoweredAir Interface (such as MultiAvailability, Availability or RetrieveSeatMap) as well as to read the data from all possible reply messages in this interface (such as MultiAvailabilityReply, AvailabilityReply and the RetrieveSeatMapReply).

You may notice that certain C structures which represent the same thing, but which belong to different messages, are merged. This merged structure is know as a metastructure.

The advantage of the metastructure is to optimise memory usage. The disadvantage is thatthe size and repetition values may sometimes seem confusing in certain contexts.

For example, In the PoweredAirDic.h file, the field typeOfRequest in the C structure CAPI_PoweredAirProductTypeDetails is described as :

typedef struct

{

AMD_Char typeOfRequest[3][9+1];

AMD_Char productIndicators[3][9+1];

}CAPI_PoweredAirProductTypeDetails;

C structure from .h file




 This field is used both by the query message (PoweredAir_MultiAvailability) as well as the query message (PoweredAir_Availability).
In the PoweredAir_MultiAvailability query message, the online documentation shows how the structure needs to be completed in order to build a

CAPI_PoweredAirMultiAvailabilityRequestSection->

CAPI_PoweredAirAvailabilityOptions-CAPI_PoweredAirProductTypeDetails->typeOfRequest

CAPI_PoweredAirProductTypeDetails productTypeDetails;

 

. typeOfRequest[2+1]

 

 On-line documentation 


Notice that here this field type of request is not repeated, and its maximum length is 2+1.
In this context, the C structure provided in the PoweredAirDic.h file seems excessively large. This is because, the same structure is reused in the query message of PoweredAir_Availability,

CAPI_PoweredAirAvailability_cityPairRelatedSection->

CAPI_PoweredAirAvailability_requestSection->CAPI_PoweredAirTravelProductInformation->

CAPI_PoweredAirProductTypeDetails->typeOfRequest)


where the online documentation describes it as:

CAPI_PoweredAirProductTypeDetails availabilityTypeDetails;

 

 . typeOfRequest[9][3+1]

 

To summarize:
The online documentation describes the usage in a given context, where as the <interfaceName>dic.h file describes the metastructures.
                                                           September 2003