Seating Manager API (beta)
Seating manager handles seating offers. A seating offer contains data for the seats in the material used on a dated service journey. Each seat has a list of seat usages that hold reservation information for station pairs on the journey.
Seating offer creation
A seating offer will be created when seating manager receives an event from scheduled stock containing information about a dated service journey and corresponding material.
Material
The events from scheduled stock contain links to material in rolling stock. Seating manager will fetch the material definitions from rolling stock.
Seating offer modifications
Events from scheduled stock may contain changes to a previously created seating offer. This will usually lead to the creation of a new version of the seating offer.
Seating offer deletions
Events from scheduled stock may contain information that a seating offer is no longer valid. The seating offer will be marked as inactive. It will not be physically deleted.
Seat reservations
Seating manager subscribes to order events. This will create reservations and update the seat usages of affected seats.
First version of a new reservation
The first version of a reservation is created in status DRAFT. New reservations lines may be added. Corresponding seat usages will be updated. Reservation lines may be deleted. Corresponding seat usages will be reset.
When the reservation is confirmed, the status will be changed to CONFIRMED.
New version of a confirmed reservation.
The new version will be created as a copy of the confirmed reservation in status DRAFT. New reservations lines may be added. Corresponding seat usages will be updated. Reservation lines may de deleted. Corresponding seat usages will be reset only if the reservation line was originally adde in the DRAFT reservation.
When the reservation is confirmed, reservation lines no longer present, will reset seat usages. The original reservation will be set to DEPRECATED. The new reservation will be set to CONFIRMED.
Modification of a confirmed reservation
A change in a confirmed reservation, from for example a PUT Request, will result in a new draft version of the reservation. The new draft reservation will only contain reservationLines defined in the request itself. All the new reservationLines and old reservationLines with new seats will have new seatUsages.
Cancel reservation
If the reservation is DRAFT of a new reservation
Seat usages will be reset. The reservation lines will be deleted. The reservation will be set to CANCELLED.
If the reservation is CONFIRMED
The reservation will be set to DEPRECATED. A new version without any reservation lines will be created and set to CANCELLED. Seat usages will be reset.
If the reservation is DRAFT of a CONFIRMED reservation
The confirmed reservation will be set to DEPRECATED. The DRAFT reservation will be set to CANCELLED. All reservation lines in this reservation will be deleted. Seat usages will be reset.
Rebooking
Rebooking means that reservations in one seating offer are moved to another. This may be caused by modification of a seating offer that has led to the creation of a new version. Rebooking of a seat may lead to
- successful reservation with all properties satisfied
- partly successful reservation with important properties satisfied
- unsuccessful reservation
Sorting when rebooking
The reservations to rebook should be ordered so that the most difficult cases are handled first. This process is controlled by records in the table Sorting_Property.
Sorting criteria based on seating properties
This divides Netex properties into three groups that are compared separately.
Sorting criterion - Critical seating properties
A seating property is introduced in this group by records like
INSERT INTO sorting_property(sorting_key, sorting_value) VALUES('NuisanceFacility.NO_ANIMALS', 3);
The sorting value for this criterion is the number of matching properties in the reservation.
Sorting criterion - Important seating properties
A seating property is introduced in this group by records like
INSERT INTO sorting_property(sorting_key, sorting_value) VALUES('SeatPosition.UPPER_BERTH', 2);
The sorting value for this criterion is the number of matching properties in the reservation.
Sorting criterion - Less important seating properties
A seating property is introduced in this group by records like
INSERT INTO sorting_property(sorting_key, sorting_value) VALUES('SeatPosition.WINDOW', 1);
The sorting value for this criterion is the number of matching properties in the reservation.
Sorting criteria based on size of reservation
Sorting criterion - Number of travellers
Reservations with a large number of travellers may be handled early in the process. The minimum size for this criterion to be used is defined by this record:
INSERT INTO sorting_property(sorting_key, sorting_value) VALUES('Travellers.MIN_VALUE', 20);
This signifies that reservations with more than 20 travellers are handled early.
Sorting criterion - Number of compartments
Reservations with a large number of compartments may be handled early in the process. The minimum size for this criterion to be used is defined by this record:
INSERT INTO sorting_property(sorting_key, sorting_value) VALUES('Compartments.MIN_VALUE', 2);
This signifies that reservations with more than 2 compartments are handled early.
Defining the order of the sorting criteria
The order used when sorting is defined by records in Sorting_Property. Priorities are set from 0 to 4. 0 is the highest priority. If no priority is defined for a criterion, this criterion is ignored.
When two reservations are compared, the criteria with highest priority are compared. If they are unequal, the comparison is finished. If not, the criteria with second highest oriority are compared. If they are unequal, the comparison is finished. If not, the next criteria are compared. This continues until all priorities have been checked.
The criterion 'Number of travellers' is given priority 0 - highest:
INSERT INTO sorting_property(sorting_key, sorting_value) VALUES('Priority.TRAVELLERS', 0));
The criterion 'Number of compartments' is given priority 1:
INSERT INTO sorting_property(sorting_key, sorting_value) VALUES('Priority.COMPARTMENTS', 1));
The criterion 'Critical seating properties' is given priority 2:
INSERT INTO sorting_property(sorting_key, sorting_value) VALUES('Priority.CRITICAL_PROPERTIES', 2));
The criterion 'Important seating properties' is given priority 3:
INSERT INTO sorting_property(sorting_key, sorting_value) VALUES('Priority.IMPORTANT_PROPERTIES', 3));
The criterion 'Less important seating properties' is given priority 4 - lowest:
INSERT INTO sorting_property(sorting_key, sorting_value) VALUES('Priority.LESS_IMPORTANT_PROPERTIES', 4));
Authentication
The Seating manager requires a Bearer Token in the Authorization header created by the Entur Authentication server to be passed for every request.