「Developers Summit 2009」講演レビュー（２）

[hmino]

みなさん、長らくお待たせしました。
Developers Summit 2009のレビューPart2をお伝えします。
前回はWebアプリケーションの問題点やそれに対するCurlのOCC機能の説明やローカルDBアクセスについてお話いたしましたが、今回はCurlのOCC機能を使用した事例であります佐川急便様のe飛伝Ⅱをお話いたします。
佐川急便様は皆様ご承知の通り、宅配便でおなじみの会社様です。

しかも今回お話させていただくe飛伝Ⅱで出力された帳票はおそらくほとんどの方が一度は目にしているはずです！アプリケーションの機能の詳細はこちらをご覧ください。
講演当日は実際のアプリケーションのデモをケーブルをはずしてオフラインで実行してみたり、またe飛伝Ⅱから出力される帳票を実際に皆様にお配りいたしました 。
佐川急便様はお客様の満足度を更に高めるためにオフラインつまり障害時にもとまらないシステムを目指して開発されたわけですが、どのような課題があり、どのような解決をしてきたのかを以下の３つのポイントでお話させていただきました。

ローカルDBとサーバーDBの同期の方法やタイミング
明細情報（問合せ番号）のコードの採番方法
帳票のレイアウト作成と印刷の処理
e飛伝Ⅱではローカルやサーバーにこのような様々なテーブルがありますが、同期の取り方は基本は「ログイン時」にとっています。また、適宜ポーリング方式をとった同期と組み合わせております。 また、あるテーブルについてはユーザーが任意で同期を行うものもあります。

また、データベースに関して面白い方式をとっておりまして、同じユーザーで複数ログインができるようになっていることから端末間の同期をとる仕組みも持っております。 簡単にいいますとローカルのテーブルにはダウンロード日時があり、サーバーにはアップロード日付を持っており、その比較で更新する仕組みを持っています。 また、ユーザーIDと端末IDも管理していることもポイントといえるでしょう。

その他としてはDBにはローカルでしか管理されないテーブルもあります。
たとえばプリンタの設定情報やローカルPCにある外部ファイルのCSVとの紐付けなど、各端末個別の情報などで業務に関わらないものはローカルのみで管理されております。
この点も運用負荷を軽くすることや、サーバーの負荷の軽減やユーザーへのクイックなレスポンスを実現するのに不可欠な工夫だと思います。
次に明細情報のコードの採番方法ですが、通常、トランザクションコードはサーバー側で動的に生成され、採番されることが一般的ですが、e飛伝Ⅱは送り状に問合せ番号を採番する仕組みを「空き番号」制のようなものをとっており、クライアントDBに事前に空き番号を振り、空き番号がある場合はクライアントの送り状を管理するテーブルにデータと問合せ番号とともに登録する仕組みとなっています。この間、サーバー接続はありません。

最後にサーバーへ問合せ番号およびデータを登録へ行きますが、オフラインの状態であっても業務は簡潔するようになっています。 つまり、この「空き番号」制が非常に工夫されたものとなっているからです。
また帳票レイアウトの作成と印刷は一般的には帳票サーバーでレイアウトの処理を行い、印刷することがほとんどですが、Curlならカールだけで帳票の作成から印刷まで含めてクライアントで実行することができます。ですからオフラインの状態であっても帳票作成から印刷までをも可能することができるのです。このことはサーバー負荷の軽減にもつながってきます。

あまり細かい部分はお話することができないのですが、是非みなさんもオフライン機能を使用して「とまらない業務」を実現してください。

では