Amadeus - DOC - DOC

Document Sample
Amadeus - DOC - DOC Powered By Docstoc
					Cruise database migration                                        Internship report




                        Internship Report




  Cruise database migration from an IBM system (TPF) to
               Oracle and data management.

                  19th of April 2004 – 24th of September 2004



Yoann POULAIN                                   DESS ISI / LOG

Company: Amadeus
Amadeus supervisors: Marie-France Borderes, Javier Suay-Rincon
Cruise database migration                                                 Internship report




Acknowledgem ent

I would like to thank all the persons who greet me along this internship. More precisely, I
want to thank Marie-France Borderes TSP Manager who gave me a chance to apply my
skills in a big company environment and who trusted me to establish a big project
foundation.

I would like to thank all the team members in the OSP service where I was incorporated.
I want to thank Richard Godec, Russell-James Humphries, Jean-Luc Planque, Olivier
Mitride, special thanks for Pierre Schmitt for his advice and his patience in front of my
questions, and of course thanks to Javier Suay-Rincon, the OSP Team Leader, who
trusted me and who dealt with all the problems I had.

Finally I want to thank Jean-Marc Bouzin who gave my CV to the right person in the
Amadeus structure and Patrick Ferrante who gave me the necessary help to achieve my
project.




                                                                                         1
Cruise database migration                       Internship report



Tabl e of cont ents
Introduction                                                   4
Amadeus                                                        5
 1 - ABOUT AMADEUS                                             5
    1-1 Presentation                                            5
    1-2 History                                                 6
    1-3 Amadeus around the world                                7
    1-4 NMCs                                                    9
    1-5 Regional Headquarters                                   9
 2 - STRATEGY AND FUTURE OUTLOOK                              10
    2-1 Travel distribution                                   11
    2-2 E-commerce                                            12
    2-3 IT Service provider                                   13
 3 - AMADEUS CULTURE                                          14
 4 - AMADEUS QUALITY                                          15
 5 - AMADEUS WITH FIGURES                                     16
 6 - SOPHIA ANTIPOLIS ORGANIZATION                            17
    6-1 TSP                                                   17
    6-2 OSP                                                   18

The migration project                                        19
 1 - THE CURRENT CRUISE ARCHITECTURE                          19
 2 - THE PROBLEM                                              20
 3 - THE MIGRATION MISSION                                    20
 4 - PLANNING                                                 21
 5 - THE GENERAL ARCHITECTURE                                 22
Database migration                                           23
 1 - EXISTING DATA MODEL                                      23
 2 - TPF-DF TO O RACLE TRANSFORMATION                         24
    2-1 The version problem                                   24
    2-2 The profile management problem                        25
 3 - THE ORACLE DATABASE MODEL                                27
Edifact                                                      28
 1 - EDIFACT CONCEPTS                                         28
 2 - EDIFACT: AN OMNIPRESENT LAYER IN AMADEUS                 29

                                                               2
Cruise database migration                           Internship report


 3 - EDIFACT MESSAGES CREATION                                    29
    3-1 The retrieve transaction                                  30
    3-2 The create transaction                                    32
    3-3 The delete transaction                                    33
    3-4 The update transaction                                    33

Open BackEnd                                                     34
 1 - WHAT IS AN O PEN BACKEND?                                    34
 2 - GENERAL OPEN BACKEND ARCHITECTURE                            35
    2-1 UpSQL Layer                                               35
    2-2 Field and Container Layer                                 36
    2-3 Dbrequest Layer                                           36
    2-4 Automatic generation                                      37
    2-5 Business Layer                                            38
    2-6 Usecase Layer                                             38
    2-7 Dispatcher Layer                                          39
    2-8 Msgtranslator Layer                                       39
    2-9 Entry Layer                                               40
 3 - OPEN BACK END RECAPITULATION                                 42
Java Graphical User Interface                                    43
 1 - GENERAL ARCHITECTURE                                         43
 2 - BUSINESS LA YER                                              44
    2-1 Concrete organization                                     44
    2-2 Business object layer                                     45
    2-3 Adapter layer                                             45
    2-4 Transaction                                               47
 3 - GRAPHICAL LAYER                                              48
    3-1 Graphical layer role                                      48
    3-2 A MVC usage example                                       49
    3-3 A cache of objects                                        51
    3-4 Transaction storage                                       51
    3-5 Interface automatic generation                            52
 4 - GRAPHICAL USER INTERFACE RECAPITULATION                      53
Conclusion                                                       54
 1 - WORK CONCLUSION                                              54
 2 - INTERNSHIP CONCLUSION                                        55

Appendix                                                         56
 1 - SEVERAL GRAPHICAL USER INTERFACE SCREENSHOTS                 56
 2 – EDIFACT MESSA GE EXAMPLE                                     59


                                                                   3
Cruise database migration                                                  Internship report



Intr oducti on

The aim of this report is to present the main part of the realized work I made during this
six month long internship in the Amadeus Company. This internship concludes the DESS
formation I made during one year at ESSI. It is also the last step before the entry in the
active life. So this internship has several purposes:
    - The application of the learned knowledge at ESSI and during all my studies
    - The learning of new technologies
    - The learning of professional methods
    - A better introduction into the labor market

This document just explains the work I have done and focuses on the most interesting
parts of this internship because the amount of creation and of analysis document made
can not be contained in one report.

I have been hired in the OSP department which is managed by Marie-France Borderes
and Javier Suay-Rincon. This department deals with several booking applications
(Cruise, Ferry, Insurance …) which are hosted into an old IBM big system (TPF). The
actual Amadeus politic is to detach most of these app lications from this system and to
make a migration to a Unix system (Open Backend) and using an Oracle database
management system.

My mission during this 6 month long internship was to begin the migration for the cruise
application. This beginning includes the migration of the database and the design of a
new relational model and the implementation of services in order to manage this database
from a graphical user interface.

This report provides first a quick overview of the Amadeus Company and of the strategy.
We will study briefly the actual cruise application in order to view the current
architecture and finally I will explain more in details all the layers I designed to complete
the project.

This report does not content any bibliography because most o f the documents I used are
the property of Amadeus and it is impossible for an external user to access to these
documents.




                                                                                           4
Cruise database migration                                                 Internship report




Amadeus
The following information are extracted from an official document edited in
September 2003.

  1 - Ab out Am adeus

    1-1 Presentation
    1-1 Presentation




       Amadeus operates one of the world‟s most extensive electronic marketplaces that
enables travel agents and travel service providers to market and sell travel to corporate
and consumer end-users, in some 214 markets around the world. In addition, our modular
technology is used by more than 130 airlines to optimize their internal operational
requirements.

Founded in 1987, Amadeus has                      hoteliers, rail staff and car rental
become one of the world‟s three main              employees. The data behind all this
global distribution systems (GDS) and             information powers the world‟s travel
is the leading provider of technology             industry and is stored, communicated
solutions, being also a significant               and flashed across millions of screens
enabler of e-commerce for the travel              all around the world. Amadeus
industry. Since its creation, Amadeus             provides the computer network, the
has evolved to become the fastest                 terminals, the software and the content
growing GDS in the world, serving                 that allows airlines, travel agents, hotel
more travel agencies directly than any            chains, car rental firms, ferry and
other. Each and every journey is                  cruise lines, train operators and
planned and organized through a                   insurance agents to distribute travel
network of travel agents, airline and             products the world over.
airport staff,




                                                                                          5
Cruise database migration                                         Internship report




    1-2 History
    1-2 History




Amadeus Global Travel Distribution is      Meanwhile, in Europe, many of the
a means of charting the world of           national airlines had developed their
travel, providing the travel industry      own      reservation      systems    and
with tools to discover new territories     distribution networks. These, however,
of information and services. In the late   only served their respective national
60s, the main US airline companies         markets. Imminent deregulation of the
started developing and implementing        European travel industry made it
CRSs (Computerized Reservation             imperative to create distribution
Systems). Years later, in the mid 70s,     systems able to serve the European and
they decided to install terminals in       global market. In 1987, responding to
travel agencies, giving only access to     these needs and business opportunities,
limited data. But as a result of the       Air France, Iberia, Lufthansa and SAS
pressure by travel agencies and            pooled their resources in a project
different official organizations, the      called Amadeus. In 1989 Amadeus
CRSs started to move towards neutral       was the first GDS to offer a neutral
systems, showing also all of the           flight availability display following EC
competitors‟ information. In the mid       regulations. Amadeus became fully
80s, US CRSs were increasing in            operational in 1992, and a public listed
sophistication and they began to look      company in 1999.
overseas for opportunities to expand.




                                                                                 6
Cruise database migration                                             Internship report




    1-3 Amadeus around the world
    1-3 Amadeus around the world
Amadeus is the undisputed market leader in Europe and South America and also has a
strong foothold in the US market, in Africa, and in the Asia Pacific region, with over
5,000 employees spread worldwide.



Corporate Headquarters MADRID                   Product Development & Marketing
The headquarters of Amadeus are                 Centre SOPHIA ANTIPOLIS
located in Madrid, Spain, where the             Product definition and development
group‟s      corporate,      financial,         facilities are located in Sophia
marketing, human resources and                  Antipolis near Nice, France. Sharing
communication strategies are defined,           the product marketing with Madrid,
and where relations with providers,             Sophia is also our central customer
airlines, and travel agencies are               support site and manages and
managed.                                        maintains databases.
• Group Head Office                             • Product Marketing
• Definition of Corporate & Financial           • Product Definition
Strategy                                        • Product Development
• Central Marketing Strategy                    • Central Customer Support
• Human Resources                               • Database Maintenance
• Corporate Communication                       • Corporate Strategy
• Provider Marketing & Sales
• Management of NMCs




                                                                                     7
Cruise database migration                                         Internship report




                                           IT Service Centers
                                           We have created two commercial
                                           bases in London and Sydney
                                           respectively to provide hosting and IT
                                           services for airlines. These
                                           development centers have been created
                                           as part of our IT services strategy to be
                                           a leading airline solutions partner.



                                            Amadeus         Services
Data Centre ERDING                          LONDON
The Amadeus Data Processing Centre,       • Commercial base for
located in Erding close to Munich,        partnership with BA
Germany operates 24 hours a day, 365      • Hosting and IT services
days a year to give users and providers   •     Enhancement        of
access to our Global Distribution         passenger     management
System. Data is transferred directly      systems
from the „Operation Centre‟ into a
worldwide backbone network. „State
of the Art‟ technology and highly
qualified teams of people make the
Amadeus Data Processing Centre one        Amadeus           Services
of Europe‟s most capable and              SYDNEY
innovative commercial computing           • Development centre for
centers.                                  partnership with Qantas
• One of Europe‟s largest commercial      • Hosting and IT services
data centers                              • Enhancement            of
• 99.98% system availability              passenger     management
• User access to over 2,150               systems
transactions per second
• 1-7 million bookings per day




                                                                                   8
Cruise database migration                                       Internship report




    1-4 NMCs
    1-4 NMCs

A network of over 70 National             NMCs are structured as independent
Marketing Companies (NMCs) allows         companies, usually with Amadeus
us to operate in some 214 markets         Global Travel Distribution as a part, or
throughout the globe. These NMCs are      sole shareholder. This approach
Amadeus         front- line   marketing   ensures Amadeus‟ marketing strategy
companies, and represent the Amadeus      has great flexibility, as well as giving
brand, locally and regionally. They are   Amadeus the capacity to understand
responsible for:                          and closely address the needs of
• sales and marketing to local users      specific markets. The majority of
(particularly travel agents)              NMCs are fully owned by Amadeus
• activities with providers               with employees who form a truly
• local product definition                global network spanning across six
• customer service                        regions:
• technical Help Desk and training        • Western Europe
support                                   • Central, Eastern & Southern Europe
                                          • Middle East & Africa
                                          • North and Central America &
                                          Caribbean
                                          • South America
                                          • Asia Pacific



    1-5 Regional Headquarters
    1-5 Regional Headquarters


Our regional offices in Miami for
North/Central America, in Bangkok
for the Asia-Pacific area and in Buenos
Aires for South America support our
NMCs and coordinate commercial
relationships with regional providers.

North Ame rica, Miami
• Product development
• Customer service
• US providers
• US marketing services
• NMC activity




                                                                                9
Cruise database migration                                              Internship report


Asia Pacific, Bangkok
• Regional management and operations
• Customer support
• Key account management
• Regional marketing
• NMC coordination and support

South America, Buenos Aires
• Regional management and operations
• Customer support
• Key account management
• Regional marketing
• NMC coordination and support




  2 - St ra tegy and f utu re o utlo ok
Amadeus is organized along three main business lines:

• Travel distribution                            • IT services
Since its beginnings in 1987, Amadeus            Amadeus is a leading application
has evolved to become a pivotal                  service provider (ASP) to the airline
element within the travel distribution           industry. Over 130 airlines use the
chain, providing sales and marketing             Amadeus Sales System in their offices
facilities across to travel agencies and         to provide passengers with superior
airline offices which together total             and seamless service at optimal cost.
over 290,000 points of sale in some              Amadeus's      new    generation     of
214 markets worldwide.                           Passenger Service Systems, which
                                                 include all IT systems associated with
• E-commerce                                     inventory management and departure
Through our e-Travel business unit we            control, will be implemented by
offer a range of online travel solutions         British Airways, Qantas and Finnair.
and web-booking tools that enable
airlines, corporations, travel agencies
and online travel portals to grow
successful online business.




                                                                                     10
Cruise database migration                                       Internship report




    2-1 Travel distribution
    2-1 Travel distribution

The traditional core of our business is   The global resources of Amadeus
travel      distribution.   Worldwide,    provide our travel agency subscribers
Amadeus has the most extensive            with access to unprecedented levels of
international distribution network and    information. Our specially designed
more international bookings are made      interfaces make this information easy
through Amadeus than through any          to access and to use. We are working
other system. We continue to              constantly to expand the range of
strengthen our position as the fastest    products that travel agency subscribers
growing GDS in terms of revenue and       can sell through the system; with the
profitability. We process over 400        help of our national marketing partners
million bookings annually, linking a      we have enhanced our core product
wide range of providers such as           offer considerably by adding a large
airlines,    car rental companies,        number of local product providers.
hospitality providers as well as travel   With products such as Amadeus Vista,
assistance services like rail, ferry,     Amadeus Pro, Amadeus Pro Web and
cruise and tour providers to the          the ICSA-T development we provide
worldwide travel market. Amadeus          subscribers with solutions that ensure
offers a comprehensive portfolio of       high levels of productivity. Through
central system products from our data     the „System User‟ concept, which
centre in Erding (complemented by         allows airline customers to have their
distributed     software    for  travel   internal sales and reservation systems
agencies) and web applications            outsourced Amadeus is the only
adapted to corporations and public        Global Distribution System serving
consumers.                                more than 130 airlines with the same
                                          products and services as those
                                          provided through the travel agency
                                          channels.




                                                                              11
Cruise database migration                                         Internship report




    2-2 E-commerce
    2-2 E-commerce


Since March 2002 e-Travel, Inc., a
leading US supplier of hosted
corporate travel technology solutions
based in Waltham, Massachusetts, was
merged with the entire Amadeus
online business solutions offering to
create an integrated Amadeus business
unit separately branded as - e-Travel.     tourism products on the Internet. Since
The “new e-Travel” focuses on              then, we have continued to play an
delivering successful online travel        important role in e-commerce,
solutions to the whole range of            providing the powerful booking
corporate and leisure customers,           engines behind the web pages of over
including airlines, corporations, travel   900 travel agencies, more than 260
agencies, portals and travel suppliers.    corporate sites, 10 hotel sites and over
This integration follows Amadeus´          130 web sites serving over 50 airlines.
acquisition of e-Travel Inc., in 2001.     In order to provide comprehensive e-
Incorporating e-Travel Inc., allowed us    marketing tools for our Internet clients,
to offer further corporate travel          we began to complement our booking
solutions and significantly increased      engine e-Travel Planitgo (formerly 1a-
our presence in the important US           Res), with the jointly developed
market. e-Travel, in turn, expanded its    BroadVision® e-Travel® (formerly
global potential and capabilities          BroadVision-Amadeus               Travel
through its relationship with a parent     Commerce™). This is an innovative
company that is an established leader      travel application and marketing tool,
in travel technology and distribution.     which        allows      One-To-One®
Amadeus started developing solutions       personalization technology offering
for e-Commerce in the mid 90s, based       distributors, such as online travel
around the 1a-Res application enabling     agencies and corporations with
the distribution of travel and             extensive travel needs, next-generation




                                                                                 12
Cruise database migration                                     Internship report




    2-3 IT Service provider
    2-3 IT Service provider

Internet travel solutions for consumer   one-stop shop for online solutions e-
and employee markets. In the             Travel. To find out more about e-
corporate travel market sector we have   Travel, the Amadeus business unit for
been working closely with strategic      online travel solutions go to www.e-
corporate partners such as SAP to        travel.com. Amongst our strategic
develop a corporate booking solutions    joint- venture partners are such as
portfolio addressing all corporate       Rumbo.com in association with Terra
market      segments;      local   and   Lycos in Spain, Portugal and Latin
multinational travel agencies and        America, OneTravel.com in the US,
corporations. Our online corporate       travel.com.au in Asia Pacific, and
travel booking tool e-Travel Aergo       Opodo in the UK.
(formerly Corporate Traveler) is
serving the travel cost management       IT services provider
needs of some of the leading             As an Application Services Provider
corporations and business travel         (ASP) we are creating a platform for
agencies in the world. This powerful     airlines to fulfil their IT needs.
Amadeus e-commerce offering creates      Amadeus operates and will enhance
a unique and integrated                  further passenger management systems
                                         for British Airways,Qantas, and
                                         Finnair. We will introduce a new
                                         generation of inventory and departure
                                         control systems, encouraging the
                                         world‟s leading airline groups and
                                         alliances to outsource information
                                         technology functions.




                                                                            13
Cruise database migration                                         Internship report



  3 - A madeu s cul tur e

Amadeus culture
Amadeus is a truly global company,
and the foundations of its culture have
never been dominated by any one
particular country. Amadeus has
always      been     an     international
organization, spreading out from
Europe with a clear policy of finding
local people to build up local markets.
In our main corporate sites we have
                                            Amadeus people
around 30 nationalities working
                                            The people who work in Amadeus are
together. This variety of backgrounds
                                            the vital resource for the company and
and cultural diversity has been a major
                                            its future, creating products and
factor in the success of our company.
                                            services that distinguish us from our
We encourage creativity, innovation,
                                            competitors. Amadeus people are not
and teamwork – the working practices
                                            easily defined or categorized. Most are
that have driven our achievements.
                                            young, many speak at least two or
Our investment in training keeps
                                            three languages and usually bring
growing. Amadeus offers its people
                                            experience from the information
the chance to learn, to evolve and to
                                            technology or travel industries. All
manage responsibilities from an early
                                            care tremendously about the future
stage in their careers, enhancing both
                                            success of Amadeus. At Amadeus,
personal        and         professional
                                            day-to-day business involves constant
development.
                                            change. We provide a stimulating and
                                            challenging work environment for our
                                            people who enjoy being part of a fast-
                                            growing enterprise. We believe that
                                            our achievements and our success
                                            depend on the effective contribution of
                                            each and every one of our employees,
                                            as well as their commitment.




                                                                                14
Cruise database migration                                             Internship report




  4 - A madeu s Quali ty
In late 1997, Amadeus created a department dedicated to making the delivery of top
quality systematic throughout the company. A Quality Management System (QMS) was
developed and installed to plan, control and improve continuously the company‟s ability
to deliver better value to customers at a lower cost. One year later (in 1998), Amadeus
was the first GDS to receive ISO 9002 Certification for its QMS (covering delivery of
services). In December 2000, Amadeus was the first GDS to achieve ISO 9001:2000
certification for its QMS (by now covering all departments in Madrid, Sophia Antipolis
and Erding) and encompassing the management practice and organizational requirements
for the design, development and delivery of quality products and service.


Quality System                                  Quality Policy
The Quality System Database leads to            The Amadeus Quality Policy is easy to
information on                                  remember and all Amadeus employees
Quality Policy and Quality Manual :             are expected to be familiar with it.
guidelines for quality decision making          Everyone should be committed to
and practice                                    Quality and apply Quality standards
Quality Results: a location to store            systematically.    Applying     Quality
and view performance metrics                    standards systematically means:
Corporate Information: a repository             • know the customers and focus on
of useful data about Amadeus                    their needs • set clear standards for
Quality Processes and Procedures:               performance and measurement
the library of departmental and                 • align people and resources to achieve
corporate processes and procedures              quality objectives
Ideas and Solutions: a forum for                •      practice    rigorous     process
questions and exchange of ideas on              management (plan-do-check-act) •
quality                                         apply intelligence, innovation and
                                                good teamwork
                                                • make continuous improvements and
                                                decisions based upon facts




                                                                                    15
Cruise database migration                                               Internship report



  5 - A madeu s wit h fig ures

Owners                                               % shares
Public                                               53.3
Lufthansa                                            5.1
Iberia                                               18.3
Air France                                           23.3
Total                                                100.00

Worldwide
Amadeus Owner Airlines                                                           3
Markets served by Amadeus and its National Marketing Companies (NMCs)            210

Employees of the Amadeus Group (including majority-owned NMCs)                   3,654

Employees of the Amadeus Group (not including majority-owned NMCs)               2,240


Market share                                               Locations   Terminals
Travel Agencies                                            61,000      211,800
Airlines Sales Offices (representing 113 airlines)         10,000      100,000
Total                                                      71,000      311,800

Travel Service Provide rs

Airlines storing flight schedules in Amadeus         754
Airlines bookable                                    49
Hotel properties                                     56,641
Hotel chains                                         322
Car rental companies                                 47
Car rental locations                                 23,665

2000 results

Bookings                                             395,600,000
Turnover (€)                                         1,856,000,000




                                                                                         16
Cruise database migration                                             Internship report



  6 - Sop hia Ant ipolis org aniza tion

    6-1 TSP
    6-1 TSP

BUSINESS DEVELOPMENT:
To complement the TSP portfolio with additional content, deals, processes, etc with the
objective to position Amadeus as a leading technology provider to the Hospitality,
Ground (Rail, Car rental, Insurance) and Maritime industries, both on the IT and
distribution                                                                      side.

MARKETING:
With the Amadeus customer groups as prime target, implement and drive the relevant
Marketing and Communication programs aiming at growing the non-air revenue and
profit. Manage a team of marketing experts and secure local ownership on each key
customer segment (Market, NMCs, E-commerce, Airlines).

HOSPITALITY:
The Business Unit Manager is responsible and accountable for the Profit & Loss and
projections from his suppliers, across all Amadeus customer groups. 100% responsible
for its objectives, budget, staff, product, sales and Marketing deliverables.

GMS (GROUND & MARITIME SOLUTIONS):
The Business Unit Manager is responsible and accountable for the Profit & Loss and
projections from his suppliers, across all Amadeus customer groups. 100% responsible
for its objectives, budget, staff, product, sales and Marketing deliverables.




                                                                                    17
Cruise database migration                                                          Internship report



    6-2 OSP
    6-2 OSP

The OSP department is contained in the GMS department and provides several other
services like Cruise, Insurance, Rail, Ferry, and Tour booking.




                        J.P. Hamon
                         President




                         V. Lextrait
                        TSP Director




               O. Rey                  M.F. Borderes
                HOS                        GMS




   J. Bonaud             F. Bauer                  J. Suay-Rincon       F. Pelissier
      CAR                  HCS                          OSP                PDT




                                                       R. Godec

                                                       R.J. Humphries

                                                       O. Mitride

                                                       J.L. Planque

                                                       P. Schmitt

                                                         OSP




                                                                                                 18
Cruise database migration                                                   Internship report




The mi grati on proj ect

  1 - The cu rren t Crui se A rch itec tu re

The cruise system provides information for travel agencies in order to create a booking.
There are two important processes in the booking workflow. The first is the availabilities
retrieval from the cruise providers and the second one the booking creation. The last
operation allows the user to integrate the booking to a kind of object containing
information about the client and his reservations (cruise reservation as well as air
reservation or other Amadeus reservation). For the first part – the availabilities retrieval –
we can suppose that the travel agency makes a query to the Amadeus database. In fact,
the database does not contain any information about the sailing. Each information is
retrieved in the provider system itself. The travel agency makes a retrieve request to the
Amadeus system which will forward this query to one or more providers. The response is
forwarded to the travel agency via the same way.
Although these information are not stored in Amadeus side, the cruise system owns a
database. It stores all the necessary information used in the graphical interface (named
Vista) and all data which have not to be frequently updated. For example we can get
provider‟s ships, currencies used by a special provider or some fields‟ length which can
change with the provider.

The server side in Amadeus is a TPF server. It is an old IBM operating system which is
designed to manage a big amount of transactions at the same time. The main part of the
development is made using Assembler or C function (near of the processor). The data are
stored in files into TPF file system named TPFDF (DF stands for Data Facilities). There
is a TPF front-end which deals with the incoming transactions and forwards the query to
an appropriate free backend. This solution has the advantage to work very fast. This kind
of IBM server can accommodate 64 processors and there is one backend per processor.

The Travel agencies, Amadeus and the cruise providers must be linked together and have
to share the same way to communicate. There is a standard data exchange protocol
provided by all the transport company, air company as well as cruise or car company
named EDIFACT (Electronic Data Interchange For Administration Commerce And
Transport). We can compare this data format to the XML one. So, as it is a standard
format, Amadeus decided that it will be the main data protocol between all agencies and
even between two different processes in Amadeus.

The cruise server architecture contains many parts. One of this is a farm of server which
contains the cruise database replication in order to distribute the data access. Using
Edifact to transport information, the server gets the correct information from the central
database.


                                                                                           19
Cruise database migration                                                     Internship report




                                        EDIFACT
                                        TCP/IP                    EDIFACT
                                                                  EDIFACT
                                                                  TCP/IP
                                        T
                                  I-EDI
                                         S
                                 TCP /IP
                                        O
                                        T                      EDIFACT
                                                               TCP/IP

        DCO M
        TCP/IP




                  DCO M
                  HTTP
                  TCP/IP                         A CCESS
                                             Reverse A CCESS
         DCO M     Internet
         HTTP                                    CS Cruise                  XML
         TCP/IP                                 A pplication                TCP/IP




  2 - The pr oblem
This architecture has been validated for a long time and works perfectly. However, the
Amadeus wish is to stop very high maintenance cost due to the amount of procedural
code in C and in Assembler and due to the difficulty to find qualified staff. Furthermore,
all the developments are very near from the processor and so too dependant from the IBM
servers. So the actual corporate policy is to migrate the main part of the development on a
Unix system with C++ object environment and to migrate the database into an Informix
or an Oracle database management system.

  3 - The mig rat ion m ission
According to this policy, my work during the internship was to settle the bases of a
migration from TPF server to a UNIX one and from TPF-DF database to an Oracle one.
For this last step I had to design the database with relational concepts (TPF is not
relational because it works with file architecture) and to fill it. The second and the longest
part of my work was to create services to ease the data management from a graphical user
interface.

The technologies used are always imposed in a big company like Amadeus. In fact to
create the server I had to use C++ because my application will be a tuxedo server
instance. There is a complete Framework to make the server as we will see after with the
Unix Open Backend architecture. Furthermore, to create the database, some Oracle

                                                                                            20
Cruise database migration                                                 Internship report


features are prohibited (like Triggers, stored procedure or object orientation). The
graphical user interface creation is also controlled by rules and the technology is
imposed. The graphical interface will be made in Java using a complete Framework to.

From the beginning, I identified a main difficulty: the information gathering about the
different layers creation. In fact, nobody in the OSP team has either the UNIX Open
Backend knowledge or the Java Framework or the C++ one (in fact all of the OSP team
develop with C or Assembler). From the beginning I had to find the technical solution by
myself.


  4 - Pla nning

Task name                                               week      Status
Subject definition                                      1         Completed
Study of the different layers in the Amadeus system     2         Completed
Own OBE formation                                       3         Completed
Own RFD formation                                       1         Completed
Edifact formation                                       1         Completed
Study of the existing data model                        1         Completed
Oracle model creation                                   1         Completed
Use case UML Analysis                                   1         Completed
UML server side Analysis                                1         Completed
Edifact messages creation                               1         Completed
OBE retrieval functionality implementation              2         Completed
Own Java Framework formation                            1         Completed
UML java GUI Analysis                                   1         Completed
Java retrieval functionality implementation             2         Completed
OBE insertion functionality implementation              1         Completed
Java insertion functionality implementation             1         Completed
OBE deletion functionality implementation               1         Completed
Java deletion functionality implementation              1         Completed
OBE update functionality implementation                 1         Completed
Java update functionality implementation                1         Completed
Global tests and bug corrections                        2         Completed
Total                                                   27


As you can notice, the total number of 27 weeks is greater than the total of weeks I
worked. This fact is due to the Olivier Mitride arrival in the team. With him, I was able to
develop several parts in parallel. I formed him in order to take over my work.

                                                                                         21
Cruise database migration                                                   Internship report



  5 - The Gene ral Arc hite ctu re
After a long search period I find all the components which will interact together.


                 Edifact            Special container &
                Grammar                     DbRequest

                                                 Business
                 Angel
                                                 Use case

                                                     Entry


                                                                             R
                                                                             F
     GUI           J           Smart       DSC-C++                           D       RFD
     Java          A           Aces                                          A        DB
                   P                                                         P
                                                                             I
                   I       E                                   CDB App
                       EDIFACT
                           d                                                 U
                                                                                     Cruise
                           if           1-Fill                               P
                                                                                      DB
                                                      3-use
                           a            
                                                                             S
                           c                                                 Q
                                          2-Call                            L
                            t
 Client                       OBE

In the rest of this document I will describe all the layers I made. In fact the Java graphical
user interface sends EDIFACT messages to the server side using a layer called JAPI
which provides facilities to transform java object to EDIFACT text. The SMARTACES
software gets these EDIFACT messages and fills C++ container (DSC) and calls an entry
point of the CDB (Cruise DataBase) management software I designed. After going
through several layers which check a lot of parameters, the SQL query is made by a
DbRequest layer using an Amadeus API (UP-SQL) to access to the new cruise database
or using RFD (Referential data) to access to the Amadeus share information (City list,
Currency list …).




                                                                                           22
Cruise database migration                                                      Internship report




Databas e migr ation
  1 - Exis ting dat a mo del
In the TPF-DF data model, there are two main kinds of file:
    - The generic data which are shared by all providers
    - The specific data which are specific to a provider
This difference is quite important. In fact, as I said before, the database is replicated on a
server farm. To do it, a server makes an EDIFACT query to know which data have been
updated since its last synchronization and makes other queries to download the
difference. To implement this system, each TPF-DF files has a version number to identify
the data which have to be downloaded. So each file has its own version number.

There are in fact, four kinds of files, the common files, the specific ones, and the tables
which contain the specific file union and special other files like the providers list or the
versions list.

                Specific tables (joined)                        Generic
                                                                tables
            •      City codes                        •     City codes/desc
            •      Currency codes                    •     Menu item codes/desc
            •      Menu item codes                   •     Price item codes/desc
            •      Cabin filter codes                •     Age group codes/desc
            •      Modes of transportation codes     •     Bed configuration codes/desc
            •      Passenger title codes             •     Credit cards
                                                     •     Cabin filter codes/desc

             Specific tables (standalone)            •     Fax capability codes/desc
                                                     •     Forms of payment codes/desc
                                                     •     Gift type codes/desc
            •      Cruise profile                    •     Insurance codes/desc
            •      Ship codes/names                  •     Modes of transportation codes/desc
            •      Occupation codes/desc             •     Passenger title codes /desc
            •      S chedule                         •     Regions/sub-regions codes/desc
                                                     •     Remarks
                    Special tables                   •     Currency codes/desc
                                                     •     Advisory codes
            •      Cruise Provider list              •     Dining codes/desc
            •      Table Versions
            •      Country codes/desc


As we can see in this diagram, most of these information are used in the graphical
interface. In fact, we have for example the ship table which contains every ship for a
special provider and will be displayed in a combo box.


                                                                                                23
Cruise database migration                                                  Internship report




                         Provider                          Ship




               Mode of transport




                                                             Currency
                                    City




“Provider” is extracted from the provider special table.
“Ship” is extracted from the ship specific (standalone) table.
“Currency”, “Mode of transport” and “City” are extracted from the specific (join) tables.


  2 - TP F-D F to Oracl e t ransf or mati on
The transformation was quite easy. In fact, I noticed that it is possible to transform all
these generic files into an Oracle table. Every specific table join could be joined with a
table which contains the provider information (the multiplicity should be many to many).
Every specific standalone table could be joined with this provider table with “a one to
many” multiplicity. For each other tables it is possible to create a table to store the data.

However, there are two main problems with the version management and the profile
management.

    2-1 The version problem
    2-1 The version problem

As we have ever seen before, we have to store the version number for each generic table
and for each joint between a provider and a specific table. The first idea is to place a time
stamp for each row which indicates the last time for a row modification. With a SQL
query it could be possible to retrieve all the updated rows and all the created rows. But it
is a very heavy mechanism (for each rows and for each tables we should ha ve to store one
more data). There is another problem using this way. It is not possible with this model to
detect the row deletion as a database modification.




                                                                                          24
Cruise database migration                                                 Internship report



The solution I found is to create a table which contains a version number and the table
name. For the specific table I had to create a joint table between the provider and this
version table. With this mechanism we can easily know, for instance, the currency table
version number for the Royal Caribbean provider.


The “create table” and the “drop table” maintenance operation is not difficult. You just
have to insert a row in the version table and if it is a specific table, you have to insert
another row into the joint table.




             Version                                        Provider
                                  *                     *
             table name                                     code
             version number                                 description
                                      version number


    2-2 The profile management problem
    2-2 The profile management problem

The profile file in the TPF-DF system lists several options for a provider or several field
sizes for the display function. Furthermore, some functions are not supported by some
providers but are supported by others. The problem is that the value types in this table can
different according to the rows. We can see the following display of the table for the
Royal Caribbean provider. The only way to view these data is to call a program into the
TPF system via cryptic entries.




                                                                                         25
Cruise database migration                                                  Internship report



The main problem of this representation is the data consistency. In fact I have to check if
in a field length there is a number and not an alpha value. The only way to make this
verification is to store the characteristic value type. When inserting or updating, a part of
the program will check that the entered value is correct. Furthermore there is a need to
control the data size (for the Y/N value for example). The value size will be store too.
Finally, I introduced a default value concept. In fact, I noticed that a lot of values are
redundant (shared between several providers). To not duplicate these information, I made
a joint table that allows storing the specific characteristic values for a special provider
which are different than the default value. Because the trigger usage is forbidden, all
verifications will be implemented in the server side.




                                                                                          26
Cruise database migration                                                                                                 Internship report



   3 - The Oracl e da tabas e mo del
                                  PROFILE_CHARACTERISTIC
                                      code
                                      description                             SHIP
                                      default_value
                                                                                  code
                                      value_type
                                                                                  provider_code
                                      value_length
                                                                                  description



                                      PROVIDER_PROFILE                                            OCCUPATION
                                            provider_code                                            code
                                            profile_code                                             provider_code
                                            value                                                    description




VERSION                                                                                                    PROVIDER_CITY
                                                                                                                                             CITY
   table_name           PROVIDER_VERSION                                                                           provider_code
                                                                                                                   city_code                      code
                           provider_code
   version_number
                           table_name                                                                              specific_description           description
   libelle
                                                                                                                   specific_id_country            id_country
   generic                 version_number
                                                                                                                   specific_id_state              id_state
                           PROVIDER_MODE_OF_TRANSPORT
MODE_OF_TRANSPORT                                                                                   PROVIDER_CABIN_TYPE
                                provider_code                          PROVIDER
  code                                                                                                                                        CABIN_TYPE
                                mode_of_transport_code                     code                        provider_code
  description                                                                                          cabin_type_code                              code
                                                                           description
                                                                                                                                                    description




                                                                                                                     SCHEDULE
 PROVIDER_CURRENCY
                                                                                                                          code
    provider_code
    currency_code                 PROVIDER_MENU_ITEM                                                                      the_year             REGION
                                     provider_code                                                                        the_month
                                                                                                                                                    code
                                     menu_item_code                                                                       duration_one
                                                                                                                          duration_two              description
                                                             PROVIDER_PASSENGER_TITLE
                                                                                                                          duration_three            super_region
    CURRENCY                                                    provider_code                                             duration_four
          code                                                  passenger_title_code                                      region_code
                                                                                                                          provider_code
          description               MENU_ITEM
                                         code
                                         description                PASSENGER_TITLE
                                         super_menu_item
                                                                       code
                                                                       description




CREDIT_CARD
   code                  GIFT_TYPE              PRICE_ITEM            AGE_GROUP                 FORM_OF_PAYMENT                     BED_CONFIGURATION
                            code                      code                    code                 code
   description                                                                                                                             code
   extended_payment         description               description             age_min              description
                                                                              age_max                                                      description

  ADVISORY              FAX_CAPABILITY
      code                                          REMARK            DINING_CODES                 INSURANCE
                           code
                                                        code               code                         code
      description          description
      blocking                                          description        description                  description
                           fax_group


                                                      The database ER model

                                                                                                                                                    27
Cruise database migration                                               Internship report




Edifact
  1 - Edi fac t con cep ts
In 1985 the United Nations (UN) decided to develop a single universal standard, which
resulted in the Electronic Data Interchange for Administration, Commerce and Trade
(EDIFACT) standard.
EDIFACT has the approval of the International Standardization Organization (ISO) and
offers a comprehensive support to all EDI needs. There has been a global acceptance of
this standard and many user group specific standards converged to EDIFACT.

An EDIFACT Message is divided in several parts:

      Message – is a single business transaction that in functional terms corresponds to
       a paper document such as an order or an invoice. A message is a grouping of
       segments.
      Segment – a part of a message that relates to a single „object‟ or „entity‟ like
       name and address, delivery location or item to be ordered. A segment is always a
       logical grouping of „data elements‟ (including composite elements).
      Data Element – the smallest individual pieces of information from which
       segments are built like postal code, telephone number, quantity or price. It is
       where information is located in a message.
      Composite element – a group of data elements that are intrinsically related in
       order to represent specific information. Normally, it has a qualifier element that
       defines the following data element.
      Syntax – the „grammar‟ that is used in structuring the data elements into a
       meaningful message.

The interdependence of the previous concepts is shown abstractly in the next diagram. It
is clear to see that segments compose a message and that these segments are in turn
composed by data elements. Please note that the message is encoded in text format.




                                                                                      28
Cruise database migration                                                 Internship report



  2 - E DIF AC T: an omni pres ent laye r in Ama deus
EDIFACT is used in all layers of the Amadeus architecture. The travel agencies and vista
server can communicate in EDIFACT, vista server and TPF front-end communicate in
EDIFACT and between Amadeus and the providers the communication is also made of
EDIFACT. Because it impacts all the elements, the EDIFACT message creation is very
controlled. Amadeus owns a committee which is able to validate the message creation or
to deny it. There are two committee session a month. It edits recommendations to create a
new message or to create a new segment. There are several important recommendations:

   -   the usage of two specific messages (a transaction) for one use case (one for the
       query the other for the response);
   -   a message naming convention: first letter indicates the message origin (U for
       cruise), the next three are free, the next last indicates the action (U for Update, C
       for creation, D for deletion and R for retrieve) and the last is Q for query or R for
       reply;
   -   the maximum existing segment reusability.

  3 - E DIF AC T mes sages cre atio n
The EDIFACT provides a way to transfer data from a client to server being language
independent. In fact after the grammar creation, you can transform the structure to C++
container or to Java container. You can fill these containers with data and transfer it in
EDIFACT to the server side which transforms it to C++ containers.

So, in my UML analysis stage, I extracted the uses cases and the business objects of the
application. I was able to create my own grammars. However, I extracted about 120 use
cases (four actions per table). With the committee recommendations I should had to make
240 different messages to manage the database. In a six months internship time limit it
was impossible to make all the messages, the server and the client side. So, with the OSP
team leader, we decided to create generic messages for the creation, the update, the
deletion and the retrieval. Doing this, it was certain that the four created transactions
should not be conform to the committee specification. So it impacts the model use case:




                                                                                         29
Cruise database migration                                                                             Internship report




                                                                      <<include>>


                                                                                  Retrieve generic elements
                                                                         <<include>>

                                               Retrieve elements
                                                                       <<include>>
                                                                                              Retrieve specific elements
                            <<include>>



           <<include>>                <<include>>                                     Retrieve element in RFD

                                                                             <<include>>


                    Manage database                                          <<include>>           Create an element
Database manager                                     Add an element
                                       <<include>>

                             <<include>>                                                      Attach element to provider
                                                                        <<include>>

                                                Delete an element
                                                                    <<include>>
                           Update an element                                          detach from provider




                                                                        delete a generic item




     3-1 The retrieve transaction
     3-1 The retrieve transaction

We can see the four transaction types. For the first message an indicator provides which
use case will be called. We must specify too, the provider code if needed (for the specific
retrieval) and scrolling information. In fact, an EDIFACT message has a maximum size.
To not exceed this limit, there is a need of a scrolling mechanism which requests the first
10 elements for instance and the next 10 while all the items are not retrieve. There are
two ways to make this scrolling mechanism. The first is to get all the information from
the database and to store the result in a part of the server and with a context server the
client will be able to retrieve sequentially its data. This way is very expensive in memory
for the server side and the development to implement the mechanism and the
parameterization will be quite long. The second way to do it is to make Oracle queries to
retrieve just the part of the data we want. In a “select” query you can begin the query at a
right index and retrieve a specified number of elements. In response you have to indicate
the number of element and the last item retrieved in order to continue the queries if the
retrieve is not ended.




                                                                                                                           30
Cruise database migration                                                 Internship report




Adding to this scrolling information, the response contains a part of the query which is
the table concerned by this retrieval. Furthermore, the response contains all the business
objects Edifact representation (segments). According to the scope we can easily know
which segment is filled. There are two kinds of objects: the generic ones and the specific
ones. So in the grammar, the generic business objects are represented by segment directly
accessible from the root of the message and for the specific o nes the segments are
accessible via a special provider. Finally there is a segment group to get the return status
of the query (error message or ok status).

Que ry (UCDBRQ)

                                   Query scope (table
                                   information)
                        Scrolling
 Provider               information
 information                             Generic information

                                                        Mode of
                                         Insurance      transport
Reply (UCDBRR)
                                         object         object
                                                                    Specific information




Scrolling   Reply
            scope         Error group

                                                             Provider   Mode of Currency
                                                             object     transport object
                                                                        object




                                                                                         31
Cruise database migration                                                 Internship report



    3-2 The create transaction
    3-2 The create transaction

The create transaction works on this model but the query and reply role is reversed. In
fact in the create query message you have to give the new object to the server in order to
create it in the database. So, you have to fill the correct EDIFACT segment that represent
the business object and describe the action to realize (scope of the query). There is no
need of scrolling mechanism.

The response is very simple. We just have to transport the return status in order that the
client knows the result of the execution (failed error or ok result).




Que ry (UCDBCQ)


            Generic business objects               Specific business objects group




Reply (UCDBCR)


                                  Return status
                                  management




                                                                                        32
Cruise database migration                                                  Internship report



    3-3 The delete transaction
    3-3 The delete transaction

The delete message is the easiest message because we just have to transport t he scope
(table information), the code of the item to delete and, for the specific table, the provider
code.

Que ry (UCDBDQ)


                                              Provider concerned



                         Object code
Table info (scope of the request)
Reply (UCDBDR)



                                  Return status
                                  management




    3-4 The update transaction
    3-4 The update transaction

The update is a clone of the create message. It contains the same segments and the same
data for the query but for the response to.

With these four messages, we can administrate the entire database according to the
business functions.




                                                                                          33
Cruise database migration                                                Internship report




Open BackEnd
  1 - Wha t is a n Open back end?
The Unix Open Backend provides the same kind of service as the TPF one but on a Unix
system and using a relational database. Thanks to the EDIFACT message which gives at
all the Amadeus systems the independency of language and operating system, the
migration between the IBM system and the Unix one is quite easy and can be made step
by step but finally we want to have this architecture.




The front-end role is to receive the query and to forward it to the freer backend which
provides the use case. The Backend is in fact a tuxedo server instance.

BEA Tuxedo is a middleware solution that develops, deploys, and manages mission-
critical applications in distributed computing environments. It is the backbone for
enabling transactions that stretch from front-end applications to back-office processes,
across any system, anywhere in the world. Tuxedo provides distributed transaction
processing and application messaging for applications that operate across multiple
hardware platforms, databases, and operating systems.

Tuxedo solution is based on servers, instances of servers and services. A server is an
executable that includes several services. An instance of server is a process that can
execute all services defined in its server. One server can have more than one instance.
Process stays alive during all servers live. A service is a particular function handled by
the instance.

In fact, the OBE is an instance of a tuxedo which provides some functions.




                                                                                       34
Cruise database migration                                                            Internship report



  2 - Gene ral Open bac kend arc hite ctu re
Amadeus has a special framework to develop an OBE organized in layers. These layers
are design to minimize the development cost in case of maintenance.




                                 Application server (SMART-ACES/Callback)


                             EDIFACT
   Transactional Monitor




                             translator       Entry point (Entry)
                           (MsgTranslator)


                                             Functionality (Use Case)
                                                                           Fiel d
                                                                         Container
                                             Specialization (Business)

                                             SQL Request (DbRequest)

                                             RDBMS client (UP_SQL)
                                                and RFD access

                                                                                           RDBMS
                                                                                            server

           2-1 UpSQL Layer
           2-1 UpSQL Layer

The aim of UP SQL layer is to encapsulate SQL features into C++ classes. Therefore,
this package is an API that contains several relational database access features:
- Connection and transaction handling,
- SQL queries and cursors,
- Data fields and input/output rows.
Defined classes are Template objects, containing STL- looks like iterators. There is also
an error management, by Exceptions and warnings handling. UP SQL is based on SQL
version 9.xx. In fact, although SQL is normally a standard, each relational database has
its own implementation. There is an ease of development, by accessing object API
instead of SQL. There is a possible integration in common objec t-based architecture. The
portability between RDMS is managed at UP SQL level, and no more at client
application level.
Furthermore, in this same middleware layer there is a facility to access all the common
data in the Amadeus system (such as cities list or currency code and description). This is
a C++ API named RFD (Referential Data) directly usable into OBE to make verification
or retrieve special shared data.



                                                                                                     35
Cruise database migration                                                  Internship report



    2-2 Field and Container Layer
    2-2 Field and Container Layer

To ease the mapping between the UPSQL architecture and the database representation,
the using of class that represents fields is recommended. In the database schema I have
two kinds of data type: VARCHAR2 will be mapped to Field_String that encapsulates an
Amadeus String and NUMBER will be mapped to Field_Int that encapsulates an int.
Fields also provide a complete exception system in order to validate the inner data.




The container is a set of fields which represents the object business data. So a container
must be created to map on each business object. There is another kind of container: the
container list which encapsulates a STL_List. This kind of list is used for all the retrieval
functions which can return a subset of the database (several rows).

    2-3 Dbrequest Layer
    2-3 Dbrequest Layer
In all three-tier architectures, the database objects mapping to business object ones and
the query organization is quite complex. In the Amadeus OBE Framework, the advice is
to make a special layer to encapsulate all the queries. Into the package, the framework
provides only one advice: one class per logical table. This layer provides only retrieve,
create, update and delete methods that use UPSQL prepared query to manage database.
For specific table several methods are added as the “attach an element to a special
provider” method (which create a row into the joint table), detach from a provider (which
delete a row into the joint table) and retrieve by provider which retrieve a list of row
associated to a special provider. Furthermore, I added several methods to access the
Amadeus common information (RFD) for the Currency class, the City class and the
Advisory one.

                                                                                          36
Cruise database migration                                                                 Internship report



    2-4 Automatic generation
    2-4 Automatic generation

The two first layers are really dependant on the database structure. In fact in the first layer
the container content data depend on the table column name and type, and the second
layer (dbrequest) contains the queries which manage the database. Furthermore, there is
one container class per table (in fact there is a container class per business object but each
logical table represents a business object so there is a container per table) and one
dbrequest class per table. The only things which change are the table name, the field
name and the type of field in the class. So, to save time, I made a generator which takes a
C++ template file and an xml representation of the database schema and which creates a
container file having the right fields and a dbrequest file which contains all the five base
prepared queries (create, delete, update, retrieve and retrieve all elements) and methods.
 <class>
  <table>currency</table>
  <champ nom="code" taille="3" type="string"/>
  <champ nom="description" taille="35" type="string"/>
  <action>
    <name>retrieve</name>
  </action>
  <action>
                         UP_SQLPrepQuery DbRequest_$(classname)::create_query("INSERT INTO $(classname_up) “
    <name>retrieveall</name>
  </action>                                                                    “VALUES($(insertparam))");
  <action>
    <name>create</name>  UP_SQLPrepQuery DbRequest_$(classname)::retrieve_query("SELECT $(retrievefields) "
  </action>                                                                     “FROM $(classname_up) "
  <action>                                                                      "WHERE $(keyname) = ? ");
    <name>delete</name>
  </action>              UP_SQLPrepQuery DbRequest_$(classname)::retrieveAll_query("SELECT * FROM( "
  <action>                                                                         "SELECT $(keyname),$(retrievefields) "
    <name>update</name>                                                            "FROM $(classname_up) "
  </action>                                                                       "WHERE $(keyname) > ? "
 </class>                                                                         "ORDER BY $(keyname) "
                                                                                  “)"
                                                                                   "WHERE row num <= ?");




   UP_SQLPrepQuery DbRequest_Currency::create_query("INSERT INTO CURRENCY “
                                                        “VALUES(?,?)");

   UP_SQLPrepQuery DbRequest_Currency::retrieve_query("SELECT code,description "
                                                         “FROM CURRENCY "
                                                         "WHERE code = ? ");

   UP_SQLPrepQuery DbRequest_Currency::retrieveAll_query("SELECT * FROM( "
                                                            "SELECT code,description "
                                                            "FROM CURRENCY "
                                                            "WHERE code > ? "
                                                            "ORDER BY code "
                                                            “)"
                                                            "WHERE row num <= ?");




                                                                                                           37
Cruise database migration                                                  Internship report



    2-5 Business Layer
    2-5 Business Layer

The business layer provides functionalities in order to manage the application business
logic. There is one class per business object which is in fact a kind of factory for business
container. This layer only knows the business rules and provides functional independence
between functional rules and database rules. This layer has a complete exception system
which allows the business error creation before making an Oracle query which throws an
Oracle exception. For instance the program is able to generate a NotFoundException
before making the deletion query.




    2-6 Usecase Layer
    2-6 Usecase Layer
The use case layer is in fact a kind of interface which provides all the application
functionalities. There is one class per functional use case. So, only in this layer there are
about 120 classes which are able to call the correct business object creation method. This
layer has a complete exception system to, but most of the exceptions thrown by this layer
are in fact previous exceptions thrown by the lower layers. This layer tries to encapsulate
the previous exception (BusinessException) to a UsecaseException in order to have a
good consistency for the exception catching in the upper layers.




                                                                                          38
Cruise database migration                                                Internship report



    2-7 Dispatcher Layer
    2-7 Dispatcher Layer

This layer is not recommended by the Open Backend framework. As I said before, the
EDIFACT messages are not conform to the committee recommendation because a same
message can have several scopes and the use case called depends on this query scope. So
it is necessary to have a layer which is able to call the appropriate use case regarding on
the query option. In fact, I created this layer in order to have the less dependence as
possible. If the OSP policy changes and if they want to create the 240 EDIFACT
messages the transformation of the server will be very easy. This layer throws exceptions
to, and adds a kind of exception in the system: the ActionNotFoundException which is
thrown when the requested scope is unknown. There are four kinds of dispatchers
according to the initial query. For the UCDBRQ message (Retrieval) the display
dispatcher is used, for the UCDBCQ message (Creation) the create dispatcher is used, for
the UCDBUQ message (Update) the update dispatcher is used and it is the same thing for
the deletion message (UCDBDQ).

    2-8 Msgtranslator Layer
    2-8 Msgtranslator Layer
The MsgTranslator layer is a very important layer. This layer takes care of translation
between the DSC Container and our own container. There is one class per message (one
for the query to decode and one for the response to encode). In fact, the DSC Container
contains a lot of information and for the application we just need a subset of this
information. Furthermore, for the encoding purpose, we have to translate our business
object to an EDIFACT representation (through other DSC Containers). Several checks
are done and a reply is created. If an error occurred in the lower layers, the error
translation will be made according to the error type.




                                                                                        39
Cruise database migration                                                  Internship report




    2-9 Entry Layer
    2-9 Entry Layer
The parent of all the other layers is the entry layer. This layer provides an entry point for
the EDIFACT message which arrives. These entries are called by the SmartAces front-
end. So there is one class per message type. This entry calls all the necessary methods
and constructs all the necessary classes in order to treat the inbound message and to
create an outbound message.




                                                                                          40
                                                                                                               XXX =
                                                                                                               currency

     SA_Backend             :                      :                  :                :                :                 :                 :                   :                       :
                      OBECruiseServer   MsgTranslator_UCDBCQ Container_UCDBCQ Container_Currency CreateDispatcher UseCase_CreateXXX Business_Currency   DbRequest_Currency   MsgTranslator_UCDBCR
           UCDBCQCallback( )
                                   decode( )


                                               decodeCurrency( )
                                                        fillContainer
                                                                                                                                                                                                    Cruise database migration




                                                                    fillContainer


                                                                   dispatch( )
                                                                                                                execute( )
                                                                                                                                create( )
                                                                                                                                                   exists( )
                                                                                                                                                   create( )




                                                                                                    translateOK( )

             sendMessage
                                                                                                                                                                                                    Internship report




41
Cruise database migration                                                 Internship report



  3 - Open Back End Re capi tula tion
It is a very long task to implement an entire Open Backend which is breakdown resistant.
I made a complete exception system which catches the most of problems as possible. A
part of these exceptions are transmitted to the client side (for data exception for example)
and another part activates special server treatments. For example, when the server loses
the Oracle connection the application stops and Tuxedo is able to reload this server in
order to re-establish the connection.

In fact, the longest task I made was the first OBE compilation using the different
middleware and libraries (RFD, Smart Aces, UpSql, Tracer for the logs …). The OBE I
designed is compliant to the framework recommendation. I made a maximum usage of
exceptions, of fields and containers. The server uses transaction for the query to the
database. For example, when an add request arrives to the server, this server must
automatically increment the version. However, if an error occurs in this increase process
or in the adding process, the transaction has to be roll backed.

The total of classes designed is upper than 250 and the total code lines number is upper
than 55 000 (comments included).




                                                                                         42
Cruise database migration                                                 Internship report




Jav a Graphical User Interface
  1 - Gene ral a rchi tec tur e
Like the OBE development there is a kind of framework provided by Amadeus for the
graphical interface Java client development. In fact, the implementation o f several layers
is recommended. In this framework there are three main layers. The first is the
middleware layer which is provided by the Amadeus middleware department in order to
deal with the communication between the client and the server. It also deals with the
EDIFACT grammar representation. Aids of the software “Angel”, the grammar is
translated to Java classes. The second layer deals with the business object model. It
contains few business rules (like verification of not empty fields), the mapping from
business objects to EDIFACT containers and the transaction creations (a transaction is a
complete message which will be sent to the server and the mechanism to receive the
response). Finally, the third layer is the graphical one which is able to display a business
object or a collection of business objects.



       GUI Layer
                                                Business object graphical representation
                                                User entries to create transaction

          uses



     Business Layer
                                                Business object
                                                Object to EDIFACT segment conversion
                                                Transaction
          uses



       Middleware
          Layer                                EDIFACT segment representation
                                               Server communication




                                                                                         43
Cruise database migration                                                                                  Internship report




  2 - busin ess laye r

    2-1 Concrete organization
    2-1 Concrete organization

The business layer is divided in three packages which deal with completely different part
of the business functionalities. A first layer called the business layer store the business
objects and the business objects integrity and validation, a second layer deals with the
encoding or decoding from these business objects to EDIFACT groups and segments and
the final third layer deals with the communication with the server and manage the server
exception (like time out).


                                                    Business Layer
                                                (from Java Application)


                                                Business Transaction Objects
                                             ConcreteBusinessTransaction
                                              (from Business Transaction Objects)




                         wrap/unwrap                                    find the correct object in the tree


                                                                               Business Objects
                        Adapters


                           Adapter                                                  BusinessObject
                         (from Adapters)          get/set the values             (from Business Objects)



                                      1                         calls
                          1

                                                            uses

                                                  Middleware Layer
                                              (from Java Application)
                                          Grammar
                                   (from Middleware Layer)

                            1..n                 1..n

                      Group                  Segment               Interface
                   (from Grammar)          (from Grammar)       (from Grammar)




                                                                                                                         44
Cruise database migration                                                   Internship report



    2-2 Business object layer
    2-2 Business object layer

The object package is the first package to implement. The business object definition was
the first I made during the database analysis study. All objects provide some common
functionality like the capacity to analyze its fields and to return an exception if one of its
fields is invalid. Another kind of business objects is the collection of the original business
objects. In fact, I created this for the main reason that the principal use case called by the
GUI is the display of an entire table. It is easier to display in one shot a business object
which contains a lot of data than a lot of little business objects. Furthermore it allows
general mechanisms on lists.




This layer allows being independent of the EDIFACT containers which contain several
useless data.

    2-3 Adapter layer
    2-3 Adapter layer

As we will see in the next section (the transaction part), the business transaction code will
pilot the wrapping and unwrapping of the business objects into the EDIFACT classes
generated by Angel and the reverse.
Writing an adapter between a business object (and eventually its aggregated objects) and
its EDIFACT representations is a task that must be done in the spirit of reusability. This
is the most difficult dimension of the problem because it is always possible to write a
specific huge linear function in the code of the business transaction method to perform
the three steps of the transactions (wrapping, send and receive, unwrapping).

                                                                                           45
Cruise database migration                                                 Internship report


The problem with this solution is that it is very hard to maintain and generates a very big
amount of duplicated code. Moreover, all transaction know the global tree of business
objects and EDIFACT classes, which is not a really object oriented way of programming.
In order to limit this code the maximum possible and to make this code quite easy to
maintain, the wrapping layer should exhibit units of wrapping/unwrapping that take in
charge the wrapping and unwrapping of parts of the business model. The code of the
business transaction would be the calling of those wrapping classes in the EDIFACT
transaction context.

So there is one adapter per business object. These classes provide a wrap method which is
able to transform the business object to the correct StructureContainer (all segments and
groups generated by Angel inherit from this class) and a unwrap method which translates
a special StructureContainer to a business object.

However, there is a problem doing this. For the transformation from the EDIFACT
grammar to Java container there are several rules. Each EDIFACT segment has a name
used for the generation of classes. For example the CPY segment which represents the
providers has the name “Non-Air Company information” and the generation will produce
a Java class named “NonAirCompanyInformation”. So there is no problem for this kind
of segment. However, for the group segments like schedule information which is an
aggregate of several segments, there is no name. So a name will be automatically
generated and this name will be prefixed by the message name. In these conditions it is
quite hard to reuse the same adapter for each message. However, the way to access to the
segments into the group is the same for all the same groups in different messages.




                              Schedule group (UCDBCQ message)




                                                                                        46
Cruise database migration                                                             Internship report



For the update message, this is exactly the same class diagram except the group class
name. So according to the message we want to wrap the given parameter type must
change. There are several ways to resolve this problem. The first solution is to make a
strategy pattern and override the wrap method into the concrete strategies. But the
drawback of this solution is to have the creation of three classes instead of one. The
solution I wrote uses the java.lang.reflect package. Because the way accessing to the
segments are the same for every message and because there is no inheritance between the
generated class groups, I construct dynamically the correct instance of the class group,
and I dynamically call the getInitXXX methods.



 StructureContainer cont = null;
 PlaceLocationIdentification region = null;
 StructuredDateTimeInformation date_info= null;
 Quantity duration_qty = null;

 Constructor construct = instanciateClass.getConstructor(null); //instanciateClass is the group class : one of
 CreateCruiseElementDatabase_schedule.class and UpdateCruiseElementDatabase_schedule.class
 cont = (StructureContainer)construct.newInstance(null);
 region = (PlaceLocationIdentification)instanciateClass.getMethod("getInitRegion",null).invoke(cont,null);
 date_info = (StructuredDateTimeInformation)instanciateClass.getMethod("getInitPeriod",null).invoke(cont,null);
 duration_qty = (Quantity) instanciateClass.getMethod("getInitDuration",null).invoke(cont,null);

 Schedule schedule = (Schedule)table;
 region.getInitLocationDescription().setCode(schedule.getIdRegion());
 …




    2-4 Transaction
    2-4 Transaction

This layer is the most important layer for the application. It pilots the others layers,
calling the correct adapters in order to send business objects to the server side and in
order to construct other business objects from the response. Furthermore, with the help of
the middleware layer, it is able to create a communication with the server and to call the
send and receive methods. For this application, there are four main kinds of transactions:
the display all items transaction, the update transaction, the delete transaction and the
create transaction. However because the message contents depend on the query scope (the
filled EDIFACT segment depend on the targeted table), I had to create a special kind of
transaction per table. The called adapters are not the same if we want to create a provider
or insurance. Nevertheless, several mandatory segments are represented in all messages,
so it is possible to create facilities to decode automatically these mandatory segments.
Furthermore these facilities provide the send and receive functionalities.




                                                                                                        47
Cruise database migration                                                 Internship report




  3 - Grap hical l ayer

    3-1 Graphical layer role
    3-1 Graphical layer role
The graphical layer has three main roles:
    - the business object display using dedicated beans
    - the management of user entries
    - the creation of transactions
Because the development of the graphical interface is a quite long job and the
maintenance is often complex, I tried to make a big analysis work and I tried to use the
maximum of pattern which helps the maintenance in order to save time after. In this part
we will not see the entire graphical layer I created but I will just focus on the most
interesting parts.

For the organization of the graphical view, I tried to keep the same flow and design as the
Visual EDIFACT software for one main reason: a big part of the Amadeus staff has
already used this tool. Furthermore, I developed several advanced functionalities like the
usage of a cache of objects in order to not send the transaction directly and to cancel
modification.

The graphical interface is divided in two main parts, the left one shows the different
tables and the right part is in charge of displaying the table content in a table graphical
component contained in a tab. There are several buttons in order to make action on the
table (add, delete, update) and several buttons in order to make action on the transactions
(validate or cancel transactions). There is refresh mechanism. If we add a provider we can
refresh the list by double clicking on correct leaf of the left tree.




                                                                                        48
  Cruise database migration                                                    Internship report




                                                                                        List
                                                                                        Action
                                                                                        buttons




                                                          Update frame
Menu generated from
database version table query       Transaction action buttons




      3-2 A MVC usage example
      3-2 A MVC usage example

  I tried to use a maximum of the MVC pattern in order to have to good separation between
  the “View” which is the graphical part and managing graphical problems, the “Model”
  which is the class used to access data and the “Controller” which manages all instances.
  For example we can see the mechanism of the left menu. In fact we have a controller
  which is able to get the graphical event thrown by the graphical object (in this case it is a
  double click on a tree leaf). It is able to treat this double-click and according to this click
  calls the appropriate model (in our case it‟s menu model) method. If the state of this
  model changes (the number of leaf changed in the menu), the model throws an event
  which is caught in the graphical class which will be refresh using the new state of the
  model.

  So the first step in this case is to create a model event system. The “MenuModel” will be
  a kind of “ModelObserved” which is able to throw “ModelEvent” to the declared
  “ModelListener”. The display class (MenuView) encapsulates a correct “ModelListener”,
  and so, this class will react to the model changes.




                                                                                              49
Cruise database migration                                                Internship report




The second step is to create the controller which will modify the model state according to
the action made on the graphical layer.

The mechanism is a MVC pattern implementation. With this it is quite simple to add new
comportment and new view without changing the model.




                                                                                       50
Cruise database migration                                                   Internship report



    3-3 A cache of objects
    3-3 A cache of objects

The Amadeus Framework recommendation is to create a cache of business object, to
work on it and to validate or to cancel all modification made. This mechanism, described
in the framework, advocates to duplicate the objects (make a kind of clone), to work on it
and to replace it by the first object in case of cancel or replace the first in case of
validation. However, the application I developed can deal with a big amount of data and
it will be an error to clone these kinds of “big” objects because of memory problem. So
the first solution I thought was the duplication of the objects but instead of keeping it in
memory, store it in the file disk system (serialization) and get it when the application
need it. But we have not a need of this system. In fact, from the beginning, I knew that I
used graphical table components which have their own model. So I decided to use this
model to store a copy of objects. In fact, I used table model as a temporary cache of
business objects. All modifications will be made in this model and in case of cancellation
we have just to reload the table from the initial data (deleting all elements in the table
model). So, I wrote my own table model inherited from the Java swing one. It enables me
to implement a tag system in order to know the new rows, the rows which will be deleted
and the updated rows and using a special table renderer to highlight these rows with
different colors.

    3-4 Transaction storage
    3-4 Transaction storage

As we have just seen before, the transactions are not directly transmitted to the server
side. So, it is important to have a way to store it and a way to execute it after. To
implement this functionality, I designed a kind of “Command” pattern. In fact, when a
user wants to delete, update or create an element it automatically creates a database
modifier object. If the transaction is valid (does not already exist for example), this object
is added to an object which stores every commands. This last object is able to execute all
the transactions stored.




                                                                                           51
Cruise database migration                                                    Internship report




The “execute all” method returns in a status array which provides the return status of all
the transactions. Furthermore with this system it will be possible to select only several
transactions to execute instead of executing all. A last feature of this system would be the
serialization of these transactions in order to make a backup if a lot of operations are
made.

    3-5 Interface automatic generation
    3-5 Interface automatic generation

As I said before, a graphical client development is a quite long job. In a six month long
internship it was very difficult to develop the server side, the transport layer and the client
side. So for the graphical interface I used several shortcuts. One of these is the generation
of panels for all the adding and update operations. Normally I had to develop, for all the
business objects, a graphical panel for the adding action in order to set new information
(it is the same thing for the update use case). Instead of this I automatically generated all
these panels using field description objects. In fact, when I construct the table for the
display use case, I also construct a collection of field descriptions which are used to know
the column names. This object encapsulates the field type (number, String, list …), the
field size and several others properties. One of these is a kind of function pointer which
targets a right setter method in the associated business object in order to fill this business
object.




                                                                                            52
Cruise database migration                                                   Internship report



The complete principle is the following. The first step is to create an array of field
descriptions. Each field description is mapped on a business object field. We define all
the display properties for each field (type, size) and one field setter which, with an object
and a value, is able to invoke the correct setter method on this object. Using this field
description array, the graphical interface is able to be displayed. When the user validates
the new information, we get all the information set, we construct an empty business
object and for all field descriptions we call the field setter contained in it with this empty
object and the value filled by the user. At the end, the business object is filled with the
user entries, and we can invoke the validate method on this object in order to know if the
contained values are correct.




The ActionProceedUI is the auto- generated interface. It allows several other advanced
functionalities like the capacity to have a help to automatically fill fields doing a query to
the database.

  4 - Grap hical Use r I nte rfac e r ecapi tula tion

The GUI provides all the wanted features. We have seen in this document only a small
part of the development I made but the most interesting. In fact, I developed for the GUI
more than 230 classes. As the server side, this client is resistant to a lot of breakdowns
like time out, connection lost with the server. It was tested during a quite long period and
it normally blocks all the incorrect user entries.



                                                                                           53
Cruise database migration                                                  Internship report




Conclusion
  1 - Wo rk co nclusi on
All the OSP team wanted features have been developed. The total software is very
resistant to the main part of error that can be thrown by the system or by the software
itself. However, before this software goes on a production stage, there is some feature
missed as the security management. For the moment everybody can access and can
modify all the data contained in the Oracle database. From the beginning I took care of
this thing. So, the first action that the GUI user makes for the moment is a login step. The
second step is to make a query to the server in order to get the tables. At this stage we can
easily block the display of some tables. Furthermore, I created an easy way to activate or
to deactivate action for a special table.

Furthermore, there is another longer problem to solve. This is the EDIFACT message
modification in order to be compliant with the EDIFACT committee requirements.
Instead of the creation of four transactions, it is really probable that the committee orders
the creation of one real transaction per use case (240 messages). Furthermore, in order to
pass the committee validation, a big documentation of all the messages created should be
done.

The work I made is the first part of the cruise application migration from a TPF system to
a Unix one. It is a little step for the project but it is the foundations of the future
developments. In fact, my work will not be sunk into oblivion. I formed a new comer in
the team to the software I designed and his work will be to take over the project and to
add several functionalities like the low cost retrieval from the Oracle database.




                                                                                          54
Cruise database migration                                                   Internship report



  2 - In ter nship concl usion
This internship was a very positive experience to end my studies and to begin a
professional life. It increases my CV wealth and it allowed me to improve my skills in
several areas in a professional context.

The subject was very ambitious because it will be the base of other application. So, I
want to thanks the managers and team leaders for trusting me. Furthermore, it was a very
long task to make the analysis of all the different software parts and its implementation.
My planning was good until the end. I totally finished the software just few days before
the end of the internship.

The big advantage of this subject was the development of all the three-tier architecture
parties. I really like this kind of architecture and having a first professional experience on
it, is very important for my future carrier. Furthermore, I used several programming
language (Java, C++), several architectures (Tuxedo, Oracle) and I registered my work
into a corporate framework. I also saw a different way for the mapping between business
objects and the database schema than the other I have seen before (EJB, JDO …).

Moreover, it is very interesting to create an entire program from the beginning to the end
and to make the analysis of the entire software. It allows me to have a UML professional
experience and to improve my skills in this domain. Finally, because I had to find
resources by myself to construct all the parts, I improved my learning capacity.

Amadeus is a really big software company which uses a lot of norms and procedures. So
it is a good experience to register my work and my working methods into these norms. It
is also a good experience to try to find resources into the right service and the right
person. Because the halves of the employee are foreigners, the Amadeus experience
improved my functional English level.

I made three internships in different kind of company: a small (5 persons), a medium (60
persons) and Amadeus (1600 persons). Even if the subject was good in the first two
companies, I‟d rather work in an Amadeus like company because the subjects are more
interesting, the budgets are bigger and the impacted people to.

This experience is a good springboard for my future carrier. This experience allows me to
have no difficulty to integrate others companies and thanks to this internship I have
already signed an unspecified duration contract with a society in order to work as
consultant into the Amadeus structure.




                                                                                           55
Cruise database migration                                    Internship report



Appendix
  1 - Sev eral gra phica l use r in ter face
  screens hots




                            Connecti on to the server side




                                                                           56
Cruise database migration                                                       Internship report




 Delete the “teacher” occupati on (red), add “ dri ver” and “commandant” occupati on (green). The
                                 transactions are not vali dated yet.




                                                                                                57
Cruise database migration                                                    Internship report




                      Transacti ons successfully vali dated (green bullet)




                                                                                           58
Cruise database migration                                                  Internship report


  2 – EDI FA CT messa ge ex ampl e
Retrieve all occupations for the Amadeus Cruise IT Hosting demo provider.

UCDBRQ

Grammar:




Implementation sample:

CPY+++ACD+AMADE US CRUISE IT HOS TING DEMO'&             Provider reference (ACD)
ADT+131+99'&                                             Scrolling Info (99 first element)
IRV+ CC+++:26::OCCUPA TION::SPT                          Query scope (Specific Occupation
                                                         table)

UCDBRR

Piece of grammar:




Response sample:

ADT++5:SQL'&                         Scrolling info (5 elements retrieved the last is SQL)
IRV+ CC+++:::OCCUPA TION::SPT'&      Table scope (repetition of the query scope)
STX+0:1:A:OK'&                       Return status (everything is OK)
DUM'&                                DUM segment indicates we are in the specific group
CPY+++ACD'&                          Conc erned provider (A CD)
EMP+1++ADM:::ADMIN'&                 First occupation retrieved
EMP+1++CAP:::CAPITAIN'&              Second occupation retrieved
EMP+1++COM:::COMMA NDA NT'&          Third occupation retrieved
EMP+1++DRI:::DRIVER'&                Fourt h occupation retrieved
EMP+1++SQL:::SQUADRON LEADE R        Fifth occupation retrieved




                                                                                             59

				
DOCUMENT INFO