TravelData

TravelData is one of the most important pieces of Smartpoint SDK. TravelData is a library that allows searching for data and creating bookings via a neutral interface (i.e., one that is not tightly coupled with Galileo Web Services or Galileo terminology). TravelData abstracts most of the plumbing that is required to talk to the host. Smartpoint has a dependency on TravelData but TravelData does not have a dependency on Smartpoint.

TravelData was created to eliminate the need for front-end developers to build XML manually and understand host-specific naming and conventions. Therefore, TravelData allows front-end developers to focus on user interface design rather than having to understand back-end travel constructs.

TravelData supports Galileo Web Services and Galileo Desktop (via XML API Desktop). For developing Smartpoint plug-ins only the Galileo Desktop factory should be used. The correct instantiated factory will be available through a property in Smartpoint. This factory and the parent factories, CommunicationFactory, SessionedCommunicationFactory, and GalileoFactory, are the only ones supported. TravelData is ready for XMLPro and Universal API; however, these products are not supported by Smartpoint SDK and should not be used.

Supported functionality

  • Air, including availability, low fare shop, and fare display
  • Hotel, including availability, details, and rules
  • Car rental, including availability, description, and rules
  • Booking file, including creating, finding, and retrieving
  • Client files (Galileo and Apollo only)
  • Queue functions (Galileo and Apollo only)
  • Terminal transactions
  • Pass-through XML transactions (available if you need functionality that is not currently supported in Smartpoint SDK but is supported in Galileo Web Services or XML API Desktop)
  • Travelport Universal API and Worldspan XMLPro proof-of-concept code only

Factory architecture

Factory pattern used to populate generic objects, such as low fare search results or a booking. When substantiating a specific factory, any credentials needed is part of the constructor:

CommunicationFactory factory=new GalileoDesktopFactory("xxx")

For Smartpoint, you should not substantiate your own factories. Instead, Smartpoint has a "Get current connection" and it will give you the correct factory.

CommunicationFactory contains many travel methods. In addition, the following factories inherit from CommunicationFactory:

  • SessionedCommunicationFactory contains all of the methods that require sessions.
  • GalileoFactory contains all methods related to Galileo.
  • GalileoDesktopFactory contains all methods related to Galileo Desktop.
  • GalileoWebServicesFactory contains all methods related to Galileo Web Services.

Sessions and Smartpoint SDK

TravelData handles sessions for Galileo Desktop and Galileo Web Services. Galileo Desktop takes care of sessions for you. Galileo Web Services creates sessions when you need them and keeps them active as long as you need them.

Communication thread

It is recommended that you use a single thread for communication. TravelData is dependent on Galileo Desktop, and Galileo Desktop only supports a single, concurrent transaction. In TravelData, once you get into the core code that communicates with Galileo Desktop, a lock is placed on the submit section that prohibits the code from proceeding until the lock has been removed (i.e., the previous instance that called into that code has been released). As long as you have a single instance of TravelData, you can multi-thread, but be aware that your thread will be locked if there is another thread that tries to interact with Galileo Desktop.

Cache

TravelData uses a local cache for decoding and validating information such as airline and airport codes. Smartpoint automatically handles the cache file, putting it into the user's application folder with the correct connections. However, as a Smartpoint SDK developer, if you write code against TravelData and if errors or warnings about the cache file display, you may need to edit the app.config file and add a connection string that points to the correct location of the cache.

The cache should be in a writable location or a temporary path should be added to the connection string. TravelData does not need to write to the database; however, Microsoft SQL Server CE requires that the database be in a writable location.

How to modify the cache location

The cache is an SQL Server CE 3.5 database called TravelData.sdf. This file is stored in the cache subfolder by default but can be stored anywhere if the TravelDataConnectionString in app.config is updated with the new location.

Next Steps

Understand how to use TravelData.