月曜日, 10月 27, 2008

【EC開発体験記-EDI-】 SVNを業務で使い倒す このエントリーを含むはてなブックマーク



 EDIで外部システムとの連携を考えるときに最も注意しなければならないのはデータの不整合である。これは、送ったはずのデータが送られていない、あるいは、受け取ったはずのデータがなくななるといったことであるが、基本的にこういったものは「性悪説のスタンス」で設計した方がよく、むしろ、日常茶飯事でトラブルが起きるぐらいの覚悟でいるとちょうどよいと思われる。
 
 ということで、EDIをSVNで管理することを考えてみた。SVNといえば、ソースコードやドキュメントの履歴管理によく使われる、開発者にとってはお馴染みのバージョン管理ソフトである。これをEDIに活用して、送受信データをいつでも再送/再受信できるようにしようというわけだ。特に人手を介して入手するマスター類の登録などでは真価を発揮する。いつも送った送らないで揉める人間系でもSVNの履歴には反論の余地がない。SVNを業務アプリケーションに使うことに違和感を覚える方も多いと思われるが一度利用してみることをおすすめする。


<SVNによるEDI> 


<SVNをEDIで使うメリット>

1)一貫性確保 ・・・ コミットしたものと送受信したものが同一であることを保障できる
2)実績確認  ・・・ いつ何をどれくらい送受信したか実績を確認できる
3)リカバリ対応・・・ 履歴から過去データを取り出せるためいつでも再送できる

<SVNをEDIとして使うケース>

1)物流      ・・・ 物流業者への出荷指示データの送信と出荷済データの受信
2)商品マスタ  ・・・ 商品部からの商品マスタの受信とホームページへの反映
3)在庫管理    ・・・ 倉庫からの在庫データの受信とたな卸しデータの送信


 一貫性が保障できて実績が確認できればエビデンスとしても利用できる。対外システム側との取り決めが必要だが、例えば、SVNファイルを正と取り決めておけば、物流業者の請求金額についてはSVNファイルの「出荷済」のレコード数をカウントすることで確認できる。また受け取ったデータをそのままコミットしておけばトラブルがあったときにリカバリーも確実に行えて原因を突き止めることが容易になる。
 EDIでは、まず、送ったものと受け取ったものを確実に管理することが重要である。基本はトランザクション処理と同様の考え方で、成功でコミット、失敗でロールバックとすればよい。以下の例では、SVNのDIFFをとり新規分があればupdateして送信するが、失敗すればリビジョンを元に戻すという動きをする。これは実際に使っている全銀システムと通信するコードの抜粋である。全銀ISDN回線で話中で数回に1回の確率で失敗するようなFuck!な連携システムでもSVN履歴管理はとても有効である。


# 未送信分チェック(送信すべき新規のファイルがSVNにあるかどうかをDIFFを使って調べる)
DIFF1=`svn diff --revision BASE:HEAD hoge.dat`
if [ $? != "0" ]; then
    echo [`date`] ファイルが未更新
else
    if [ -n "$DIFF1" ]; then
      echo [`date`] ファイルが更新されています
      svn update hoge.dat

      # 送信処理
       ・・・
      # 送信成功?
      if [ $? != "0" ]; then
        # もし送れなかったらエラーを報告してリビジョンを1つ前に戻す
        echo [`date` ] エラーが発生したため処理を中断します。
        svn update -r PREV hoge.dat

      else
        # 送信成功
        echo "送信成功!"
      fi
    fi
fi



 また、TortoiseSVNとの組み合わせにより、Windowsフォルダを操作する感覚でSVNを扱えるのも嬉しい。これにより、オペレータさんなど、SVNコマンドの特別な知識がない方でも扱えるようになる。オペレータさんは通常はデータを生で見ることはあまりないが、エラー発生時のファイルの状態やコミット時間、件数を報告してもらうとトラブルに迅速に対応できるようになる。

 たまに、SVNのdb内で不整合が発生してエラーになることがあるが大抵svnadminコマンドでリカバリーできる。


/usr/bin/svnadmin recover /usr/local/svn



 SVNエラーは大きいファイルをhttp(https)でコミットしようとすると起きやすいため、svn+sshで接続することをおすすめする。実際にsvn+sshで50万件の商品マスタを毎日コミットしていたが特に問題なく運用できていた。
 TortoiseSVNからsvn+sshで接続するのは以下のように設定するとよい。






 ちなみに、弊社では上記のSVN EDIソリューションを、Reflexパッケージとともに提供していきたいと考えている。SVNは内部的にberkeley dbを使用しているため再販するためにはOracleライセンスが必要になるが、弊社はReflexパッケージのなかでライセンス許諾権を結ぶことでOracle社と基本合意している。(11月中に締結予定)
 
<関連>

【EC開発体験記-スケーラビリティ-】信頼性とジレンマ
【EC開発体験記-トランザクション処理-】古くて新しい永遠のテーマ

2 件のコメント:

masaruyokoi さんのコメント...

svn で利用する db っていくつか選べられるようです。 svnadmin help create なんてコマンドを叩くと --fs-type っていうのが選べられるのです。 ここで fsfs っていうのを選ぶと Berkeley DB でないファイルシステムを選択できるんです。

HTTP 経由で大量データを送って失敗するのはなぜなのでしょうかね。。。 コミット中に timeout でも起きるのですかね。 その辺では ssh なら安全ですからね。

takezaki さんのコメント...

>ここで fsfs っていうのを選ぶと Berkeley DB でないファイルシステムを選択できるんです。

おおお、そうでしたか。

 
© 2006-2015 Virtual Technology
当サイトではGoogle Analyticsを使ってウェブサイトのトラフィック情報を収集しています。詳しくは、プライバシーポリシーを参照してください。