Table of Contents

SwOTA: Session and State Support

Being based on the OpenTravel public specification and originally targeted towards GDS client application types, the Versonix OTA supports transactions that occur within a stateless environment. Within the messages, this is reflected by a tendency to include data in the response that was defined in the request. With this design, message senders and recipients are not forced to "remember" data between calls.

In addition to stateless environment, Versonix OTA supports stateful flow and the session context (working in a session). Though stateful manner is usually not the way GDS systems choose to integrate with OTA, the stateful mode does provide more flow flexibility and wider functionality.

Session and Temporary Storage

Notion of session in Seaware OTA is similar to what you can see in many other applications. This is user session that can be considered as user specific context to store temporary objects, apply security restrictions, etc. It is created when user logs in and destroyed when user logs out (or by timeout). In a sense this is a kind of state that is associated with the user in Seaware.

User Types

There are several types of users (roles) in Seaware:

  • Travel Agents: Agents work on behalf of some Travel Agency. Selling through travel agencies is the most common way to sell travel packages, tickets, etc. in travel industry.
  • Res Agents: Company's staff members that can make reservations (in call centers, for example). Res agents usually make reservations on behalf of some special internal agency.
  • Consumers: Direct customers that can make reservations by itself through the B2C web interface (or any other way).

API Usage Modes

Versonix OTA API calls can be used in:

  • Session context: Login request provides session GUID, then subsequent requests use the session GUID, finally logout request destroys all temporary session objects
  • Session-less context: POS (Point Of Sale) identifier ("login") is provided in each request, requests/calls are separate and are not connected by a single session

AND/OR

  • Stateful mode: Booking management using temporary storage, ability to lock (create), edit, then store or unlock a booking
  • Stateless mode: Each request has it's own session/state context, no access to temporary storage (except special case of CabinHold) and user session, everything in a single call. Largely used by GDS systems.

Mode Details

For detailed information about each mode, see:

Benefits of Each Mode

Stateless Mode (Default)

Benefits:

  • Simpler integration
  • No session management required
  • Compatible with most GDS systems
  • Each request is independent

Use when:

  • Building GDS integrations
  • Simple booking flows
  • No need to hold inventory across multiple requests
  • Prefer simplicity over advanced features

Session Mode

Benefits:

  • Maintains user context across requests
  • Automatic POS handling
  • Better tracking of user actions
  • Improved security

Use when:

  • Building web applications
  • Need to track user activity
  • Want simplified authentication across calls
  • Working with authenticated users

Stateful Mode

Benefits:

  • Hold inventory while building bookings
  • Edit existing bookings with inventory protection
  • Build complex bookings in multiple steps
  • Prevent concurrent modifications

Use when:

  • Need to hold cabins/inventory temporarily
  • Building bookings in multiple steps
  • Editing existing bookings
  • Need to protect against concurrent modifications
  • Want to preview changes before committing

Combining Modes

These modes can be combined. For example, you can work in session context while using stateful booking mode, or you can use stateful mode without sessions (by providing POS in each request).