航空券の予約システムのバックエンド開発および 予約の管理サイトの開発

設計・実装

サーバーは Node.js の fastify.js フレームワークを用いて作成しました。 クライアントとサーバーの処理フローはおおむね以下のようになります。

• クライアントは JSON パラメータとともに HTTP リクエストをサーバーに投げます。
• サーバーは受け取ったパラメータを XML に変換し、 SOAP API にリクエストを投げます。
• サーバーは SOAP API から受け取った XML から必要なデータを抽出して JSON に変換します。
• サーバーは変換したデータをクライアントに返します。

上記のうち、2~3の処理は SOAP クライアントというモジュールとして分離して実装しました。 こうすることにより、別のフレームワークを使うサーバーに機能を移植することや、サーバー自体のインターフェースを変えずに SOAP API ではない別のサービスを使用するように構成を変更することが可能になります。

SOAP クライアントの処理はさらに query maker と query parser という処理に分かれています。 SOAP クライアントの処理は以下の通りです。

• 引数としてパラメータを受け取る。
• query makerにパラメータを渡し、XML形式のデータを生成する。
• HTTPクライアントを使ってSOAP APIに生成したXMLデータを投げる。
• SOAP APIから返ってきたXMLデータをquery parserに渡し、JSON形式のデータを生成する。
• 戻り値として生成したJSONデータを返す。

どのように業務を進めたか

まず SOAP API で返されるデータの構造について調べる必要がありました。SOAP について調べ、どのようにデータを送ればよいのか、 インターフェース定義はどう読めばよいのかを調べました。SOAP は wsdl というファイルでインターフェースを定義しているのですが、 そのままでは Typescript では取り扱えないので、定義の読み方を調べて typescript の型定義として作り直しました。

SOAP API のリスポンスサンプルはドキュメントには書いてありましたが、それだけでは構造がよくわからなかったので、そのリスポンス内に 含まれているオブジェクト同士の関係性を ER 図のような形で書き起こしてみました。さらに航空券の仕組みを調べ、それと照らし合わせることで、 どの要素が何に相当するのかを推定しました。（たとえば「予約」には「運賃」の情報が必要。「運賃」にはさらに「運賃ルール」や実際に使われる「航空便」 の情報が紐づいている。一方で検索で返ってくる情報は「旅程」で、この中には「航空便」のリストや「運賃」のリストが含まれているので、 予約をする場合は「運賃」情報を抜き出す必要がある。）その過程で意味の分かりづらい名前は分かりやすい名前に変更しました。

SOAP APIのオブジェクトはいろいろな場所で使いまわされている（例えば「検索」APIの結果に含まれる「運賃」情報と 「予約」APIの結果に含まれる「運賃」情報が同じ）ので、オブジェクト単位でパーサーが作れるようにしました。例えば、 「検索」結果をパースする機能は「運賃」をパースする機能と「航空券」をパースする機能を組み合わせて作れるようにしています。

画面に表示したいだけの情報を返せれば十分なので、最初は検索・予約の一連の処理をするのに最低限必要なデータをパースする機能だけを作り、 要件に応じてパーサーの機能を追加していきました。

設計・実装

フルスタックフレームワークの Blitz.js を使って実装を行いました。 最終的に、データベースの構造は、大きくわけて請求書、仕訳項目、予約の３つに分かれました。

トップページからそれぞれのデータの検索・一覧ページに飛ぶことができ、さらにその中で 新規作成画面や詳細表示・編集画面に飛べるような構成になりました。 検索・一覧ページは、ページ上部に検索フォームを置き、下部に検索結果のテーブルを置くような 構成にしました。テーブルの行をクリックすることで詳細表示画面に移動できます。

どのように業務を進めたか

会計の仕組みについて調べ、そこからデータベースの ER 図を作成しました。 要件の内容について詳しく聞き、その情報を既存のデータベースに入れるべきかどうかを判断し、 場合によってはテーブルの定義を分けて ER 図に追加しました。