近年のサンクトペテルブルクとモスクワ間の旅は、イベントから日常業務に変わりました。 サンクトペテルブルクからモスクワへ、またはその逆に、仕事のため、仕事のために毎週傷を負った人がいます。 誰かが女の子、両親、友人がいる...飛行機での飛行には1時間以上かかります。 2つの首都の間では、毎日40便以上の便が運航しています。



そして、モスクワとサンクトペテルブルクだけが絶え間ないトラフィックを生み出しています。 他の経済および文化の中心地が出現しています。 1日10便以上がカザンに飛ぶ。 クラスノダール-20以上。



人間の行動の変化に続いて、航空などの保守的な領域も変化しています。 柔軟な運賃、オープン日付のチケット、および現在の旅行チケット。







本日は、航空旅行またはマルチパスの一環として、オンラインでの購入、登録、チケットの変更をどのように実装したかを説明します。 そして、彼らはアクティブな旅行者に、できるだけ簡単に都市間を行き来する機会を与えました。 テイミング予約システムの技術的な側面に興味がある場合、または旅行者の1人である場合は、私たちの記事が役立ちます。



空の旅そのものは新しいものではありません。 彼らは数年前にロシアに現れ始め、現在多くの航空会社で運営されています。 それらの登録と使用のスキームは一般的でした-チケットオフィスでチケットを発行するか、ウェブサイトにリクエストを残し、コールセンターを通じて各フライトを選択して確認します。



今日、誰がチケット売り場でチケットを購入しますか？ 今日、誰がコールセンターに電話するのが好きですか？ オンライン代理店がチケットオフィスを置き換えています。 コールセンターに代わるWebサイト機能。

人々は、スマートフォンのボタンを押すだけで、どこへ行っても電話をかけなくても、いつでも利用できるサービスを求めています。

1.旅行カードは定期購入です

私たちの現実の空の旅はまだ購読です。 選択したルートで一定数の往復フライトの運賃を購入します。 これは、出発日が開いている複数のフライトの予約として手配されます。 期間限定です。 ただし、この期間内のフライトとフライトの日付は、任意に選択できます。 そして何度でも変更できます。 無料で。



したがって、ロシアで機能します。



航空会社アライアンスおよびいくつかの個々の航空会社には他のスキームがあります。 要するに、それらは2つのタイプに分けられます：

• 特定の時間内のある国または大陸でのフライトの数に制限はありません（ 例 ）
• または一般的なスペース-無制限の生涯フライト（ 例 ）

しかし、これはまったく異なる話です。 現実に戻りましょう。

2.オフラインオフラインまたは以前のように

2.1。 チケット売り場でチケットを発行します

1. レジに来て、旅行カードが必要だと言います。 最初のフライト時に報告します。
2. レジ係がフライトを受け取り、予約します。
3. 旅行カードを発行します。
4. 最初のチケットを発行します。
5. 旅行カード全体のお金を受け入れます。

原則として、すべてがシンプルです。 所要時間はわずか30分です。各チケットの日付ごとにスケジュール全体が音声で通知されます。 次に、GreenScreenを介して予約を行います。これは、テキスト要求で機能する予約システムへのアクセスツールです。 次に、チケットを書きます...



しかし、これらはまだ花です！ これはサブスクリプションです。 いくつかの便があります。 ここから楽しみが始まります。

2.2。 フライトプランの変更

新しいフライトのデータを入力したり、すでに発行されているフライトの日付を変更したりできるのは、非常に高度な航空会社の専門家だけです。 それらは2つの場所で見つけることができます。

• 空港の航空会社駐在員事務所で
• 航空会社のコールセンターで。

予約を変更する手順は、設計よりもはるかに複雑です。

• 場合によっては、最初のフライトのデータを変更するには、古い予約をキャンセルして新しい予約を発行する必要があります。
  
  
  
  
• 後続のフライトのいずれかの日付の変更は、再検証手順によって行われます。 チケット自体を変更せずにチケットのデータを変更すると、簡単に聞こえます。
  
  
  
  
• そして最後に、「最も甘い」部分。 予約システムのルールに従って、予約は、乗客が最後の計画飛行を行った3日後にアーカイブされます（非アクティブになり、基本的にキャンセルされます）。 つまり、チケットを発行し、チケットを1つだけ発行し、そのチケットを飛ばし、3日以内に2つ目のチケットが発行されなかった場合、システム内のすべての未使用セグメントのすべての予約がアーカイブされます。 パラパラメモリ...
  
  
  
  当然、この問題は、正しいテキストクエリのプール全体を導入することで解決されますが、これは最も苦痛です。

航空会社の専門家によるグリーンスクリーンシステムの画面を次に示します。







乾燥残留物中。 旅行カードをアップグレードするたびに、チケットオフィスでatめなければなりません。これは明らかに長く不便です。 サイトで販売することで製品のパフォーマンスを向上させることができ、コールセンターを通じてのみ変更できます。 それは少し速くなりますが、それでも21世紀ではありません。

3. 100％オンラインにすることは可能ですか？

私たちが決定した「出張」はまさにそれです。 チケットの発行と支払い、チケットの選択、フライトの変更に関するすべての操作は、当社のサービスを通じてオンラインで実行されます。

3.1。 UIの設計

予想どおり、UIの設計から始めました。 このタスクは、次のコンポーネント（要件）で構成されていました。



A）航空会社の顧客向けにWebサービスを作成し、会社のWebサービスのスタイルに完全に準拠する必要があります。 これは当たり前です。



B）チケットをオンラインで販売する場合、チケットを購入するときとまったく同じユーザーエクスペリエンスを作成する必要があります。



航空会社のウェブサイトのフライト選択画面は次のようになります。





このような旅行カード内のフライトを選択するための画面：





C）この場合、ユーザーはこれがチケットではないことを明確に理解する必要があります-これはチケットです。 これを行うために、いくつかのツールが提供されています。

• フライト選択フォームには、運賃で規定されているすべてのフライトがすぐに表示されます。
• 支払い確認ページでは、クライアントの準備が整っている場合、次のフライトを発行することを提案しています。

同じ情報-「出張カード」のクライアントのオフィスへのリンクは、旅行カードの登録とその新しいチケットの確認メールに表示されます。

• そして最後に、Business Travel Webサイトの個人アカウントに移動して、新しいフライトを追加できます。

D）モバイル版はトラフィックの30％を生成します。 モバイルプラットフォームですぐに高品質のディスプレイを設計します。



最初は、クライアントが非常にモバイルであるという前提から進めました。 そして、フライトの出発の20分前に、クライアントが次のフライトを作成する方法の実例がすでにあります。

3.2。 ソリューションの技術面

長期の予約スペシャリストを超高速オンラインオペレーションにどのように置き換えましたか？



当社のソリューションは、5つのテクノロジーに基づいています。

• サーバー部分はJava（Spring Bootフレームワークに基づくAPI）です。 バックエンドのビジネスロジックで予約システムを操作するためのロジックのほとんどを実装しました。 SWSでは、アプリケーションのサーバー部分の内部での予約、原価計算、発券に関するかなり複雑な操作をすべて実行し、クライアントに簡素化されたインターフェイスを提供します。 すべてのクライアント要求は非常に単純になりました。 たとえば、旅行カードの編集ページには「保存」ボタンのみがあり、次のような操作があります。予約システムから予約をリクエストする、ルート情報を変更する（場合によっては新しい予約を作成して現在の予約をキャンセルする）、チケットを再検証する（複合ビルを構築する）テキストクエリ）、新しい旅程の領収書をPDF形式で生成し（詳細は後ほど説明します）、情報レターを乗客に送信します。
  
  
  
  
• データベースはMongo DBです（Javersライブラリを使用したバージョン管理のサポートがあります）。 リレーショナルデータベースの利点を使用する予定はなかったため、このNoSQLデータベースを使用することにしました。 しかし、アプリケーションと予約システムサービスの実装の両方が進化しているという事実により、MongoDBのレコードの多様性を使用する方が簡単で便利です。 さらに、予約とチケットに関する情報、および各チケットの支払いステータスを保存します。 そして、これはMongoDBのドキュメントに非常によく適合します。
  
  
  
  チケットに関する変更を追跡するために、MongoDBに保存されているエンティティをバージョン管理する機能を提供するJaversライブラリを使用します。
  
  
  
  
• フロントエンドは、独自のSPAフレームワークです。 ここで彼についてすでに書いた 。
  
  
  
  
• PDF形式のルート領収書の生成。 ここでは、最近wkhtmltopdfツールを使用しました。 Freemarkerでテンプレートを作成し、これらのテンプレートを予約システムからのデータで強化します。 その結果、HTMLドキュメントが生成され、wkhtmltopdfを使用して処理されます。
  
  
  
  最初にJasperReportsを使用しました。 しかし、テンプレートに少しでも変更を加えるには非常に長い時間がかかるという結論に達しました。 そして、要素の正確な（ピクセル完璧な）配置でPDFを作成することはできませんでした。 したがって、現在のソリューションを分析し、wkhtmltopdfを選択しました。 HTMLは非常に単純な形式であるため、領収書をすぐに変更できます。
  
  
  
  
• ロギング このような複雑なシステムでは、ロギングシステムを実装する必要がありました。これにより、ユーザーの旅行カードの登録中に何が起こっていたかをいつでも理解できます。 このために、logfash jenderを使用したlogback経由の実装でslf4jインターフェイスを使用しました。 アプリケーションによって形成されたログファイルにFilebeatを接続し、ログをLogstashに送信しました。 Logstashはメッセージを変換し、ログはElasticsearchのインデックス作成に使用されます。 その後、Kibanaでそれらを見て分析します。 また、この束をいくつかのプロジェクトで使用しており、非常に役立ちます。

3.2.1。 予約システムを獲得した方法

お客様が使用するGabriel予約システムには、SWS Webゲートウェイ（Sita Web Services）があります。 もちろん、彼と一緒に働きました。



その結果、予約システムの仕組みの観点から、ソリューションのキーポイントは次のようになります。

• フライトデータの変更時の再検証。 フライトの日付/時刻（およびフライト番号）を変更するには、予約を変更する必要があります。 このため、SitaWSには特別なサービスがあり、操作は非常に簡単に思えますが、現在の予約は既にアーカイブされているため、新しい予約を作成する必要がある場合があります（すべてのスケジュールされたフライトの完了後3日が経過するとすぐにそこに落ちます）。 予約情報を入力した後、チケットの情報を更新する必要があります。 そして、これはテキストコマンド（グリーンスクリーンエミュレーション）を介して実行する必要があります。
  
  
  
  
• 最初の飛行の日付を変更します（鎧の変更）。 乗客が自分のパスを書き、最初のフライトのみを示し（残りのフライトセグメントは営業日のまま）、その後日付を変更したい場合、SWSを介して予約でこのフライトを変更すると、SWSサービスは古いセグメントを削除し、一部の新しいセグメントを追加しますreasonは最初のセグメント（変更するセグメント）を最後に配置します。 そして、この操作の後、オープン日付のセグメントが最初に予約に移動し、次に選択したセグメントに移動します。 これは技術と一致していません。 したがって、現在の予約をキャンセルして、新しい予約を作成する必要があります。
  
  
  
  
• コンバーチブルシャットダウン予約
  
  たとえば、乗客は週に1回、同じフライトで特定のスケジュールで飛行します。 彼はすべてを計画し、チケットを発行しましたが、計画は変更され、月曜日の第3週には飛行できなくなり、火曜日に飛行したいと考えています。 このフライトを変更する場合、古いセグメントを削除して新しいセグメントを追加する必要があります。 この操作を実行すると、SWSは同じ番号を持つすべてのセグメントを予約から削除します。 この操作の後、フライトシーケンスが中断し、予約が無効になります。 ただし、変更後もこのSWSの動作を回避することを学びました。すべてのフライトが保存され、フライトのシーケンスが保持されます。 予約とチケットの両方が有効のままです。
  
  

3.2.2。 SPAのすべての機能を適合させる方法

現時点では、APIとSPAを介したクライアント/サーバーWebアプリケーションの実装は、トレンドと事実上の標準です。 そのため、これらのテクノロジーを使用して出張用のアプリケーションを作成することにしました。 SPAを実装するために、KnockoutJS / Durandalに基づいたフレームワークを使用しました。 いくつかの非常に複雑なものを含む、かなりの数のソリューションを実装しました。



ユーザーにはいくつかのエントリポイントがあり、そこからウィザードのステージを移動して、目標を達成します-旅行カードを発行します。

PS

話の終わりに、これを言いたいです。

私たちは、昨日フレームワークを作成しなかったという事実を解体せず、隠しません。 また、予約システムでの作業が複雑になると、私たちは初めてとはほど遠い状態になります。 そこから抜け出す可能性が高くなります。 しかし、このプロジェクトは別の課題でした。 私たちは、予約システムを使って、私たちも他の人も以前にやったことがないようなことをしました。 あなたが興味を持っていたと思います。



ところで、プロジェクトのリリースは話の終わりではありません。 1週間半前、同様のソリューションがビジネスクラスのフライトパスに対して発行されました-「出張」。 そして近い将来、オンライン旅行代理店をこのサービスに接続するためのAPIがリリースされます。



これで、すべてが内側からどのように機能するかがわかったので、外側からすべてがどのように見え、どのように機能するかを確認してください。 あまり頻繁ではありませんが、私たちはあなたに突っ込み、自分で試してみることができます。 今日はめったにない日です。 multipass.s7.ru-訪問してください。 それとも誰かが旅行カードを必要としますか？