投稿者: yamamoto

投稿日:

投影された壁

電子カルテ更新を来年初頭に控え、クライアントのセットアップとソフトウェア環境の確認作業の真っ最中。これまでは、電子カルテ本体に何らかのアプリケーションを導入するということはお願いできず、ずっと我慢してきた。10年以上の説得と実績から、今回初めて小さなソフトを一つ導入することが出来た。

一つだけだが、EGMAIN-GXにhttpインタフェースを追加するもの。サーバーやクライアント上のブラウザから、EGMAIN-GXの機能を呼び出すことが出来るようになる。ブラウザで実現した診療支援ツールから、検査オーダーの起動やエディターへの挿入、グラフなどの貼り付けなど、電子カルテの強化を図れる。

電子カルテの各種ツールをブラウザから呼び出せる。最上位のエピペンはセット登録名。病院カルテの複雑さは細分化されたり大量に登録されたオーダーやプリセット群。階層構造にすることでクリック数が増え、一つのオーダーを選ぶのに最低でも5回程度のクリックが必要。支援システムは目的に応じて次のアクションを提案できても、改めて電子カルテ側で選択し直すという障壁があった。これをショートカットする切り札になる。電子カルテ側インターフェースのベースは「FileMaker対応モジュール」である。ユーザーメードが突破口になったのは確かだろう。

4年前に発注したソフトであるが、結果的に電子カルテ更新まで日の目を見ずやっと導入に至った。しかし、些細な問題も積み残したままだった。JAVAで製造された常駐ソフトであるが、サービス登録できるほどの機能は無く、立ち上げるとタスクバーにウインドウが残ってしまう。このウィンドウを消されてしまうと、電子カルテを再起動するまで機能しなくなってしまう。ウインドウ無しで起動したかったが「セキュリティのためにウインドウがどうしても出てくるのだろう」とあきらめていた。

担当ＳＥからのメールで、このウィンドウを消して稼働すべきと指摘があり、出来ていないとメールする前に、もう一回調べてみた。結果vbsで起動用のbatをラッピングすることで、見事にバックグラウンドで起動したままにすることができた。

何年も漠然と、出来ないものだと決めつけて一歩踏み越える努力を怠っていたことに気づく。壁のなかには自分だけが勝手に作り上げた張りぼてもあるものだと、改めて思う。

投稿日:

久しぶりの障害

FMS17にしてから、本当に安定していて再起動自体があまりない。安定していることはよいことなのだが、いざ障害が発生した特の手順やノウハウがあまりないというのも事実。昨日はまさにそんな瞬間だった。

原因は単純。連携用VMのハードディスク領域が一杯になった。ということで、復旧が大変なんですが対応は簡単。だったはず。でもそうじゃなかった。まず、受け取れていない大量のジャーナルがあるため、送り元にジャーナルの再送を依頼する必要がある。これは避けて通れないので、帰宅途中のSEにお願いした。

しかし、ハードディスク領域がそれほどまでに消失されたのは、実は数百件にもおよぶ電文が何千回もリトライしていたからである。さて、このリトライの原因がわからない。十数本あるJDBCのラインの一本が滞留し一個もデータが流れない。

よく観察すると、正常と思われる電文さえ流れずどんどん滞留してリトライしている。これはデータベース本体の損傷？を疑い、バックアップからデータベースをデプロイし直して試すもだめ。データベースサーバーの再起動（データベース再起動は、起動後２回目という珍しさ）までしたが、全く反応しない。

さらにログの解析をしつつ、データなしのデータベースをアップロードして試すも動かず。すると、一瞬xDBCインターフェースが起動するがすぐに落ちるというのが繰り返されていることも気付く。たった一つの電文がインターフェースをクラッシュさせ、それが復旧しても、最初のリトライで再びクラッシュ。延々と何千ものリトライが続く流れになっていた。その連続するクラッシュがさらなるエラーログを発生させ、半端ない性能のVMが大量のハードディスク領域を消費して、電文欠落が発生したと。

さらに、この原因電文が半年前の障害と同じ原因であることも判明。（FileMakerのxDBCにはSQL長の限界があるみたいで、それを超えるとクラッシュする）しかも、その対処用の新バージョンのミドルウェアの納品を受けているのに、それをアクティベートするプログラム側の更新を怠り、古いまま動き続けていたと。

とにかく自分の間抜けを思い知った一瞬である。なので、対応昨として失敗ブログにしてみた。

文章化することは、いろいろな意味で記憶の強化となる。たとえ失敗でも。

投稿日:

httpsへの対応メモ

whois情報の確認を怠りレジストラからお預けを食らったことを反省。レジストラの諸々の情報の見直しを掛けたついでに、レンタルサーバへDNSを移管した。それを機にレンタルサーバー側の設定の見直し。

サーバー側が常時SSLに対応を掲げていたため、試しにSSLアクセスへ変更。デフォルトの証明書はサーバーの素のドメイン名であるため、medicalmacドメインでアクセスすると証明書に不備があると（当然）して、手動で通さないと通信できない。ただし、通信自体はレスポンスも問題無く、画面遷移も若干のhtmlの書き直しでリンク切れなども発生しないことを確認。

2日ほどデバッグを行い、1年前にセッティングしたwordpressも最新版へアップデートをかけ、phpもアップデート。

サーバーコンソールをよく観察するとLet’s encriptの設定タブがあったので、デフォルトの証明書からこちらへ切り替え。最初はワイルドカードを選択し、DNSへのtxt追加が出来ないためはじかれたが、単純なドメイン認証だけにしたらあっさり通過。ものの10秒程度の作業だった。

実はこのドメイン2001年ぐらいから。その前はso-netのページだったがこちらに移管して18年が経過していた。なので、googleの検索から飛ぶと当然httpになる。そこで、サイト直下の.htaccessファイルに

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

を書き込んで設置することで無事、googleからのリンクでもhttpsへ飛ぶことを確認した。特に商売をするわけでもなく、アクセスも極端に減った現在、ランクの高い証明書をインスルトールする必要もないと判断した。