100% Online Air Multi Pass or How to Harness Booking system

Travelling between St. Petersburg and Moscow has become a routine trip, not a big event anymore. Some people go back and forth from St. Petersburg to Moscow or vice versa, to work or from work to home. Or to visit girlfriend/boyfriend/parents/friends … It takes just an hour to fly between the two our capitals, and there are more than 40 flights a day.

And such permanent air traffic is common not only for Moscow and St. Petersburg. There are other economic and cultural centers appearing in our huge country. For example, there are over 10 flights a day to Kazan, and more than 20 to Krasnodar.

After changes in people behavior, such rigid area as aviation also changes — more flexible rates, open tickets, and now travel passes.

Today we will tell how we implemented online purchase, registration and ticket change in the frame of an airline travel pass, or ‘Multi pass’ — and how we gave a chance to most active travelers to fly between the cities easily. If technical aspects of managing booking systems are in the area of your interest or you are a desperate traveler — welcome to join us.

An air travel pass itself is not an innovation. They appeared in Russia a few years ago, and now are used at number of airline companies. The scheme of their registration and use was common — issuing the pass in the ticket office or requesting it on the website, choosing and confirming each flight via call center.

But who buys air tickets in booking offices today? Who enjoys calling customer support service nowadays? Online agencies appear instead of ticket offices. The functionality of the websites replaces the same of the call centers.

People want the service to be available any time with no need in going or calling somewhere, but with clicking just one button on their smartphones.

1. Travel pass is a subscription

A travel pass in Russia is subscription. You buy a certain number of roundtrip flights for the selected route. It works as booking of several flights with open departure date. It is valid during limited period. But it is possible to choose any flight dates and times within this period, changing them as many times as possible, free of charge.

So this is how it works in Russia.

The airline alliances and some separate airline companies have other schemes. In short, they are divided into 2 types: unlimited number of flights over the country or continent, no time limits (for example), or a dream — lifelong unlimited flights (find more detail here). But it is a different story.

Let’s return to our reality.

2. Total Offline or How it was before

2.1. Buying a pass at ticket office:

· You come to a ticket office and tell that you need travel pass. Tell date/time of the first flight.

· Ticket agent selects a flight and books it.

· A travel pass is issued.

· Agent issues the first ticket of the pass.

· Agent takes money in for the whole pass totally.

In general, everything is simple. The only thing — it takes at least 30 minutes… You have to listen to the schedule for each ticket and date. Then agent uses GreenScreen to book your flights — the instrument to access booking system which works through textual requests. Finally, the ticket is issued…

But it is still flowers! As you remember, we are talking about subscription. And it is supposed to have several flights assigned. From here it is getting stranger.

2.2. Changing the flight plan

To enter data on new flights or change date of those that are already issued — these are the tasks for the true super-advanced ticket agents. It is possible to find them in two places:

· in the airline representative office at the airport

· in the airline Customer Support call center.

Procedure of making changes in the booking is usually much more difficult than its initial registration.

· Changes in data of the first flight in certain cases can be made only through the cancellation of the initial booking and registering a new one.

· Changes in date of one of the subsequent flights are made through the revalidation procedure. It means the change of data in ticket without changing the ticket itself, and it only sounds easy.

· And the “sweetest” part. By rules of the booking system the booking is archived (becomes inactive, cancelled) in 3 days after a passenger made the last planned flight. So if you issued the travel pass and got only one ticket, took this flight, and didn’t issue the next ticket within three days — your entire booking with all unused segments in it is archived in the system. Ooops…

Of course, this issue can be solved by a whole bunch of textual requests, but it is the most painful one.

Here is the screen of the GreenScreen system from the airline agent side:

So this is what we have. Whenever user wants to update travel pass, he/she has to go to the ticket office, which takes much time and not convenient at all. It is possible to improve this product by selling travel pass from the website and allowing changes through the call center. Still it is not the 21st century, even though it is slightly quicker.

3. Going 100% online — truth or myth?

Our solution “Multi Pass” is just like that. All operations — registering, payment, ticket choice, changes in flights — are made online via our service.

3.1. Designing UI

As usual, we started from UI design. The task had the following requirements:

A) We implement a web service for the airline customers, so it has to have the same visual style as other web services of the company. And it is obvious.

B) If we implement online sale of multi passes, we have to follow precisely the same user experience, as the one existing for ticket purchase.

The screen of flight choice on the airline website:

The screen of flight choice for multi pass:

C) At the same time, user should understand that it is a multi pass, not a regular ticket. For this purpose there are some tools provided:

· On the flight choice page there are all flights for this fare.

· On the payment confirmation page we suggest to issue the coming flights if user is ready to do so.

The same information containing the link to the personal account of “Multi Pass” user is displayed in confirmation emails of issuing the Pass and each new ticket within it.

· Finally, it is possible just to go to the personal account on the “Multi Pass” website to add a new flight.

D) The mobile version generates 30% of traffic. We plan for high-quality rendering on mobile platforms.

We initially assumed our typical user is quite mobile. And we already have real examples of those guys who issue the next flight ticket 20 minutes before the current departure.

3.2. Technical aspect of the solution

How did we manage to substitute a long-session work of an agent in the ticket office for flash-like online operations?

Our solution is based upon five technologies:

Server part — Java (API on the basis of Spring Boot framework). We implemented the essential part of logic of working with the booking system in the business logic of our backend. We run all complicated operations in SWS for booking, price calculation, and ticketing in the server part of the application providing users with the simple interface. All client requests were made real simple. For example, on the Edit Multi Pass page there is only Save button for users, which initiates many operations on the server: requesting the booking from the booking system, changes of route information (in certain cases it is necessary to do a new booking cancelling the current one), ticket revalidation (through creation of complicated text requests), formation of the new itinerary receipt in the PDF format (later we talk about it) and sending the confirmation to the passenger.

Database — Mongo DB (with support of the version control through the use of Javers library). We decided to use this NoSQL database, as we did not plan to use any benefits of relational DB. But because both our app and booking system web services improve, it is simpler and more convenient for us to use variability of the MongoDB records. Besides, we store information on booking and tickets, and payment statuses of every ticket. And this suits the documents in MongoDB well.

To monitor ticket changes, we use Javers library providing versioning of the entities stored in MongoDB.

Frontend — our own SPA Framework. We already wrote about it here (Russian).

Itinerary receipt generation in PDF. Here we’ve been using the wkhtmltopdf tool. We made templates on Freemarker, and we add the data from the booking system into these templates. As a result, we get HTML document, which we process with the help of wkhtmltopdf.

In the beginning we used JasperReports. But it was completely rigid and time-wasting even with small changes in the templates. And we did not achieve pixel perfect PDF. Therefore, we analyzed the existing solutions and chose wkhtmltopdf. Now we can change the receipts quickly enough owing to simplicity of HTML format.

Logging. Such complex system requires implementing logging system which will help to understand what in particular happens during the multi pass issuing for any user. For this purpose we used the slf4j interface with the implementation through logback (with logstash appender). We connected Filebeat, which sends logs to Logstash, to the app log files. In Logstash the messages are converted, and logs are sent to Elasticsearch for indexation. After that, we read them and analyze in Kibana. We use such bundle on several projects too, and it always helps us.

3.2.1. How we fought booking system

Gabriel booking system, used by our customer, has SWS gateway (Sita Web Services). We worked with it, of course.

Thus, these are the key moments of our solution regarding the booking system mechanics:

· Revalidation when changing flight data. To change flight date/time (and flight number, accordingly) it is necessary to change the booking. For this purpose, there is a special service in SitaWS, it may seem quite simple, but in certain cases it is necessary to create a new booking as the current one has been archived (you remember, it happens in 3 days after all planned flights are taken). After entering information into booking, it is necessary to update ticket as well. And it should be done through the text commands (Green Screen emulation).

· Change of the first flight date (change of the booking). If passenger gets multi pass with only the first flight specified (other flight segments are left with open date) and then wants to change date, during this flight change in booking through SWS, the SWS service deletes the old segment adding a new one and, for some reason, makes the first segment (that is changed) as the last one. So after the operation is done, segments with open date go first in the booking, and our chosen segment goes next. It does not go with the technology. Therefore, we should cancel the current booking and create new.

· Reciprocity of booking “shutdown”

For example, the passenger has a regular schedule and takes the same flights every week. Everything is planned, the tickets are issued, but then plans suddenly change and on the third Monday he cannot go and wants to replace the departure on Tuesday. Trying to change this flight we should remove an old segment and add new. While processing this operation, SWS deletes all segments with the same flight number from the booking. After this operation the sequence of flights breaks and the booking becomes invalid. But we learned to manage such SWS behavior, so all flights and their sequence are preserved after the changes done. Both the booking and the ticket stay valid.

3.2.2. How we put all functionality into SPA

At the moment, implementation of client-server web applications through API and SPA is a trend and, in fact, a standard. Therefore, we decided to do the app for “Multi Pass” using these technologies. To implement SPA, we took our framework based on KnockoutJS/Durandal, on which we implemented numerous solutions including several complicated one.

There are several points of access moving from which with the help of wizard user achieves the main goal — multi pass issuing.

P.S.

In end we want to tell that:

We do not hide that our framework is quite old. And it is not the first time we dive into the nuances of booking system work. We are there every time. Nevertheless, this project was a real challenge. We did something new with the booking system, something never experienced before. And we hope it was interesting to you.

And, by the way, the release of the project is not the end of the story. We launched a similar solution for multi pass for flights by business class one and a half weeks ago — “Business Multi Pass”. And in the nearest future the API for signing online travel agencies to this service will be introduced.

Now knowing about how it works inside, we hope you will be interested to see how all this looks and works for users. It is not really often when we can give you to try the solution yourself. Today is one of these rare days. multipass.s7.ru. Does anybody need a travel pass?

Find more enterprise cases at eastbanctech.ru