Table of Contents

Basic Seaware Concepts

Sessions and Temporary Storage

Notion of session in Seaware 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 themselves through the web interface (or any other way).
  • Internal Users: Special user to do some internal utility tasks.

User session is always created when Seaware is used through rich UI (SwMain) but not always mandatory when you use other APIs.

API Usage Modes

Versonix OTA API calls can be used in:

  • Session context: Login request provide sessionGUID, then subsequent requests use the session GUID, finally logout request destroys all temporary session objects
  • Stateful context: Booking management using temporary storage, ability to lock (create), edit, then store or unlock a booking
  • Stateless manner: 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 uses by GDS systems.

Common Objects

Booking Source

SwOTA Booking source name must be provided in every request inside the POS element. It usually contains the Seaware Booking Source value, though can also contain Distribution Channel value.

The booking source defines the way reservations come from. They affect the way the SwOTA request is processed as most configuration (Seaware External Systems, Seaware Settings) are done separately for each booking source.

Agency and Agent

Agency represents a Travel Agency in the system. All reservations must be made on behalf of an agency. This could be your travel agency, or a virtual agency for direct customer bookings.

Agent is an individual staff member associated with an agency. Agents can make bookings on behalf of their agency.

The API supports authentication at either the agency level or individual agent level, depending on your integration needs.

Client, Household and Reservation Guest

Client is a real person who is supposed to purchase some of company's (cruise line) service. This is a customer from company's point of view and a main subject of usual CRM (Customer Relationship Management) system. Seaware has a kind of CRM embedded in order to record information about customer activities, preferences, etc. This information is usually used for marketing purposes: in order to encourage new customers to use some services, to award loyal customers, etc. For that purpose Seaware has an advanced pointing management systems, customer programs, coupons, etc.

Household is a concept to define family in Seaware. Each client must belong to some household object (even if it is the only member of that household). This concept is used to:

  • Decrease number of data stored in the database – some information common for all the family members (like addresses, phones, etc.) is stored just once for all the family members.
  • Record activities at family level. It is useful to produce some family specific marketing materials, promotions, etc.

Guest is a reservation guest. This concept very differs from Client. Client is a real person, unique within the whole system. Guest is not a person (Guest ID is not equal to Client ID)! It is a kind of placeholder for a client in a reservation. This is an abstract reservation component and should be unique within a reservation only. In the end of booking process each guest must be associated with the client (it's obvious – real person is supposed to travel) but at some moment in the booking process reservation can have unnamed guests, not associated with any real persons.

SwOTA processes clients but the concept of household is hidden from the API user. Depending on SwOTA related Seaware Settings new clients can each be created in their own household, or a party of a new booking can be put into a single household.

Sail Activity and Sail

Seaware has two concepts to define ship sails: Sail Activity and Sail.

Sail Activity object is related to Sail Calendar and can be considered as an event that happens with some ship at some specific time in some specific port. For example, Sail Activity could look like: "Ship A has departure at 01.01.2011 12:00 in port B pier C". Other types of sail activity events could be: arrival, repair, etc. (all activities are customizable). Set of sail activities define sail calendar for some ship. Many objects in Seaware reference to sail activities, mostly to departure and arrival events.

Sail is a concept that is related to ship sailing activities that are available to sell. Sail is defined as a process (or time interval) between two sail activity events: departure and arrival. In other words sail is a moving of a ship between two ports.

Package

Package concept is related to products that can be sold in Seaware. There are two kinds of packages: primary package and dynamic package.

Primary Package defines the main product in Seaware – sail (voyage). Formally speaking this is a moving between two ports on some ship at specific date. Currently primary package can contain one sail only. Primary package is not mandatory for reservation but if reservation is made for some sail that sail must be included in form of primary package object.

Addon

Addon object represents a complimentary product or service that can be provided on board or on shore in addition to main package products. The most often used addons are: breakfast, dinner, insurance, etc. In additional to manually added addons it's possible to tell Seaware to add addons automatically because of some conditions (defined by business rules).

Allotment

Allotment feature in Seaware is intended to allow reserving some inventory (cabins or car deck space) for some customers. If customer has allotment this guarantees them availability of specific amount of cabins in specified cabin category or some space on card deck.

Allotment ID should be specified at reservation time in order to tell the system that you are going to reserve accommodations from allotment. If there are no space in allotment that accommodations will be taken from common inventory.

Accommodation Request and Inventory Allocation

Each reservation made in the system requires a part of general ship inventory in order to accommodate reservation's guests and cars. At reservation time this inventory is requested. These requests are made in form of general availability data without specifying allocation details. For example, reservation requests some amount of places or cabins of some specific category. If there are available cabins of requested category they are reserved for this reservation but real places or cabins are not allocated. If there are no available cabins of such category this request can be put in wait list.

Real inventory allocations are made when cabin assignment is done (usually some time before check-in or during check-in). During this process reservation accommodation requests get exact places in a ship – cabin numbers. If there are no more inventories for wait listed accommodations they are refused.

Reservation

Reservation object is the central object in the system. The core of Seaware is booking engine and the core functionality is booking management. Reservation object can contain many child objects.

Some of them can be specified in corresponding request message (when reservation is supposed to be created). These children represent reservation guests, accommodation requests, products to purchase (packages, addons), promotions to apply, etc.

Other children are output only – they show reservation specific information that is calculated by Seaware. These are mostly pricing and accounting specific objects.

Group

Group in Seaware is a kind of booking. Group has inventory request, for example, several cabins on a sail plus car deck, etc.

Inside the Group simple reservations are created which are Group Delegates. They use inventory from the Group request. These Delegates have the Group ID value on them unlike simple reservations which have this field empty.

So Group is a kind of shell above simple reservations. Group usually is created for a Travel Agency to occupy inventory. Later on Travel Agency makes Delegate bookings from this Group request.

SwOTA does not provide functionality to manage groups (create or modify), but it supports creation of new group delegates.

Travel-With Functionality

Seaware has an ability (exposed in Versonix OTA API as well) to define a kind of reservation affinity. Some reservations (effectively, their guests) can be marked as traveled together in order to get some preferences in the future (like cabins close to each other, seats on the same table in the restaurant, etc.).

External Systems

This functionality is used to store in Seaware mappings between Seaware objects and some objects of some external systems that are intended to integrate with Seaware. Usually these mappings have business meaning and should be supported by business line persons so Seaware has corresponding UI for that.

SwOTA largely uses the external tables to store value mappings (e.g. ports, country codes, etc.) and some configuration parameters (e.g. pricing itemization).