FileMaker でレスポンシブなWebアプリを作る

　FileMaker（以下、FM）のデータベースを FileMaker Pro 以外のクライアント ― ブラウザ、iPhone/iPad、Android ― でも運用する場合、開発環境をFMにすべきか、カスタムWeb にすべきかを考えると思いますが、その際に考慮べき事項を比較表にまとめてみました。

×: terrible,  △: limited,  〇: OK,  ◎: Excellent

	Go	WebDirect	Custom Web
開発費用 (Devlopment cost)	◎	◎	×
ライセンス費用 (License cost)	×	×	◎
サーバ機費用 (Server machine cost)	×	×	◎
ライセンス体系 (License policy)	×	×	◎
開発の容易さ (Ease of development)	◎	◎	×
コードの再利用性 (Code reusability)	×	×	◎
開発の柔軟性 (Development flexibility)	×	×	◎
レスポンシブ性 (Responsive Web Design)	×	×	◎
Android等非iOS機との互換性 (Android compatibility)	×	△	◎
スケーラビリティ (Scalabilty)	△	×	◎
他DBへの移植 (Migration to other DBs)	△	△	◎

この表からは、

圧倒的ではないか、カスタムWebは

という感じですが、FMの世界では「開発費用」と「開発の容易さ」が他の要素を圧倒し、Go やWebDirect が採用されやすいのではないでしょうか。逆に言えば、他の要素が重要なプロジェクトでは、FMは使用されないのです。
　
　とは言いいつつ、 FM のカスタムWeb という需要は少なからずあり、またスマホ普及に伴う Mobile First な要望もあり、小社としてもまたーりとそれらにお応えしたい、と愚考している次第です。
　そんなわけで、『FMEasy在庫 IWP/WD R1.5』（以下、FMEasy在庫）をバックエンドに使用し、 iPhone/iPad だけではなく Android 等の非iOS デバイスにも対応したレスポンシブな Webアプリのプロトタイプ開発にトライしていきたいと思います。

開発環境

使用データベース： FileMaker(fmp12)
使用ライブラリ： jQuery、ｊQuery Mobile
対応デバイス： PC、タブレット、スマホ（非iOSデバイスを含む）

開発方針・目標

第１フェイズ

以下の方向で、FMEasy在庫の出庫関連機能をWebアプリ化→プロトタイプを作成する。

1. マルチデバイス対応、RWD(Responsive Web Design)採用
   たとえばこんな感じで……。
   
   【PC利用時】
   
   

   

   Windows Chrome

   
   
   【タブレットPC利用時：縦置き】
   
   

   

   Nexus 7, Android, Chrome --- Portrait

   
   
   【タブレットPC利用時：横置き】
   
   

   

   Nexus 7, Android, Chrome --- Landscape

   
   
   【スマートフォン利用時】
   
   

   

   FreeTel Priori 3, Android, Chrome

   
   
2. XML/fx.php/FM API for PHP/PDO（ODBC）の比較テストを適時実施
   　→最適なAPIを決める（努力をする）
3. 出庫伝票照会機能作成
4. 出庫伝票追加・更新機能作成
5. 出庫伝票検索機能及び一覧表示機能作成
6. 出庫伝票PDF出力機能作成

第２フェイズ

1. 第１フェイズで作成した機能をライブラリ化
2. ライブラリを他のDBへ対応させる（PDOなら簡単なんじゃないかな）

第３フェイズ

1. 上記ライブラリを使用することにより、お客様にレスポンシブなシステムをリーズナブルな価格で提供する
   ＼(^_^)／

　いろいろ書いてますが、予定は未定ですｗ

本ブログの関連記事について

　本ブログで今後公開予定の RWD によるカスタムWeb関連の記事は、カスタムWeb による開発を検討されているお客様に小社で開発したプロトタイプの仕様やテスト結果をご覧いただき、プロジェクト検討の一助になることを目指しています。

ということで、次回はこのプロトタイプの照会機能についてご紹介したいと思います。

（亀）　

WebDirect 14 vs 15 ― JMeter による負荷テスト

　FileMaker インスタント Web の後継版として、FileMaker 13 より WebDirect （以下、WD）が登場しました。インスタント Web に比べ、 WD の操作性はより FileMaker Pro に近づいたものの、パフォーマンスや安定性にかなり問題があるんじゃないか、みたいなことを約1年前に記事にしました。 その折は、WD13 と WD14 の2つのサーバ上で、複数のクライアントPCを用意し、各PCで複数のブラウザウインドウを開いた状態で、それぞれのウインドウからスクリプトを手動実行して負荷をかける、というものでした。
　今回は Apache JMeter （以下、JMeter）というパフォーマンステストツールを使用し、WD14 と WD15 のパフォーマンス比較をしたので、以下にその内容をレポートします。WD の採用を検討されている方の参考になれば幸いです。

テスト内容と結果

　今回のテストでは、小社製品「FMEasy在庫 IWP/WD R1.5」を使用し、出庫伝票を作成するスクリプトを作成。JMeter によりこのスクリプトを 25 のセッションで 10 回ずつ実行し、その所要時間を測定するとともに、CPUの占有状況を観察しました。　また、このテストは FileMaker 14 と 15 の双方で行うとともに、サーバのリソース（コア数とメモリ）を増やすことにより、パフォーマンスがどの程度改善するかも測定しました。

仮想サーバ構成

　CPU： 3.0Ghz
　コア数/メモリ： 1core/2GB、2core/4GB、4core/8GB　の3パターン
　Windows Server 2012 R2 (64bit)

JMeterシナリオ

　JMeter により、「FMEasy在庫 IWP/WD R1.5」の出庫伝票を1つ作成後にログアウトするスクリプトを以下のシナリオに基づき実行。　

　Threads： 25
　Loops：10
　Ramp-up：1sec
　Pause： 1sec or 1.5 sec

注：

• Pause を設けずにシナリオを実行すると、ログアウトを待たずに次々にセッションが実行され、最大同時接続数25を超過するエラーが発生して伝票作成に失敗するため、WD15 では 1 秒、WD14 では 1.5 秒 の Pause　時間を設けました。両者で 0.5 秒の差があるのは、WD14 を 1 秒で設定すると、同様のエラーが多数したためです。この点からも、WD15 のパフォーマンスが改善していることがわかります。
• シナリオ実行後は出庫伝票が 250 個作成されていることを目視で確認しています。未作成レコードがある場合、下表に記載しています。

テスト結果

WebDirect 14 vs 15 出庫レコード作成時のパフォーマンス（Fails は作成に失敗したレコード数）

Peformance comparison graph on CPU cores and memory

考察

※WD14 vs WD15 の比較

　サーバリソースにかかわらず、WD15 は WD14 に比し、30%程度実行速度が改善されました。

※サーバリソースと実行速度の改善

　サーバリソースを 1core/2GB から 2core/4GB に増やすと、WD15 で約 50%、WD14 で約 40%、実行速度が改善されました。
　さらにリソースを 2core/4GB から 4core/8GB に増やすと速度は改善されたものの、改善率はそれぞれ 20%弱と 15%弱となりました。このことから、リソース割り当てを増やせば実行速度は改善するが、その改善率は徐々に鈍化するものと推定されます。

　

※ CPUの占有率

　以下の図は JMeter 実行時の CPU 占有率です。　1コアの場合、CPU を使い切ってしまうことが多々ありました。やはり、CPU 占有率が 100%になるような状況は避けたいです。リソースを増やすに従い、CPU の使用率は下がります。


FM WebDirect 15

1 Core / 2 GB RAM

CPU 占有率が 100% に達する状態が続く。同時アクセスユーザが集中する可能性のあるサーバは要注意。

2 Core / 4GB RAM

4 Core / 8GB RAM

---

FM WebDirect 14

1 Core / 2 GB RAM

長時間にわたり高負荷状態が発生。WD15 に比べると処理により多くのサーバリソースを消費することがわかる。

2 Core / 4GB RAM

4 Core / 8GB RAM

JMeter テスト環境と運用環境の違い

　最後にJMeterテスト環境と実際の運用環境との違いについて簡単に触れます。下図左のグラフは JMeter でにより伝票作成スクリプトを 1 セッションで 1 回実行したときのもので、右のグラフはブラウザ上から手動により伝票作成スクリプトを1回実行したときのものです。サーバのリソースは共に 1core/2GB です。 JMeter では CPU のピーク時の占有率が約 20%であるのに対して、ブラウザでは 80％弱となっています。

　今回は WD14 と WD15 の比較とサーバリソースの増減によるパフォーマンスの変化をテーマとしているためあまり問題ではないと思いますが、実際の運用環境を JMeter によりシミュレートしようとする場合は、JMeter のシナリオを如何に運用環境に近づけるかが大きな課題となります。ただ、JMeter は実行するタイミングによってパフォーマンスにばらつきが出たり（実機でもそうですが）、シナリオを WD の運用環境に近づけるのはかなり難しかったりするため、その差分を係数化し、JMeter ではその係数分の負荷を余計にかける、などの補正が必要かもしれません。
　たとえば、下図のような状況であれば係数を 0.25 とし、運用環境で 20 ユーザが 10 秒間に 1 回レコード保存を実施すると想定されるのであれば、Ramp-up は 10 秒ではなく、2.5 秒に設定し、必要な回数のループを実行する、というのは一案と思われます。　


　それでも納得できないお客様に遭遇してしまった場合ｗは、必要台数分の仮想マシンや VDI 環境を用意し、FileMaker スクリプトを各仮想マシンから一斉に実行するような仕掛けが必要になるかもしれません。
　

その他の情報

ここでは、今回の JMeter による WD パフォーマンス測定で得られたその他の情報をまとめます。

1. JMeter で WebDirect にリクエストを発行すると、タイムスタンプが狂う
   
   レコード作成日時を記録するためのフィールドをタイムスタンプ型にしておくと、JMeter 経由で WD のレコードを作成／修正すると、タイムスタンプが協定世界時刻（UTC）になってしまうことがあります。
   
   

   

   この設定では、JMeter 経由でのレコード作成時に協定世界時が記録されてしまう

   
    つまり、日本時刻では 9 時間のズレが生じることになりますが、以下のようにホストのタイムスタンプを自動入力させることでこれを回避できます。
   
   

   

   Get( ホストのタイムスタンプ ) を計算値として自動入力することで時刻の狂いを回避

   
   または、Get ( 現在の時刻 UTC ミリ秒 ) を使って日本時間を算出することもできます。
   
   計算式：
   GetAsTimestamp ( ( Get ( 現在の時刻 UTC ミリ秒 ) + ( 9 * 3600000 ) ) / 1000 ) 
   
   
2. WD14 と WD15 の挙動の違い
   
   WD14 でレコードを作成したり、修正したりすると、FileMaker で記録されるユーザ名は [WebDirect] ですが、WD15 では [WebDirect-XXXXX]という形式でユーザ名が記録されます。
   
   この XXXXX の部分は WD 実行時のセッションID（32桁、16進数文字列）の最後の 5 桁となり、各 WD ユーザを識別しやすくなっているといえるでしょう。
   
   FileMaker Pro 15 のヘルプにもこの解説がありますので、興味のある方は参考にしてみてください。
   
   Get ( ユーザ名 ) の説明
   Get ( 持続 ID ) の説明
   
   

　その他の WebDirect 関連記事を読む

(亀)

API 別/サーバ別FileMaker カスタムWebパフォーマンス比較

 FileMaker で カスタムWeb を構築する場合、どの API が一番高速なのか、と疑問を持たれてきた開発者の方も多いかと思いますが、小社もその一員です＞＜。「FM社がバンドルしてるんだから FileMaker API for PHP なら、まぁ、間違いないだろう」位のノリでそれを採用してしまったりとか。FileMaker API for PHP（以下、FM API for PHP） や FX.php なら、ネット上の情報量も多いですし。
　そんな折、FM API for PHP を使用してWeb システムを構築していたわけですが、JMeter で想定される最大負荷をかけたところ、Web サーバがダウンしてしまうことがありました。　幸い、実運用ではそのような状況には今のところ陥っていないのですが、「これは一度、4つの API で比較テストしておこう」ということになり、今回、その運びとなりました。　また、同テストを FileMaker Server 12 と 15 でも実施しました。以下にその方法と結果を公開いたします。　1ユーザによる郵便番号データの検索と表示という限られたテストなのですが、多少なりとも参考になればウレシイかも、です。

1.　テスト方法

全国の郵便番号データを入れた FileMaker データベース（今回は弊社製品『FMEasy在庫』の郵便番号テーブル）を用意し、FileMaker Server 12 と 先月リリースされたばかりの FileMaker Server 15 でそれぞれ公開。
　このデータベースにアクセスして郵便データを検索するための簡単な php ページを作成しました。

　たとえば、FileMaker API for PHP で「北海道」を含む郵便データを検索するときのイメージはこのようになります。

検索実行中！

　そして下図が実行結果となります。
　FileMaker API for PHP による「北海道」郵便データ検索結果は 8242 件（データはかなり古いので、最新のデータでは違う結果が返ると思います）で、このレコードを取得してくるのに 2.9935 秒かかったことがわかります。

2.　テスト結果

FileMaker　Server 12 と 15 を使用し、それぞれのサーバ上で XML、FileMaker API for PHP、fx.php、POD(ODBC) の 4 種類の API を使って 10 回ずつ「北海道」の検索を実施しました。
　その測定結果は次の通りとなりました。

　FileMaker Server 12 と 15 のバージョン間の比較では、FileMaker Server 15 のパフォーマンスが約30% 良い結果となりました。

　パフォーマンス平均をグラフ化すると、このようになります。

API 別 FMS15 vs FMS 12 パフォーマンス比較

　次に、API の比較ですが、本テストに限っては、PDO が圧倒的に高速でした。北海道に属する全8242レコードの検索・描画の最高速は 0.938秒。　正直、FileMaker の ODBC を介したアクセスは使い物にならない、と過去の経験から思い込んでいたので（その記事がこちら）、この結果は驚きでした（FMさん、御免なさい r(￣_￣;)）。　また、2つの php ライブラリでは、FX.php がほんの少し有利で、php ライブラリと 生XML の比較では、生XML が約40% 高速となりました。


　php ライブラリは、Web プログラマにとって扱いやすいというのがメリットですが、処理が関数化されていることによって、その分サーバのパフォーマンスが相当程度犠牲になっているようです。
少ない人数の運用では何ら問題が無かったのに、ユーザ数が増えた途端に業務に支障をきたすようになった、みたいな時は、DBへのクエリやコードの見直しに加えて、XML や PDO への乗り換えも選択肢になるかもしれません。


参考サイト：
FileMaker×PHPで作る、簡単・便利なWebアプリ　― とっても力作なサイト

過去記事：
ODBC ドライバ DataDirect SequeLink を使って FileMaker Pro にアクセスしたときの問題点


（亀）

FileMaker 5.5/6 をモバイルで使う

　FileMaker 15 がリリースで盛り上がる？中、前回は FileMaker 5.5/6 って最高！という記事を書きました。

　開発サイドとしては、機能強化された最新の FileMaker を利用していただけると助かるのですが、コスト、対応デバイス、環境変更の手間等々の事情により、そう簡単にアップグレードできない企業・組織ユーザも多いのでは、と思われます。そうしたユーザの中には「現行の FileMaker システムは順調に稼働しているので苦労してアップグレードはしたくない。でも、モバイルでは利用したいよね」、みたいなところもあるのではないかと思います。

　そんなわけで、「この会社は一体何を考えているのか」という冷ややかな視線を感じつつ、今回は FileMaker 5.5/6 によるモバイル使用を試してみます。
　とは言いつつも、モバイル用のリモートデスクトップアプリを介してFM5.5/6を使用する、というだけなので、「なにを今さら」と思う方もいらっしゃると思います。小社でも以前、いくつかのリモート接続ツール（Remote とか iRdesktop とか iTapRDP ）を試してみて、「これでFMデータベース操作するのは厳しい」と思い込み、最近は完全ノーマークでした。ところが Microsoft 社からリリースされているモバイル用 Remote Desktop Client というアプリを恥ずかしながら最近知り、これならなんとか使えるかも、と思い始めた次第です。

注：
言わずもがなですが、iPhone/iPad 上のFileMaker Go を使用すれば FileMaker Server に直接接続できます。本稿は、FileMaker Go は利用できない、あるいは　Android やSurface で FileMaker を使用したいという方向けへの記事ともなっています。　

概要と準備するもの

　モバイル機器からの FileMaker データベース接続イメージはこのようになります。

モバイル機器による旧バージョン FileMaker データベース接続イメージ

　上記のように構成する場合は、以下の環境が必要となります。

　FMモバイルアクセス環境

1. FileMaker Server
2. FileMaker Pro アプリケーション（クライアント数分のライセンスが必要）
3. タブレットPCやスマートフォンなどのモバイル機器
4. リモートデスクトップサーバやVDI等の仮想デスクトップ環境（ここで FileMaker Pro を起動し、サーバにアクセス）
5. モバイル用Microsoft Remote Desktop（Android / iOS）

　FileMaker Server、FileMaker Pro、仮想デスクトップ環境（上記4）の各種設定の説明は省略しますが、　仮想デスクトップ環境では、下図のようにPC のプロパティより「リモートの設定」を選択してリモート接続を許可する点にご留意ください。

操作手順

　今回は FileMaker Server 5.5でデータベース（本例では、小社の旧商品「売上猫くん 4.5」（FileMaker 5.5/6対応）を公開し、仮想デスクトップ環境を介してAndroid タブレット PC （Nexus7）からアクセスする方法を順を追ってご紹介します。

1. タブレット PC に Microsoft Remote Desktop アプリをインストールします。
   
   Google Play を開き、MS Remote Desktop を検索し、インストールします。
   
   
   
   
   【iOS用の Microsoft Remote Desktop アプリ】
   
   iOS をご利用の方は、Apple ストアから Microsoft Remote Desktop アプリを入手してインストールすれば、同様に操作できるようになります。
   
   
2. RD Client アイコンをタップします。
   
   ホーム画面に RD Client アイコン（←Microsoft Remote Desktop のアイコン）が表示されますので、これをタップします。
   
   
   
3. リモートデスクトップ接続を追加します。
   
   Remote Desktop Client アプリが起動します。
   画面右上の＋アイコンをタップします。
   
   
   
4. Desktop を選択します。
   
   追加可能な項目の一覧が表示されますので、その中から Desktop を選択します。
   
   
5. リモートデスクトップ接続情報を入力します。
   
   表記はすべて英語となりますが、最低限接続先のPC名（または IP アドレス）とユーザ名を設定するだけでも接続できるようになります。
   
   下図では、フレンドリ名として nekodemo を入力していますが、これは必須ではありません。
   
   
   
   
6. 共有先の Windows PC に接続します。
   
   接続情報を保存すると、nekodemo という名前のアイコンが画面に追加されますので、これをタップします。
   
   
7. ログイン情報を入力します。
   
   共有先の PC に接続すると、ログインダイアログが表示されますので、Windows PC へのログイン情報を入力し、“Connect”ボタンをタップします。
   
   
   
   ※このアプリの仕様と思われますが、接続後の画面設定は縦置き表示ができないため、以降は、デバイスを横置きにした状態で操作を進めます。
8. マウスポインタをタッチパネルに切り替えます。
   
   ログインに成功すると、おなじみのリモートデスクトップ画面がモバイル PC 上に表示されます。
   
   
   
   画面上部のポインタ切り替えアイコンをタップします。すると、画面表示が以下のように変わります。
   
   画面右の“Touch”アイコンをタップすることによって、マウスポインタをタッチパネルモードに切り替えます。
   
   
9. ズームインモードに切り替えます。
   
   モバイル PC 上のリモートデスクトップ画面はとても文字が小さいという難点があります。
   リモート共有 PC側でフォントサイズを大きくしても、これは Remote Desktop アプリでは有効にならないため、文字サイズは小さいままとなります。
   
   ここで、ズームモードに切り替えて操作してみましょう。
   画面上部の虫眼鏡アイコンをタップします。
   
   すると、デスクトップがズームインされ、画面に十字矢印のアイコンが表示されます。
   
   
   
   この十字矢印に指を乗せて画面をなぞることによって、デスクトップの表示領域を移動します（多少の慣れが必要です）。
   以降、しらばらくはズームイン状態のまま操作します。
10. FileMaker 起動後、スクリーンキーボードを使って『売上猫くん4.5』にログインします。
    
    画面上の FileMaker Pro 5.5/6.0 アイコンを二回連続でタップすると、FileMaker Pro アプリケーションが起動します。
    共有ファイルより、『売上猫くん4.5』のメニューファイルを開きます。
    
    以下は FileMaker Server 5.5 で公開されている『売上猫くん4.5』のログイン画面が表示されたところです。
    [パスワード]入力ボックスをタップしてもスクリーンキーボードは表示されませんので、画面上部に配置されているスクリーンキーボードアイコンをタップします。
    
    
    
    スクリーンキーボードが表示されますので、パスワードを入力して Enter キーをタップしてログインします。
    
    
11. 『売上猫くん4.5』を操作してみます。
    
    リモートデスクトップ共有で『売上猫くん 4.5』を操作しているため、ご覧のようにファイルメーカー Pro のメニューバーは表示されたままの状態となります。
    
    
    
    “顧客（仕入先）”ボタンをタップすると、顧客仕入先画面が表示されます。
    ご覧のように、表示はモバイル PC 用に最適化されていないため、画面の一部が切れた状態となります。
    
    
    
    ここで、画面上部に表示されている虫眼鏡アイコンをタップすることにより、ズームイン状態を解除します。
    
    
    
    これにより、デスクトップ全体表示に戻ります。
    各画面の情報照会はズームインモード、一覧データを照会する際はデスクトップ全体表示にするなど工夫が必要かもしれません。
    
    （参考：住所録表示）
    
    
12. 日本語入力に切り替えて、テキストを入力します。
    
    Remote Desktop アプリケーションは、接続直後の入力モードは英語（EN）となります。
    日本語のテキストを入力するには、日本語入力モードに切り替えてから使用する必要があります。
    
    
    
    リモートデスクトップの右下に表示されている EN アイコンをタップし、JP （日本語）に切り替えます。
    
    そして、日本語を入力したい画面のテキストボックスをタップし、手順10.の要領で画面上のキーボードアイコンをタップしてスクリーンキーボードを呼び出します。
    
    このとき、お使いのモバイル PC によってはキーボードが英語のままになっているため、キーボード下部の English をタップすることによって、日本語キーボードに切り替えます。
    
    
    
    
    
    日本語入力をしてみましょう。以下は「てすとにゅうりょく」とローマ字打ちしてから、候補の中から「テスト入力」を選ぼうとしているところです。
    
    
    
    ご覧のように、[備考]フィールドに「テスト入力」と入力できました。
    
    

　以上、使い勝手はモバイルに最適化されたFileMaker Go にはかないませんが、モバイル版Microsoft Remote Desktop による FileMaker データベースの操作は、想像以上に快適に思いました。もともとリモートデスクトップはLAN上の仮想デスクトップで処理を行い、画面イメージのみをリモート端末に送るので高速です。また、モバイル機器に比べて、プリンタ等の周辺機器もPC同様に使用できるメリットもあります。
　種々の事情から FileMaker Go を利用できないユーザの方は、Microsoft Remote Desktop の利用を検討されてはいかがかと思います。

　時間があれば、旧FileMaker のアプリをモバイル用に無理やりカスタマイズしたらどのくらい操作性が向上するのか、とかも記事にしたいなぁと思っています。
　
　なお、セキュアなモバイル接続については、下記のページが参考になるかと思います。
　最終回　遠隔地のAndroid／iOS端末から社内PCにリモートデスクトップ接続する (1/2)


（亀）


参考リンク：
Microsoft Remote Desktop アプリダウンロードページ（Android）
Microsoft Remote Desktop アプリダウンロードページ（iOS）

リモート デスクトップアプリダウンロードページ（Windows）

■ FileMaker 5/6等レガシーシステム関連記事

まだまだいける FileMaker 5.5/6　― レガシーFileMaker の延命 2021 ―(21/07/24投稿)
レガシーFileMaker とOSの互換性、移行時の留意点について

IIS6 + FileMaker Web コンパニオン構成の Web サーバ機で TLS1.2 が動作するようにリバースプロキシを設定する (20/07/06投稿)
TLS1.2 非対応の IIS6 に Web ブラウザアクセス時に警告メッセージが出ないようにする

太古の FileMaker システムを延命させる！ ― 後日談FileMaker（17/09/07投稿）
下記記事のレガシー延命スキームの実施と結果について。

太古の FileMaker システムを延命させる！（17/04/25投稿）
Remote Desktop Server/FileMaker Pro 5.5 搭載の Windows Server 2008 物理マシンを P2Vし、Hyper-Vに移行することにより、レガシーシステムの延命を図る。

FileMaker 5.5/6 をモバイルで使う（16/05/25投稿）
Android/iOS に Remote Desktop Client を載せて、FileMaker Go のようなことをしてみます。

今なお輝くFileMaker 5.5/6（16/05/23投稿）
レガシーFileMaker の意外な利点。

今なお輝くFileMaker 5.5/6

FileMaker 5.5/6の環境を新サーバへ早急に移行する必要がある方へ

FileMakerのWindows OSとの互換性や注意点などをこちらの記事にまとめました。
(2021/07/25 NuckyT)

 今なお輝くFileMaker  5.5/6！　その理由は以下の通りです。

1. OS上位互換性

当社の経験上、FileMaker Pro 5.5/6（以下、FM5.5/6） は最新の Windows OS ― Windows 7/8/8.1/10で、FileMaker Server 5.5（以下、FMS5.5） は Windows Server 2008/2008R2/2012/2012R2 で動作します。また、FMP5.5/6 のマルチユーザライセンスを Windows Server のリモートデスクトップサーバ上に配置すれば、遠隔地からでも FMS5.5にアクセスして快適にFMを使用できます。
当社の取引先では、2台の Widnows Server 2008 を2008年に導入し、1台に FMS5.5 を、もう1台（Remote Desktop サービスライセンス×10ユーザ付）に FMP5.5(マルチユーザライセンス) をインストール。2016年5月現在、20ユーザがこのシステムを利用しています。
ちなみに、FM5.5のリリースが2001年。最終のアップデートがリリースされてから約15年が経過した2016年現在でも最新のOS上で普通に動作する FileMaker 5.5/6 は驚異的ですらあります。
（追記：2020年3月現在稼働中）

注：

•  2019年3月現在、当方及び取引先の Windows 10 機で FMP 5.5/6 が起動・動作することを確認しています。
• 当社ではブログのコメントにより寄せられるレガシー FileMaker の動作情報を歓迎致します。それらの情報は参考にさせて頂き、当ブログに反映させて頂くことがあります(19/3/13追記)。
• FMS5.5 は環境によっては問題が起こることもあります。当方で遭遇した現象としては、Dell PowerEdge T105 のハイパーバイザ上の仮想マシン（Windows Server 2012R2 ）では、 FMS5.5 は問題なく動作していましたが、PowerEdge R330 のハイパーバイザ上の仮想マシン（Windows Server 2012R2 ）に FMS5.5 を新規インストールした後にFMS の コンソールで「ファイルメーカー Server」を右クリックして「プロパティ」を選択するとコンソールがクラッシュする、ということがありました。　この時、正常稼働している PowerEdge T105 上 の仮想ディスク（VHD）を丸ごと PowerEdge R330 にコピーして仮想マシンを再構成したところ、コンソールで「プロパティ」を選択することができました。R330 上に新規インストールした FMS5.5 を動かすべくいろいろ試してみましたが成功せず。 本現象は両PowerEdge のビデオドライバの差異に起因するものかと疑っています。

Windows 10 上の FMP5.5 によりデータベースを起動

2. 低コスト性

これが第二の理由です。　どの位、システムの総コスト（TCO）が安いのか、FileMaker 15 の FLT との比較で試算した結果が下記です。

• FMP5.5@￥35000× 20ライセンス+FMS5.5 ￥130,000×1台＝￥830,000
• FileMaker 15 FLT　20ユーザライセンス）@￥285,000×15年＝￥4,275,000

何と FM5.5のコスト は FLTのそれに比し、 5分の1以下。これまた、驚異的です。今後、Windows 10 と Windows Server 2016でも安定運用できそうな予感が…。　そうなるともう10年はかるーく生き残りそうです。

［19/03/17追記］
2019年3月現在、当社環境では Windows 10 上の FMP5.5/6 により開発・運用を行っています。また、複数の取引先に納品した FMP5.5/6 及び FMS5.5 によるシステムが、Windows 10 を含む新しいOS上で稼働しています。 仮想マシンや P2V、Remote Desktop を使用すれば、今後10年以上、レガシーFileMaker によるシステムは運用可能と思われます。


3.高速性

最新の FileMaker は最新のマシンで起動させてもかなりモッサリ。 一方、FMP5.5/6 を最新のマシンで起動させた時の速いことと言ったら…　お暇なら古いPCと最新のPCで実行速度を比較してみてください。

FileMaker のOS互換性やFM製品間の互換性、さらにライセンスポリシーも迷走する昨今、機能的には遥かに劣る FM5.5/6 が輝いて見えます。　次回は、そんな  FM5.5/6 のアプリを iOS や Android で利用してみます。

そのアップグレード、ホントに必要？

 　FileMaker は Ver5.5/6 以降、様々なアップグレードがなされてきました。
大きいところでは、

• データベーススキーマの変更（アプリとデータの分離が可能に）
• イベントによるスクリプトトリガ
• データベース容量の拡張
• アカウント機能追加（スクリプトによるアカウントの新規作成・管理）
• マルチウインドウ対応とウインドウの制御
• サーバサイドスクリプト
• PDF出力
• ESSによるSQLデータソース（RDBMS）との連携
• WebDirect（FMアプリをそのままWebアプリ化）
• カスタムWeb機能の充実（XML/PHP/REST対応）
• iOS対応
• テーマ・スタイル/タブ機能等レイアウト機能の改善
• デバッガの改良

が挙げられます。現在、それぞれ重要な機能となっており、大きな恩恵を得ているユーザや開発者も多いでしょう。
一方、巷には、機能的なアップグレードを必要としない、或いはアップグレードが費用対効果に見合わないシステムが数多あります。 たとえば、NTT東日本の「ひかり電話設定サイト」（下図）、このサイトでは電話転送の設定を行うのですが、ここのユーザインタフェイスはこの10年程、ほとんどまったく変化がありません。

また、Googleの運営する Blogger　― 当ブログもこれを利用しています ―、このブログ投稿管理サイトも“ユーザインタフェイス”的には十数年、あまり変化がありません。

上記の2サイトは、ユーザサイドから見れば改善の余地がありますが、運営企業は「費用対効果が低い」、あるいは「プライオリティが低い」とみなしてか、少なくともユーザインタフェイスのアップグレードにはあまり熱心ではないようです。

かく言う小社も、顧客管理・請求書発行業務は「売上猫くん4.0」という FM4.0 で作成した自社システムを FM5.5 によりアップグレードし、一部簡単な機能を追加した後は、ほぼ20年間そのまま使用しており、今後も使用を続ける予定です。

FileMaker 5.5/6 で現在も稼働する小社の基幹「売上猫くん 4.0」

Amazonの通販サイトや AWS、 YouTube、Google Map、Google Analytics のように持続的なアップグレードが企業競争力と収益の源泉となるようなシステムは星の数ほど存在します。 一方、レガシーシステムであっても十分に役割を果し、今後も大規模なアップグレードを予定しないシステムも多く存在するのです。

本ページは現在でも多くのアクセスがあり、レガシーFMへの関心がいまだに高いことがうかがえます。システムをアップグレードするか、延命するかについては、業者やベンダーの情報を鵜呑みにせず、そのアプリの性質や将来像、費用対効果、双方のリスクを踏まえて意思決定するのがクレバーな企業なのだ、と思うのです。

(19/03/27追記　NuckyT)

（土屋）


追記
些細な変更にすらリスクは伴います。重要なシステムであればあるほど、そのまま使いたい。　アジャイルでリファクタリング…って何？　触らぬ神に祟りなし。
米軍の核兵器運用システムでいまだに8インチフロッピーディスクを使う理由について、ペンタゴンは「…現在も機能しているため」と言っています（米軍、核兵器運用に今も8インチフロッピー使用）。

2020/02/04 追記：
米軍、核ミサイル運用でのフロッピーディスク使用をようやく停止との報道
The US nuclear forces’ Dr. Strangelove-era messaging system finally got rid of its floppy disks （英語）
2019年にフロッピーディスクがようやく廃止されたとのことですが、約50年前のテクノロジーを延命運用できるとは、さすが米軍。

■ FileMaker 5/6等レガシーシステム関連記事

正月休み明け、仮想マシン上の FileMaker Server 5.5 バックアップが失敗していた(22/01/25投稿)
仮想マシンの外部ディスクでI/Oエラーが出た際の復旧方法

まだまだいける FileMaker 5.5/6　― レガシーFileMaker の延命 2021 ―(21/07/24投稿)
レガシーFileMaker とOSの互換性、移行時の留意点について

IIS6 + FileMaker Web コンパニオン構成の Web サーバ機で TLS1.2 が動作するようにリバースプロキシを設定する (20/07/06投稿)
TLS1.2 非対応の IIS6 に Web ブラウザアクセス時に警告メッセージが出ないようにする

太古の FileMaker システムを延命させる！ ― 後日談FileMaker（17/09/07投稿）
下記記事のレガシー延命スキームの実施と結果について。

太古の FileMaker システムを延命させる！（17/04/25投稿）
Remote Desktop Server/FileMaker Pro 5.5 搭載の Windows Server 2008 物理マシンを P2Vし、Hyper-Vに移行することにより、レガシーシステムの延命を図る。

FileMaker 5.5/6 をモバイルで使う（16/05/25投稿）
Android/iOS に Remote Desktop Client を載せて、FileMaker Go のようなことをしてみます。

今なお輝くFileMaker 5.5/6（16/05/23投稿）
レガシーFileMaker の意外な利点。

仮想マシン復旧メモ ― 次にやらかしたときのために

またやらかしてしまった...orz
最近退役したQNAPのiSCSI上にある仮想マシンに故あってアクセスしようとしたところアクセスできず、ping は返れどもブラウザからアクセスできない状態。　そこで、QNAP本体の正面にあるボタン（SELECT ― ENTER）を何気に数回押したところ、RAIDを再構成してしまった模様　ヽ(`Д´)ﾉ　
何たる不覚...

　ということで、バックアップから他のHypervisor上に回復することに。この機会（＝やらかした機会）に回復時のオプションを確認してみることにした。　以下、そのメモです。

Windows Server バックアップを進めると、以下の画面が表示される。



ここで、上図のように［Hyper-V］を選択して“次へ”をクリックすると、下図となる。



すべての仮想マシンを回復するには［Hyper-V］を選択すればいいのだが、特定の仮想マシンのみを復旧しようとすると、ご覧のごとくトホホな状態。回復が完了すると、回復先のフォルダの名称も同じくトホホな名称となるが、このトホホフォルダ内のVHD名（が適切に指定されていれば）からマシン名が特定できる。

ただ、そんなことをやっている暇はないので、「回復種類の選択」画面（冒頭の図）に戻り、［ボリューム］を選択し、“次へ”を押すと下図となる。



ご覧のように、オリジナルのボリュームに1対1で対応するように回復先のボリュームを用意しなければならない。　今回は、一つのボリュームに仮想マシンのC/E/Fドライブをまとめてしまうつもりなので、このオプションは見送る。

注：このオプションは、回復先のボリュームを初期化してしまうので、要注意。


で、結局、冒頭の画面に戻り、［ファイルおよびフォルダー］を選択し、“次へ”を押すと以下の画面。




仮想マシンを選んで、“回復”。　
元の仮想マシンはC/E/Fに分かれているのだが、このウィザードでは1回に1つのボリュームしか復旧できない（1つのボリューム内であれば、複数のファイル/フォルダ選択可）。


以下、回復操作を3回繰り返し、目的の仮想マシンのC/E/Fを回復、他のHypervisor上で仮想マシンを再構築し、無事起動することができた。

また、無駄な仕事をしてまった (ノД`)ハァ


（土屋）

参考サイト：
Windows Server 2012 R2 Hyper-V バックアップ／リストア設計・導入・運用ガイド

富士通の技術ドキュメントは何気に凄い。いつもお世話になってますm(,_,)m 

WakeMeOnLan

　遠隔地からネットワーク経由でマシンを起動するWakeOnLAN（WOL） ツールは無償のものが多数出回っていますが、今回はインストール不要で感覚的に操作できる　WakeMeOnLan　をご紹介します。

WakeMeOnLan ダウンロードサイト　ダウンロードリンクはこちら

　ツールは英語表記ですが、日本語ファイル（ダウンロード）を　WakeMeOnLan　と同じフォルダに入れれば日本語化されるのがいいですね。

　クライアントコンピュータの適当なところにダウンロードして解凍し、WakeMeOnLan.exe　を実行するだけの手軽さです(ﾟ∀ﾟ)。
　WakeMeOnLan　を起動した状態は以下のようになります。

　上図の赤で囲まれたスキャンボタンをクリックすると、同一ネットワーク上のコンピュータがスキャンされます。電源状態が不明なものも、電源が落ちているものもスキャンされます。

　稼働状態はアイコンで示されます。

　赤●　--- 電源が落ちている
　黄●　--- 電源状態は不明
　緑●　--- 稼働中



　リストより、起動したいコンピュータをマウスで右クリックすると、サブメニューが表示されますので、その中から「選択したコンピュータを起動(W)」を選択すると、コンピュータが起動されます。

　但し、コンピュータのネットワークカードが WakeOnLAN（WOL） 対応している必要があり、かつWOLが使用できる状態に設定されている必要があります。


（亀）