ダイレクトプリントの話
リモートワーク
今年は北海道も暑いよ
会社が完全リモートワークになって、基本的にどこに住んでも良いということになったので、札幌に帰ってきました。
冬は寒いだろうなあ？と身構えていましたが、家の中は東京よりもずっと暖かく。夏は涼しいだろうなあと楽しみにしてたらこの猛暑。
札幌はエアコンがない家が多いので、東京よりもかなり厳しいです。
エアコンを付けようかとも考えましたが、10年以上前に建てられたアパートの場合、そもそもエアコンを付けることは考慮されていないので、簡単にはいきません。
取り付け手続きを聞いただけで嫌になってやめちゃいました。
来春にまた考えよう。
サーバー印刷とクライアント印刷
SVFの始まりはサーバー印刷
SVFは帳票サーバーを構築するツールです。
各種入力データとデータベース内のマスターデータから印刷データを作成し、帳票サーバーに直結されたプリンターから出力されます。
そうです。初期の頃はプリンターはPCに直接接続されていました。
最近だとデスクトップPCでもプリンター接続用のコネクターなんて付いてないですけどね。
その後、LANが一般的になり、帳票サーバーとプリンターが同一フロアにある場合は、ネットワーク接続して使用するようになりました。
PAを作成した経緯
RDEを作っている途中でPAを作ろうと思った話を少ししましょう。
PAというのは、帳票サーバー（RDE）がある場所とは物理的に離れている場所で印刷を行うために、遠隔地のPCに入れるアプリです。
20年前の話（ああ、もうそんなに経ったのか）です。インターネットはありましたが、今のように高速回線が常時接続されているわけはなく、当然VPNなんかもありません。
インターネットにつなぐにも、拠点間をつなぐにも、ダイアルアップ接続（電話をかけて通信を行い、時間による従量課金）していました。
拠点間接続を必要とするような会社ではISDNというデジタル回線を引いて、64Kbps（または2回線を束ねて128Kbps）という通信速度でした。
これでも当時としては高速かつ安定した通信でしたが、いかんせん64Kbpsでしかありません。
スマホで、ギガ使いすぎて速度制限されても128kbpsくらいなので、その半分の速度です。
普通の会社はモデムを使用していたので、28.8Kbpsくらいでしょうか？
64Kbpsの半分以下ですね。
えっ？私ですか？私は自宅にISDNを引いていた変な人です。
ただ、64Kbpsで接続できる先はあまり無かったので、デジタル回線なのにモデムを使うという無意味な状態が長かった気がします。
RDEから遅い回線を経由してPAまで印刷データを送ることになります。
通信時間に応じて課金されるので、できるだけ通信時間を短くしたいということで、印刷データを圧縮して送るようにしました。
前回お話ししたように、SVFは自前で印刷データを作成しているので、印刷データは自在に取り扱えます。なので、圧縮も簡単です。
PAって、構想時にはなかったんですよね。
「遠隔地に印刷したい人いるんじゃないの？」
「従量課金だとお金がかかって大変だろうなあ？」
「こんなのあったら便利なんじゃないの？」
と特にニーズの調査などしたわけではなく、勝手に作ったものでしたが、これが意外と使われることに。
この頃に半分冗談で作った諸々の製品が今もどこかで使われていたりして、サポートさせられる人は大変だろうなあと思っています。
C言語で作られたツールなんかは、実機がないとビルドできないので、現地まで行って客先でコンパイル作業したりしてました。
何かのコネクトのクライアントだったと思いますが、NEWS（ソニーのUnixワークステーション）版をビルドしに行った記憶があります。
クライアント印刷
SVFを売っている側としては、印刷を必要とするすべての場所にSVFを導入して、帳票サーバーをたくさん構築してもらえると儲かるのですが、裏側にはデータベースなんかも必要ですし、なかなかそういうわけにはいきません。
旅行会社の店頭で旅行スケジュールなんかを印刷したり、車屋さんの店頭で見積書をもらったりすることがあると思いますが、あれは各店舗に帳票サーバーがあるわけではなく、本社かどこかにある帳票サーバーに指示を出して、店頭にあるプリンターから印刷していることが多いと思います。
印刷指示はクライアント（店頭）側PCから行い、印刷データの作成はセンター側の帳票サーバーで行われ、印刷はクライアント側PCから店頭にあるプリンターへ出力する。という流れになります。
こういう構成をクライアント印刷と呼んでいます。
SVF Cloud Agent
クラウドチームなので、SVF Cloudの話をしましょう。
SVF Cloudで印刷を行うために使用するのがSVF Cloud Agentです。
SVF Cloudの場合、いわゆるサーバー印刷というのはないので、クライアント印刷とは呼ばず、ダイレクトプリントと呼ばれています。
クラウドからプリンターにダイレクト！ということでしょうか？
SVF Cloud Agentの特徴
ここではSVF Cloud Agentの特徴について説明します。
SVF Cloudとの通信方法
プリンター検索
プリンターの状態を通知
SVF Cloud Agent自身のアップデート
PDL／EMFPlusによる印刷
SVF Cloud Agentの冗長化
SVF Cloudとの通信方法
当たり前ですが、クラウド側にあるSVF Cloudと通信する必要があります。
SVF Cloud Agentの総数が何台になるかわからないので、常時コネクションを維持するような構成にはできません。
SVF Cloud APIの呼び出しとメッセージの送受信を利用してやり取りするようになっています。
プリンター検索
SVF Cloud AgentはWindows PCで動作します。
プリンターの検索では、Windowsに登録されているプリンター（ローカルプリンター）とネットワークプリンターの検索を行うことができます。
プリンター検索では、
プリンターベンター
機種名
PDL（印刷に使用するページ記述言語）
シリアルナンバー
などを取得します。
プリンターの印刷設定は、これらの情報を使用して自動的に行われます。
使う人がプリンターに詳しくなくても勝手に設定してくれるので、簡単に使うことができます。
もちろん、プリンターのことがよくわかっていて、PDLを指定したい人は設定を変更することで使用できます。
プリンターの状態を通知
プリンターの状態を取得して、クラウド側に通知しています。
どうやって取得しているかは前々回、前回の記事を参照してください。
プリンターの状態はSVF Cloudマネージャー画面で見ることもできますし、APIで取得できるのでユーザ側のプログラムで利用することもできます。
必要に応じて、プリンターの状態を確認してから印刷指示を行うとか、印刷先のプリンターを変更するとか、そういうことに使えます。
SVF Cloud Agent自身のアップデート
SVF Cloud Agentは、機能追加やバグ修正などで新しいバージョンがリリースされることがあります。
新しいバージョンがリリースされても、勝手に更新されることはありません。
ユーザー側の管理者が「新バージョンを適用しよう」と考えた場合に、SVF Cloudマネージャー画面から「SVF Cloud Agentのバージョンアップ」を指示することが出来ます。
バージョンアップ後のSVF Cloud Agentは「自身が正常に起動できなかった」ことを検出すると、自動的に従来のバージョンに切り戻します。
また、正常にバージョンアップして動作しているとしても、ユーザー側の管理者が「古いバージョンに戻したい」と考えた場合は、直前のバージョンに戻すことができます。
PDL／EMFPlusによる印刷
さっき、半分冗談で作ったものが結構売れてしまったという話をしましたが、売れたということは使い道があるということで、手直しされて生き残ることがあります。
昔、JavaアプリからEMFを印刷するのに使えるライブラリを作って、当時の製品名は分かりませんが、知らないうちにたくさん売られていてかなり驚いた記憶があります。
かなり前に販売終了になっていると思いますが、SVF Cloud Agentの印刷部分も元を辿ればこれです。
これを元にEMFPlusも印刷できるようにして、ログ出力などを手直ししたものがSVF Cloud Agentの印刷処理で使われています。
今、元ライブラリのソースを確認したら、19年前でした…
PDLが得意なSVFですから、EMF／EMFPlusだけではなく、PDLによる印刷ももちろん可能です。
SVF Cloud Agentの冗長化
ローカルプリンター（Windowsのプリンター一覧に登録されていて、Windowsスプーラーを経由して印刷する）の場合は無理ですが、ネットワークプリンター（SVF Cloud Agentからネットワークを利用して直接印刷する）の場合は、複数のSVF Cloud Agentから印刷を行うことができます。
どれか１台が動作していれば印刷できるため、PCの故障やアップデート作業などの場合でも印刷を継続できます。
最後に
SVF Cloudは、PDFを生成してファイルをダウンロードするという使われ方が多いのですが、まだまだプリンターへの出力も使われています。
SVF Cloud Agentは今後ものすごい機能強化が行われる、ということはないと思いますが、これからもひっそりと動き続けます。
この記事が気に入ったらサポートをしてみませんか？