カテゴリー: FileMaker

投稿日:

FileMakerからCP932の出力

ソケット通信用の固定長のデータをfileMakerで出力する目的でShift-JISで文字を外部テキストファイルとして生成する必要がある。ただし、オリジナルデータは基幹システム上にあってCP932で送付され、ミドルウェアでCP932 -> UTF-8 となっている。

とくに人名に含まれる「﨑」「彅」「髙」などの拡張文字がはいると、Shift-JISに変換するときにまったく出力できないという問題があった。

これまで、最後に改行を含まないデータを出力する場合、BaseElemntプラグインを使用し、BE_SetTextEncoding ()でshift-jisにしていた。これをCP932に設定しても動作せずオーバーヘッドを無視するなら、別にインストールしたiconvを使い、UTF-8で出力したファイルをCP932に変換するなど行う必要があった。

ファイルメーカー標準のフィールドのエキスポートには、文字コード設定がなく無理と決めつけていたが、オンラインのFileMaker勉強会で質問したところ、FileMaker 16から使えるTextEncode()を使うと良いのでは無いかと指摘された。

具体的にはグローバルオブジェクトフィールドにTextEncode($text,”shift_jis”,4)として一旦作成し、これをフィールドのエキスポートを使って出力し、上記の文字が問題なく変換されていることを確認した。ただし、変換できない文字は半角スペースになることから、正確にバイト長を合わせなければならない、固定バイト長ソケット電文を作成するには問題があった。

そこでさらに、JIS変換後に何バイトになるのかわかるカスタム関数を

GetContainerAttribute ( TextEncode ( w ; “shift_jis” ; 4 ) ; “fileSize” )

として用意して固定バイト長が破綻しないようにできた。非常に有用な知見であった。

投稿日:

投影された壁

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

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

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

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

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

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

投稿日:

久しぶりの障害

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

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

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

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

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

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

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

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