100% онлайн-авиапроездной або Як приборкати систему бронювання

Подорож між Петербургом і Москвою за останні роки події перетворилося в рутинну завдання. Хтось щотижня мотається з Пітера до Москви або навпаки на роботу, з роботи. У кого-то там дівчина, батьки, друзі… Переліт на літаку займає трохи більше години. Між двома столицями в день літають понад 40 рейсів.

Та й не тільки Москва і Пітер генерують постійний трафік. З'являються і інші економічні і культурні центри. В Казань літає понад 10 рейсів на день. У Краснодар – більше 20.

Слідом за зміною поведінки людей, змінюється і така консервативна область, як авіація. Гнучкі тарифи, квитки з відкритою датою, а тепер і проїзні квитки.

Сьогодні розповімо, як реалізували онлайн-покупку, оформлення і зміна квитків в рамках авиапроездного або multipass. І дали активно подорожують можливість курсувати між містами максимально легко. Якщо вам цікаві технічні аспекти приборкання систем бронювання, або ви один з мандрівників – наша стаття для вас.

Сам по собі авиапроездной штука не нова. У Росії вони почали з'являтися кілька років тому, і тепер функціонують у ряду авіакомпаній. Схема їх оформлення та користування була загальна – оформи проїзний в касі або залиш заявку на сайті, а кожен політ вибирай і підтверджую через колл-центр.

Хто сьогодні піде купувати квиток у касі? Хто сьогодні полюбляє дзвонити в колл-центр? Онлайн-агентства приходять на зміну квиткових кас. Функціонал сайтів замінює собою колл-центри.
Люди хочуть сервіс, доступний в будь-який момент, без необхідності куди-то йти чи телефонувати, просто натиснувши кнопку на смартфоні.

1. Проїзний – це абонемент
Авиапроездной в наших реаліях – це все-таки абонемент. Ти купуєш тариф на певне число перельотів туди-назад по вибраному маршруту. Влаштовано це як бронь на кілька перельотів з відкритою датою вильоту. Діє він протягом обмеженого терміну. Але дати польотів у межах цього строку і рейси можна вибирати будь-які. І міняти як завгодно багато разів. Безкоштовно.

Так воно працює в Росії.

авіа альянсів і деяких окремих авіакомпаній існують і інші схеми. Якщо коротко, то вони поділяються на 2 види:
Але це зовсім інша історія. Повернемося ж до наших реалій.


2. Офлайновий офлайн або Як воно було раніше
2.1. Оформляємо проїзний в касі
  1. Прийти в касу і сказати, що потрібний проїзний. Повідомити, коли перший політ.
  2. Касир підбере і забронює рейс.
  3. Оформить проїзний.
  4. Випише перший квиток.
  5. Візьме гроші за весь проїзний.
В принципі все просто. Тільки займе хвилин 30… Вам будуть розповідати вголос всі розклад на кожну дату по кожному квитку. Потім оформляти бронювання через GreenScreen – інструмент доступу до системи бронювання, який працює з текстовим запитам. Потім виписувати квиток…

Але це ще квіточки! Це ж абонемент. Польотів за нього покладається кілька. Тут і починається найцікавіше.

2.2. Вносимо зміни в план польотів
Внести дані про нових польотів або змінити дату тих, що вже оформлені можуть тільки супер-просунуті фахівці авіакомпанії. Знайти їх можна в двох місцях:
  • у представництві авіакомпанії в аеропорту
  • в колл-центрі авіакомпанії.
Процедура внесення змін до бронювання значно більш складна, ніж оформлення.
  • Зміна даних першого польоту в деяких випадках можна зробити тільки через анулювання старої броні і оформлення нової.
  • Зміна дати одного з наступних польотів оформляється через процедуру ревалідацію. Це зміна даних у квитку без зміни самого квитка, і тільки звучить легко.
  • І, нарешті, сама «солодка» частина. За правилами системи бронювання бронь йде в архів (стає неактивною, по суті анулюється) через 3 дні після того, як пасажир здійснив останній із запланованих перельотів. Тобто якщо ви оформили проїзний і виписали тільки один квиток, злітали з нього, а другий протягом трьох днів не виписали, вся ваша бронь з усіма невикористаними сегментами в системі йде в архів. Пара-пара-пам '…
    Природно, ця проблема теж вирішувана шляхом введення цілого пулу правильних текстових запитів, але сама болісна.


Ось так виглядає екран системи Green Screen у фахівця авіакомпанії:


В сухому залишку. Кожен раз при оновленні проїзного треба здаватися в касу, що явно довго і незручно. Поліпшити показники продукту можна, зробивши продаж на сайті, і тільки зміна через колл-центр. Вийде трохи швидше, але все ще не 21 століття.

3. А можна 100% онлайн?
Наше рішення «Діловий проїзний» як раз таке. Всі операції з оформлення та оплату проїзного, вибору квитків, зміни рейсів виробляються онлайн через наш сервіс.

3.1. Проектуємо UI
Почали, як і годиться, з проектування UI. Завдання складалася з наступних складових (вимог):

А) Ми робимо веб-сервіс для клієнтів авіакомпанії, і він повинен повністю відповідати стилістиці веб-сервісів компанії. Це само собою зрозуміле.

Б) Якщо ми реалізуємо онлайн-продаж проїзних, ми повинні створити точно такий-же користувальницький досвід, як і при покупці квитка.

Екран вибору рейсу на сайті авіакомпанії виглядає так:


Екран вибору рейсів в рамках проїзного ось так:


В) При цьому нам потрібно, щоб користувач точно розумів, що це не квиток – це проїзний. Для цього передбачено цілий ряд інструментів:
  • На формі вибору рейсів відразу вказані всі передбачені тарифом перельоти.
  • На сторінці підтвердження оплати ми пропонуємо оформити такі перельоти, якщо клієнт вже готовий.
Ця ж інформація – посилання на кабінет клієнта «Ділового проїзного» відображається email підтвердження оформлення проїзного і кожного нового квитка за нього.


  • І, нарешті, можна просто зайти в особистий кабінет на сайті «Ділового проїзного» і додати новий переліт.


Г) Мобільна версія генерує 30% трафіку. Відразу проектуємо якісне відображення на мобільних платформах.

спочатку Ми виходили з припущення, що наш клієнт – дуже мобільний. І у нас вже є реальні приклади, як за 20 хвилин до вильоту одного з рейсів клієнт успішно оформляє наступний.

3.2. Технічна сторона вирішення
Як ми підмінили тривалий сеанс роботи фахівця з бронювання блискавичними онлайн-операціями?

Наше рішення побудоване на трьох технологіях:
  • Серверна частина – Java (API на основі фреймворку Spring Boot).
    Більшу частину логіки роботи з системою бронювання, ми реалізували в бізнес-логікою нашого бекенду. Всі досить складні операції в SWS по бронюванню, розрахунку вартості і тикетированию ми виконуємо всередині серверної частини програми надаючи клієнту спрощений інтерфейс. Всі клієнтські запити стали досить прості. Наприклад, на сторінці редагування проїзного є тільки кнопка «Зберегти», а на сервері відбуваються такі операції як: запит броні з системи бронювання, зміни маршрутної інформації (в деяких випадках доводиться робити нову броню і анулювати поточну), ревалидация квитка (через побудову складних текстових запитів) формування нової маршрутної квитанції у форматі PDF (про це трохи пізніше) і надсилання інформаційного листа пасажиру.
  • База даних – Mongo DB (з підтримкою версійності через використання бібліотеки Javers)
    Вирішили використовувати цю NoSQL базу даних, так як ніяких переваг реляційної бази ми не планували використовувати. Але в зв'язку з тим, що еволюціонують і наш додаток, і реалізація сервісів системи бронювання, нам простіше і зручніше використовувати варіативність записів у MongoDB. Крім того, ми зберігаємо інформацію про бронювання і квитках, а також про стан оплати кожного квитка. А це дуже добре лягає на документи в MongoDB.
    Для того, щоб відстежувати зміни про квитки, ми використовуємо бібліотеку Javers, яка надає можливість версионирования сутностей, що зберігаються в MongoDB.
  • Frontend – наш власний SPA Framework. Ми про нього вже писали ось тут: habrahabr.ru/company/eastbanctech/blog/244745
  • Генерація маршрутної квитанції у форматі PDF
    Тут ми з недавнього часу використовуємо інструмент wkhtmltopdf. Зробили шаблони на Freemarker, збагачуємо ці шаблони даними із системи бронювання. В результаті формується HTML-документ, який ми потім обробляємо за допомогою wkhtmltopdf.
    Спочатку ми користувалися JasperReports. Але прийшли до того, що внесення навіть незначних змін в його шаблони займає дуже багато часу. А зробити PDF з точним (pixel perfect) розташуванням елементів в нас так і не вийшло. Тому ми проаналізували поточні рішення і вибрали wkhtmltopdf. Тепер зміни квитанції ми можемо робити досить швидко, так як HTML – досить простий формат.
  • Логування
    Для такої складної системи знадобилося реалізувати систему логування, за допомогою якої можна в будь-який момент зрозуміти, що відбувалося під час оформлення проїзного у будь-якого користувача. Для цього ми використовували інтерфейс slf4j з реалізацією через logback (з logstash апендером ). До файлів і логів, які формуються додатком, ми підключили Filebeat, який відправляє логи в Logstash. У Logstash проводиться конвертація повідомлень, і логи йдуть на індексацію Elasticsearch. Після цього ми їх дивимося і аналізуємо в Kibana. Таку зв'язку ми використовуємо теж на декількох проектах, і вона нам дуже добре допомагає.


3.2.1. Як ми перемагали систему бронювання
У системи бронювання Gabriel, яку використовує наш замовник, є веб-шлюз SWS (Sita Web Services). Ми, звичайно, працювали саме з ним.

В результаті, з точки зору механіки системи бронювання ключові моменти нашого рішення виглядають так:
  • Ревалидация при зміні польотних даних
    Для зміни дати/часу перельоту (та номера рейсу відповідно) треба внести зміни в бронь. Для цього в SitaWS є спеціальний сервіс, і здавалося б операція досить проста, але в деяких випадках треба створювати нову броню, так як поточна вже пішла в архів (пам'ятаєте, вона туди падає, як тільки проходить 3 дні після здійснення всіх запланованих перельотів). Після внесення інформації до бронювання треба оновити інформацію у квитку. І це доводиться робити через текстові команди (емуляція Green Screen).
  • Зміна дати першого польоту (зміна броні)
    Якщо пасажир виписав собі проїзний, вказавши тільки перший рейс (інші сегменти перельоту залишаються з відкритою датою), а потім хоче поміняти дату, то при зміні цього рейсу в бронюванні через SWS, сервіс SWS видаляє старий сегмент і додає новий сегмент і з якоїсь причини ставить перший сегмент (який ми змінюємо) самим останнім. І після цієї операції в броні спочатку йдуть сегменти з відкритою датою, а потім наш вибраний сегмент. Це не відповідає технології. Тому нам доводиться анулювати поточну бронь і формувати нову.
  • Оборотність «шатдауна» бронювання
    Наприклад, пасажир літає за певним графіком одним і тим же рейсом раз в тиждень. Все запланував, квитки виписав, але плани змінилися і на третьому тижні в понеділок він полетіти не зможе і хоче полетіти у вівторок. При спробі змінити цей рейс, нам треба видалити старий сегмент і додати новий. При виконанні цієї операції SWS видаляє з броні всі сегменти з таким же номером. Після цієї операції ламається послідовність рейсів і бронь стає невалидной. Але ми навчилися обходити таку поведінку SWS і після зміни – всі рейси зберігаються і зберігається послідовність рейсів. І бронь, квиток залишаються валідними.


3.2.2. Як умістили всю функціональність в SPA
На даний момент реалізація клієнт-серверних веб-додатків через API і SPA є, можна сказати, трендом і де-факто стандартом. Тому додаток для «Ділового проїзного» ми вирішили робити з використанням цих технологій. Для реалізації SPA ми взяли свій фреймворк, який зроблений на основі KnockoutJS/Durandal. На ньому ми реалізували досить багато рішень, у тому числі кілька дуже складних.

Для користувача є кілька точок входу, з яких він, рухаючись через етапи візарда, досягає своєї мети – оформлення проїзного.

p.s.
На завершення історії хочемо сказати ось що:
Ми не лукавимо і не приховуємо, що свій фреймворк створили не вчора. І тонкощі роботи з системою бронювання занурюємося вже далеко не перший раз. Ми швидше звідти і не вилазимо :-). Але цей проект став черговим викликом. Ми робили з системою бронювання таке, чого не робили раніше ні ми, ні, схоже, інші. Сподіваємося, що і вам було цікаво.

І, до речі, реліз проекту – це зовсім не кінець історії. Півтори тижні тому вийшло аналогічне рішення для абонементів на переліт в бізнес-класі «Бізнес-проїзний». А найближчим часом побачить світ API для підключення до даної послуги онлайн тревел-агентств.

Тепер, знаючи, як це все працює зсередини, сподіваємося, вам буде цікаво подивитися, як це все виглядає і працює зовні. Не так часто ми можемо дати вам потикати і спробувати самим. Сьогодні один з рідкісних днів. multipass.s7.ru – заходьте в гості. А може комусь потрібний проїзний?
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.