Skip to content

Instantly share code, notes, and snippets.

@s9gf4ult

s9gf4ult/new flow.md

Last active September 22, 2017 09:54
Show Gist options
  • Save s9gf4ult/d33cb8255f86f859e4e6605d2cccce7d to your computer and use it in GitHub Desktop.
Save s9gf4ult/d33cb8255f86f859e4e6605d2cccce7d to your computer and use it in GitHub Desktop.
Download ZIP
Raw
new flow.md

1. Форма бронирования

На форму попадаем с поиска и предварительного бронирования. К моменту попадания на форму имеем сохраненный в базе офер и OfferId

1.1 Репрайс оффера

  • Пользователь меняет, или не меняет (тогда остается 0) extra markup

  • Жмет Add

    • Отправляется POST запрос на репрайс оффера п. 4.1 markup в запросе
    • Форма отображает обновленный прайсинг

  • Видит обновленный прайсинг на форме

  • В базе ни чего не сохраняется, Pnr не создается

1.2 Бронирование

  • Пользователь заполняет данные формы

  • Жмет book

  • Выполняется валидация запроса и всякие проверки

    • В случае ошибки
      • Возвращаем форму с ошибками
      • Ошибки показываются на форме бронировния
      • Возвращаемся к п. 1.2

  • Создается бронь в амадеусе получаем PNR

  • Делаем полноценный репрайс с полученным PNR

    • При ошибках
      • Мы еще не сохранили ордер в базе, а PNR уже получили

  • Создаем ордер в базе с обновленным прайсингом. Ордер помечается как "невидимый/временный" и еще не виден в админке, но все данные по нему уже есть в базе

  • Проверяем, изменилась ли цена agency net price после репрайса с PNR

1.2.1 Если цена не изменилась

  • Помечаем созданный в п. 1.2 ордер как "видимый"

  • Редиректим на форму выписки п.3 с пометкой "без проверки FXX"

1.2.2 Если цена изменилась

К этому моменту у нас есть OrderId от временного ордера со всеми данными и PNR

  • Сохраняем ошибку формы куда нибудь (в редис?) по паре (OrderId, PnrLocator)

  • Создаем задачу в таскере на отмену брони по таймауту п. 5.1

  • Редиректим пользователя на форму подтверждения п.2

2. Форма подтверждения бронирования

Форма подтверждения берет из урла OrderId и PnrLocator, которые закодированы в сегменте урла

host#confirm_booking/OrderId/PnrLocator

  • Пользователь переходит по урлу формы

  • Фронт достает из формы OrderId и PnrLocator

  • Фронт делает GET запрос на получение формы по ордеру п.4.3

    • Бэк берет ошибку бронирования из редиса (если есть) сохраненную в п. 1.2.2

  • Фронт отображает данные по оферу и пасажирам

2.1 Репрайс ордера на форме подтверждения

На форме подтверждения у нас уже есть ордер, следовательно мы можем делать полноценный репрайс ордера

  • Пользователь меняет agency extra markup

  • Жмет Add

  • Отправляется запрос на репрайс ордера п. 4.2

  • На форме обновляется прайсинг

2.2 Подтверждение бронирования

  • Пользователь проверяет прайсинг и соглашается с ним. Выбирает форму оплаты

  • Жмет Confirm

  • Отправляется запрос на подтверждение ордера п. 4.5

  • Делается полноценный репрайс ордера с запросом в CM

  • Проверяется, изменилась ли gency net price в сравнении с той, что показана пользователю

2.2.1 Цена не изменилась

  • Обновляем во временном ордере прайсинг

  • Делаем пометку в ордере чтобы он стал видимым в админке

  • Отменяем задачу на снос ордера п. 5.1 созданную в п. 1.2.2, либо надо придумать другой механизм защиты от автосноса брони

  • Редиректим пользователя на форму выписки п.3 с пометкой "без проверки FXX"

2.2.2 Цена изменилась

  • Возвращаем форму с обновленным прайсингом и фронт отображает его

  • Переходим к п.2.2

3. Форма выписки

host#ticketing/Checking/OrderId/PnrLocator

Где

  • Checking может принимать два значения:

    • no_check означает, что форма не должна проверять FXX и получать данные из запроса формы ордера п. 4.3

    • check_price форма должна получать данные из запроса формы ордера с проверкой FXX п. 4.4

  • OrderId - ид ордера

  • PnrLocator - pnr

  • Пользователь попадает на форму выписки

  • Фронт берет из урла параметры Checking, OrderId и PnrLocator и делает запрос на получение формы и отображает данные

3.1 Репрайс ордера

Полностью аналогично репрайсу ордера на форме подтверждения бронирования п. 2.1

3.2 Выписка

  • Пользователь заполняет форму и/или соглашается с прайсингом

  • Жмет ticket

  • Выполняется запрос на выписку п. 4.7

  • Делаются проверки лимитов и валидация запроса

  • Делаем полноценный репрайс с проверкой FXX

  • Проверяем что цена agency net price не отличается от показанной пользователю

3.2.1 Если цена не изменилась и все проверки прошли

  • Сохраняем в базе обновленный прайсинг некоторым образом (либо добавляем прайсинг к существующим продуктам, либо пересоздаем продукты, а старые переводим в другое состояние).

  • Списываются деньги с acquiring если надо, создаются платежки в базе

3.2.1.1 Если платежка прошла успешно

  • Добавляем ремарки и добавляем в очередь на выписку, добавляем форму оплаты в амадеусе

  • Запускаем задачу на загрузку билетов п. 5.2

  • Возвращаем пользователю APIItinerary

3.2.1.2 Если платежка не прошла

  • Мапим ошибки из эквайринга в человекочитаемые ошибки формы и возвращаем их

  • В базе ни чего не сохраняем

  • Пользователь видит ошибку оплаты на форме выписки

  • Переходим к п. 3.2

3.2.2 Цена изменилась

  • Формируем ответ с обновленной ценой

  • Фронт отображает обновленный прайсинг и ошибки

  • Переходим к п. 3.2

4. Запросы

4.1 Запрос на репрайс оффера

Выполняет упрощенный репрйас оффера без запроса в CM и калькулятор.

POST /api/v1/reprice/offer/OfferId

Где OfferId - ид оффера

Тело запроса:

{ "extra_markup": 10 }
  • extra_markup - agency extra markup в долларах

Тело ответа: booking offer с обновленным прайсингом

4.2 Запрос на репрайс ордера

Выполняет репрайс ордера.

POST /api/v1/reprice/order/OrderId/PnrLocator

Где OrderId и PnrLocator - ид ордера и pnr соответственно.

Тело запроса

{ "extra_markup": 10 }
  • extra_markup - agency extra markup в долларах

Тело ответа: booking offer с обновленным прайсингом

4.3 Запрос на получение формы по ордеру

Запрос нужен для получения формы подтверждения бронирования и формы тикетирования, если мы попали на нее сразу с формы бронирования. Запрос ни чего не меняет в базе и не делает запросов в амадеус, только возвращает данные ордера (оффер с прайсингом + пасажиры)

GET /api/v1/order/form/no_check/OrderId/PnrLocator

4.4 Запрос на получение формы с одновременной проверкой FXX

Запрос нужен для формы выписки когда мы попадаем на нее с админки. То же самое, что п.4.3, но выполняет проверку изменения цены в FXX, если цена изменилась делает новый прайсинг и возвращает его с ошибкой, поясняющей что цена изменилась. Новый прайсинг в базе не сохраняется, только показывается пользователю. Запрос в базе ни чего не меняет.

GET /api/v1/order/form/check_price/OrderId/PnrLocator

4.5 Подтверждение ордера

host/api/v1/confirm_booking/OrderId/PnrLocator

Запрос на подтверждение изменившейся после бронирования цены. Делается с формы подтверждения п. 2.2, работа запроса описана там же

4.6 Запрос на бронирование

4.7 Запрос на выписку

5 Задачи в таскере

5.1 Задача на снос не подтвержденной брони

При изменении цены на бронировании, когда пользователь не сгласился с ценой, но и бронь не отменил, а просто закрыл вкладку, у нас остается временный ордер с бронью, которую надо отменить.

Задача запускается на бронировании при изменении цены перед показом формы подтверждения.

Задача должна проверять, что ордер находится в состоянии "временный" и сносить бронь если это так. Плюс закрывать ордер.

И надо еще придумать механизм, который не позволит задаче сносить бронь в случае, если пользователь играется с ценой, или вошел в цикл изменения цены (когда цена постоянно меняется, пользователь тупит, потом соглашается, а цена снова меняется). Или не придумывать и тупо сносить по таймауту если ордер не подтвержден в течении X минут.

5.2 Задача на загрузку билетов

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment