「注文書を自動でＦＡＸ送信出来ないか？」とのご要望を頂きまして、過去サラリーマン時代の基幹システム(NEC ACOS-2)で実際に運用動作していたし、「っま可能ですよ。」と、ご回答しておきました。
で、具体的な案件はまだ決まっていないのですが、コレは他にも応用が利くので、実際に実装を意識しての調査やらテストやらを開始したワケです。
まず、要件として「基幹系システム（サーバー）は、対象となる注文データを、直接ＦＡＸを送ることはしないで、CSV形式でエクスポートするダケで、あとはソッチで何とかしてチョ。」となれば、サーバーを新規に建てずに、クライアントＰＣのwindowsアプリで行けそうだ・・・となり、エクスポートされるデータがマスタデータなどに依存しなければ、単純にデータを注文書（レポート）に整形し、各業者さん毎にＦＡＸ送信といったシンプルな処理で行けそうです。
で、最初にFaxModem（安価な中国製のclass1）を入手し、windows添付のFAXユーティリティーで送信テスト（懐かしいなぁ。こんなのCanBeでやったなぁ）。あっさり成功。
# 事務所には電話回線ないのですが、自宅にはISDN時代のナゴリで、局番の違う２回線があり、テスト環境は「偶然バッチリ」でした。
ＰＣはmodemに繋がったし、次はアプリを何で作るか？
最新はすっかりtomcatやらspringやらでjavaを使ってwebアプリ開発にイソしんでいたので「久しぶりにswing使ってjavaのクライアントアプリにしようか」と調査をしておりました。RS232C（これまた懐かしい）っまシリアル通信をjava.Communicationsでホホイと監視・制御することでmodemとやり取りし、そこら辺は意外と何とかなりそうだ・・・との感じ。しかし、肝心のＦＡＸ送信文書（イメージデータ）は、自力で白黒のドットの連続を作らねばならない模様・・・ああああ、面倒そうです。
ならば、これまた久しぶりのvisualBasicでwindowsアプリを作ったら・・・と、調査してみると、結構、簡単そうな感じ。早速、倉庫に眠っていたインストールディスクでＰＣに開発環境をセッティングし、サンプルを参考にホンの数行をコーディングし、テストしたところアッサリ成功。しかも予め作成しておいたPDFファイルを指定しただけで、イメージデータも特別な処理いらない。さらに例のwindowsのＦＡＸユーティリティーで送信関連の管理がメーラー感覚で出来るので、送信状況のモニタや、再送信や印刷への処理転換などの正常外処理もいらない。おおおお！！！！天国ですね。
この案件、意外と難航するカモ？と、今朝、仏壇のご先祖様に拝んでおいたのですが、すっかり目処が立ちました。戻ったらお線香をあげる心算です。
今まで「大なり小なり」システムを構築し、稼働させて頂きましたが、それらは個別に設計・実装されたモノでした。
以前から構想していたシステムのCoreな部分である要素（組織・人物・住所・製品）の土台部分を理想的に充実させ、その上に各個別のカラクリを載せる・・・といった考えを進めるべく、ライフワークとして取り組んでいた「Mighty構想」が、ついに今回リリースした実稼働システムに採用されています。
で、個別部分の初回の機能の動作確認が終わり、ちょこっとした要望もシステムに反映し、では次の機能拡張を・・・と。
・・・・待てよ。次の機能も初回と同様にcsvファイルのアップロード処理が入るなぁ・・・・。初回ではブラウザ外からのドラッグ＆ドロップと、複数ファイルの同時処理を入れなかったケド、テスト時の動作確認では結構面倒だったなぁ。
よし、古いIEでは出来ないが、それは救済機能を入れてコイツらを実装しようじゃないか・・・・と。
クライアントのブラウザ側はjQueryをprototypeと住み分けながらAjaxとして実装。ところがサーバー側のspring君が、ファイル１つでは動作するが複数を放り込むとエラーで動作しない！！！
１日中調査をしたら英語のサイトで、同様のトラブル対処の仕方を解説してくれているっぽい感じである。つたない英語力でヒィーヒィー解読しながらも、昨日はタイムアップ。
で、家で一杯やったり、事務所への自転車往復などで頭を冷やして、本日・冷静に考えて、「これって最近のspringならOKじゃないの？」と、面倒なモノだからあえて目線を変えて、昨日も特に参考にしたサイト（日本語）を、飛ばさないでゆっくりジックリ読んだ。
エラーからもリゾルバが処理できていない感であったのだが、このサイトの説明では、今まで使っていた「org.springframework.web.multipart.commons.CommonsMultipartResolver」ではなく、「org.springframework.web.multipart.support.StandardServletMultipartResolver」ってのを使っていて、コイツで上手く動作するらしい。
で、springを2.5.6から3.2.9に上げて、上記のサイトの丁寧な説明に沿って設定を書き換えたら・・・・「あっさり動作した」。
心にトメよ
使い慣れた環境に甘んじずに、新しいバージョンを積極的に採用しよう！
（ではなぜ最新の４にしないのか？）・・なにやら大幅に変更があったらしく、色々と調整に手間がかかりそうである。ので、そこまでハマリたくない。ヨウは、「このようにシタイ」ことが「技術的にデキレば良いのである」。
とにかく、アキラメなくて良かった。・・・（← 最近のアキラメは方向キーで選択できるサジェスト機能であった。マウス選択での実装で妥協）とほほ。
RAID1のNASを使い始めて５～６年になりますかね。現在２台のNASがシッカリと働いてくれています。で、HDD交換です。雪の騒ぎが落ち着いた月曜日にコンビニに到着済みのHDDを受け取り、チャッチャっと換装し、現在再構築中です。っま、ランプも点滅しますし、ご丁寧にメールでも「１番のHDDヤバイよ」と通知してくれるので、毎回余裕を持っての交換作業です。
もうこの作業は容量アップも含めて３～４回やっているので、何も問題はありませんが、思うに、年に１回位はHDD障害が起こっているってコトで、RAID1導入以前にはいつもデータ保全を気にして、CDやDVDに焼いたり、別のHDDにバックアップしたり、ヒヤヒヤものだったのが、ほんに「アリガタヤ」です。
ちなみにデータを失いカケタ昨年末のお客さんにも導入してもらいました。
あと、amazonの「コンビニ受け取り」も、今回で３回目の利用ですが、今回もドンピシャでした。土日には事務所には居ないし、ましてこんな雪の日に宅配のタイミングがずれて、再配達してもらうには、コッチもソッチも大変な思いですが、コノ受取方法はコッチの都合でナントでもなるし、非常に便利！
さて、恒例の申告の会計処理もヒトマズ終わったことだし、エンジンかけて行きますかぃ？