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 の意外な利点。

新WebDirectのパフォーマンスについてあれこれ

　FileMaker 13 の WebDirect (以下、WebDirect 13) と比べ、FileMaker 14 の WebDirect (以下、WebDirect 14) のパフォーマンスはどれだけ向上したのか？実用に耐えるレベルになったのか？
　WebDirect 14 の導入を検討するにあたり、これはとっても気になるところです。

　FileMaker 社の公式サイトでは、WebDirect の起動スピードは以前より 25% 向上していると謳ってはいます。また、独自にパフォーマンスの比較検証を行って公開している方（会社）もおいでで、そうした情報はとっても貴重です。

　ということで、パフォーマンスについて情報を公開している方の情報を例によって渉猟してみました。　（あと、人様の情報を紹介させて頂くだけでは申し訳ないので、弊社でも WebDirect のパフォーマンスの検証をしてみました。）

米国 FileMaker 社（パートナー）が公開している YouTube ビデオ

　かの有名な  Richard Carlton Consulting Inc. の FileMaker Training Videos Channel という動画です。

　WebDirect関連のビデオでは 「第一部：FileMaker WebDirect 14 のご紹介」、「第二部：WebDirect の最適化方」の 2 本が公開されていますが、その中からパフォーマンスに関する情報を拾って要約しました。

「第一部：FileMaker WebDirect 14 のご紹介」　Introduction to FileMaker WebDirect 14

　WebDirect がモバイル対応になったことを中心に、パフォーマンス面も向上していることについて触れています。

パフォーマンスに関する重要ポイント（リンクはタイムスタンプ）：

1. 11:30 今回のリリースで WebDirect の全面書き換えが行われたことにより、実行速度が格段に向上している。
2. 13:40 WebDirect 14 によるレコード移動時の表示速度デモ
3. 15:13 WebDirect 13 vs WebDirect 14 レコード移動速度比較
4. 16:54 WebDirect 14 のタブキー操作によるレイアウトフィールド移動は、WebDirect 13 に比べると 2倍は速くなっている。
5. 20:02 デスクトップ版 WebDirect 14 は、 WebDiredt 13 に比べると 2-3 倍動作が速い。Android モバイルに至っては 10-20 倍速くなっている！（WD13はAndroidには正規対応していないのですが、Richardさんは独自の方法でチェックされたようです。但し、この部分は動画にはありません。）。
6. 27:28 WebDirect は ChromeBook の動作保障をしていないが、自己検証ではサクサク動いた。

（動画は英語）

　

　特に　15:13 あたりの WebDirect 13 vs WebDirect 14 レコード移動速度比較実験は必見！
　ウィンドウを左右に並べて比較しているので、速度が向上していることは一目瞭然にわかります。

「第二部：WebDirect の最適化」　Optimaizing Solutions for FileMaker WebDirect 14 

　2013年の Richard Carlton Consulting Inc. の FileMaker 13 WebDirect Overview and Optimization Presentation と基本的な流れは同じですが、 WebDirect 14 に関する情報にも触れられています。

パフォーマンスに関する重要ポイント（リンクはタイムスタンプ）：

1. 17:55 *.fp7 ファイルを  FileMaker Pro 14 フォーマット(*.fmp12) に変換した直後のレイアウトサイズは 850kb。
   これを予め登録した共有スタイルで最適化させると 425kb までサイズダウン。
   サイズが約半分ということは、転送速度が約2倍になっているといえる。
2. 18:49 FileMaker Pro 14 に付属のストーンテーマのスタイルを極力いじらずに同様のレイアウトを作成した場合は、225kb までスリム化できた。
3. 19:55 WebDirect 13 で共有スタイルで最適化したレイアウトサイズは 480kb だったが、 WebDirect 14 で同様の作業を行うと 425kb で、 約15% スリム化されていることがわかった。

（動画は英語）

 　今回は WebDirect のパフォーマンス比較がわかるところのみを中心にご紹介していますが、ビデオの中では以下のようなことにも触れています。

WebDirect 13 の最適化ビデオと重なる情報は省いてあります。より詳しい情報をご覧になりたい方は、FileMaker 13 WebDirect Overview and Optimization （英語）をご覧いただくか、弊社記事 WebDirect 開発の勘どころ をご覧ください。

画像について 

　ｊpeg, png などの画像利用は最小限にする。
　FileMaker Pro 14 には軽量の SVG ビルトイン画像（glyph）が用意されているので、これを使ってボタンアイコンを装飾することを検討。
　※SVG = スケーラブル・ベクター・グラフィックス

タブ・スライドコントロールについて

　タブ、スライドコントロールの使用もできるだけ避ける。
　必要のない情報をロードさせないのが基本。
　タブコントロールを配置するれば、裏でタブ上のすべての情報がロードされることに注意。

ポップオーバーについて

　FMP13 で導入されたポップオーバーも要注意。
　ブラウザに別ウィンドウを表示させる代わりに使えるが、多用は避けること。
　裏であらかじめすべてのポップオーバーデータをロードすることには変わりはない。

スクリプトトリガについて

　WebDirect 側にはスクリプトエンジンが搭載されていない。
　このため、イベントが発生するたびに FileMaker Server にアクセスして処理を決定する。
　当然、スクリプトをトリガさせるイベントがたびたび発生すれば、その分のトラフィックが増加する。
　このトラフィックコストはできるだけ少なくした方がよい。

FileMaker WebDirect 14 のパフォーマンス最適化については、「FileMaker 14 WebDirect ガイド」の 14 ページ「ステップ 3: パフォーマンスの最適化」（PDF）にヒントが掲載されています。こちらも併せて読むと、参考になると思います。

---

土屋企画による WebDirect パフォーマンス検証

 

 小社でも『FMEasy在庫 IWP/WD R1.5』 という製品を使い、社外と社内の2つのサーバでテストをしていました。

■実行環境
社外：米国某ホスティングサービス(VM/共用タイプ)、16 GB RAM/Xeon E5 4 cores
社内：自社サーバ（VM/占有タイプ）、4GB RAM/core i7（4プロセッサ割り当て）
FileMaker Server： Ver14.0.2（サーバ1/サーバ2共に）
使用ブラウザ：主としてIE10、IE11
注：VM＝仮想マシン

■テスト内容
　予め、連続ビュー、連続更新、出庫伝連続伝票作成、という3つのループスクリプト（後述）作っておき、5～10個のブラウザウインドウからこれらのスクリプトを実行しています。
　で、こんな感じになります。

　上図は、1台のPC上で10個のIE10ブラウザウインドウを開き、ループスクリプトを実行していますが、Remote Desktop （RDT）で複数のセッションを開き、それぞれのセッションで1～複数のブラウザウインドウを開いてループスクリプトを実行というテストも行っています。
　後述の「■テスト」の項では、＜社内/1PC/複数ブラウザ＞、＜社外/複数RDT/1ブラウザ＞などと表記しますが、前者は社内サーバに1台のPCから複数のブラウザウインドウを起動しアクセス・テスト、後者は社外サーバに複数のRemote Desk Top から1つのブラウザウインドウを起動してアクセス・テスト、を表しています。

■ループスクリプトの内容
1. 連続ビュー
上図の出庫画面で先頭レコードから1件づつ後方へ移動していく。移動直後に0.2～1秒ポーズし、50～100件目に到達したらメッセージを出して終了する。

2.連続更新
上記の連続ビューと基本は同じだが、移動直後に備考フィールドに実行時の日時を追記する。

3.連続伝票作成（クライアントサイド）
出庫伝票形式のデータを連続して100件作る。といっても、1出庫レコードには25の出庫明細レコードが付属しているので、このスクリプトを1回実行すると、出庫レコード100件+出庫明細レコード2500（25明細×100）件、計2600のレコードが作成される。

4.連続伝票作成（サーバサイド）
仕様は上記4同じだが、サーバサイドスクリプトで実行。

■テスト
1.連続ビュー　＜社外/1PC/複数ブラウザ＞
10個のIE10ブラウザウインドウで連続ビューを実行し、すべてのブラウザでエラーなく成功。


以下の動画は、撮影の都合上、6つのブラウザで実行しています。

2.連続更新
2-1　 連続更新　＜社外/1PC/複数ブラウザ＞
10個のIE10ブラウザウインドウで連続更新を実行し、全てで成功。但し、上記1よりは時間がかかる。

2-2　連続更新による影響　 ＜社外/複数RDT/1ブラウザ＞
6つのRDTで1つのブラウザを起動し、それぞれで連続更新スクリプトを実行させた後、ローカルでブラウザを起動し、テスト実行者が手動によりレコード移動や入力を行いました。　これは、他のユーザが入力作業をしていると、どのような影響を受けるかシミュレートしたものです。結果は以下の通りです。

• 6つのRDTの連続更新は時間はかかるもの成功します。
• ローカルのブラウザでは入力は成功するものの 、レコード移動ボタン（＞アイコン）を数回クリックすると、サークルアイコンが現れ操作ができなくなる現象が頻発します。数分待つと画面が表示されますが、これでは実用に耐えないレベルです。　
  

2-3　連続更新による影響　 ＜社内/複数RDT/1ブラウザ ＞
上述の2-2 と同様テスト内容を 社内サーバで実行したときの模様です。

• 今回は、ローカルで新規レコード入力操作中にサークルアイコンが現れ、その後 15 分経過しても状況が変わらなかったため、テストを中断しました。
• このサークルアイコンが現われ操作不能になる現象は今回のループテスト実行中に何回も発生しました。　サーバ性能を上げるとこの現象は緩和されるのかもしれませんが、性能を上げたとしても FileMaker Pro 並みの安定運用を行うのは厳しいのではないかと思われます。　

2-4　連続更新を24セッションで実行 ＜社内/複数RDT/複数ブラウザ ＞
4つの RDTクライアントでそれぞれ5つのIE10ブラウザウインドウを開き、さらにローカルで4つのIEブラウザウインドウを開いて（計24セッション＝4×5+4）て連続更新スクリプトを実行。成功したのは24セッション中9、残りの15セッションはサークルアイコンが出現し制御不能に。

3.連続伝票作成（クライアントサイド） 　＜社外/1PC/1ブラウザ＞
1つのIE10ブラウザウインドウで成功。所要時間は43秒。但し、再度実行すると、ブラウザが反応しなくなる（下図）。

4. .連続伝票作成（サーバサイド）　＜社外/1PC/1or 5ブラウザ＞

1つのIE10ブラウザウインドウで数秒で成功。但し、実行直後から全くブラウザが反応（上図と同様）しなくなることがある。
バグを修正したところ、上記打消し線部の問題は解消。　5つのブラウザウインドウ上で本スクリプトを同時実行したところ正常終了。さらに、続けて5つのブラウザで同スクリプトを実行したところ、こちらも問題なく終了。
※バッチ処理は実行速度と安定性から、利用可能であればサーバサイドスクリプトを利用するのが良い

※　今回のテストを通じて思ったこと　―　WebDirect導入時の注意点

1. 複数のブラウザでループスクリプトを実行しても（動作は遅くても）比較的に安定して動作する。
2. ユーザが ＜ や ＞ （レコード間移動）ボタンを手動で実行すると、サークルアイコンが延々と表示され、場合によっては操作不能になことがある。 ＜ や ＞　を連続押しすると、この現象は高い頻度で発生する。
3. レコードの連続作成スクリプトをクライアントサイドで実行すると、そのスクリプトは正常に終了したにも関わらず、次の操作が不能になる（サークルアイコンが出っ放し状態）になることがある。
4. サーバサイドスクリプトが実行できる状況であれば、使う

上述のように上記のテストは海外のサーバを使用して行っていることにご注意ください。上記2の現象に関し、WinMTR の結果をホスティング会社に送付し問い合せたところ、「some severe packet loss and latency from you location in Japan to our location」とのことでした。　ただ、サークルアイコン出っ放し状態の時でも、FileMaker Pro によりサーバにアクセスして ＜ あるい ＞ をクリックすると、速度は遅いものの正常に動作すること、社内サーバを使用してもサーバへの負荷を高めるとサークルアイコン出っぱなし現象が発生することからみて、WebDirect にはまだ問題があると思います。
　尚、小社のLAN内のWebDirect環境では、ブラウザの　＞ または ＜ 　ボタンを連続押ししても、上記の問題は発生していません。  

　以上のことから、WebDirect の導入に際しては、サーバ性能（メモリ/CPU）に加え、ネットワーク環境にも十分注意を払う必要があります。実際の運用環境にできるだけ近い環境を用意し、事前に十分なテストを行うことも必要でしょう。　またテストを行う際も精度の高いプロトタイプを用意し、十分な実行速度が確保できるかもチェックしたいところです。ブラウザ上の ＜ と ＞ （ナビボタン）を非表示にしたり、短い間隔で連続実行できないようにするなどの工夫も必要かもしれません。　導入担当者または開発者は、サークルアイコンの地雷を踏まぬよう、十分注意しましょう。

注：
「社内サーバのスペックが低すぎるのがサークルアイコンの原因だろ？」とお思いの各位、御尤もです。メモリたっぷりなサーバを調達してテストしてみたいです。　ただ、サーバ性能が低いにしても、サークルアイコン出っぱなしはオカシイと思います。

---

WebDirect のパフォーマンスに関するその他の情報

　バージョン間での WebDirect パフォーマンス比較を実際に行っている開発者は残念ながらまだ少ないようです（公式サイトの 25% 速度アップについて言及していらっしゃる方は多いでのですが）。

　そんな中、米国の FileMaker Forum ではいくつかのスレッドで WebDirect のパフォーマンスに関する情報がみつかりました。
　リンク先は英語ですが、スレッドの紹介程度に要約を載せておきます。

1. FileMaker Server 14 & WebDirect Performance

　NickLightbody という方が WebDirect 1ユーザあたりの消費メモリを計測して表にされています。
　こちらのスレッドでは、3 WebDirect ユーザ の場合は 100MB の RAM　を消費し、 30 ユーザでは 1 GB の RAM を消費することを挙げたうえで、独自の計測結果も公開されているのでとても参考になります。　すばらしい！　＼(＾o＾)／

2. FMS 14 WebDirect Performance?

　WebDirect 14にアクセスしたところ、ロード中のアイコンが出っぱなしになり、10～20 秒後にログイン画面に戻ってしまうという現象が発生。

　ちなみに、当方でも同じ現象に遭遇したことがあります。
　ホスティング会社にこの件について問い合わせたところ、FileMaker Server 13 から発生している既知の現象で、この現象が発生した場合は、FileMaker Server を再起動しないとどうにもならないとのことでした。
　また、この現象はいまのところ FileMaker Server 14 でも発生しているので、今後のアップデートが望まれるところです。　早く出さんかいヽ(`Д´)ﾉ

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

（亀）

WebDirectの導入事例を渉猟す

　WebDirect の導入に際してやはり気になるのは先行する導入事例。　
　小社でも時たま導入事例の紹介記事を探していますが、記事は多くありません。

　FileMaker 13 の WebDirect は、FileMaker Pro レイアウトのレンダリングが魅力的である反面、動作条件の厳しさ（高スペックなハードウェアの要求）、デザイン時に考慮すべき点の多さ、実行速度の問題など、機能的にはまだまだ発展途上という感じでした（これらの問題については、WebDirect 開発の勘どころ　をご参照ください。）


　そんな折、2015年5月13日に FileMaker 14 が発売になりましたが、やはり WebDirect の進化に注目が集まるっているようですね。

　ということで、小社では改めてWebDirect(WD)の導入事例を探してみました。
　以下は見つかった記事の要約、編訳となります。　

※WebDirectが2013年12月にお目見えしてから1年半。まだまだ導入事例は少ない感じです。Ver14で状況は変わるのでしょうか。

【WebDirect の導入事例】

1. Braun Electric Company, Inc. （米国カリフォルニア州）

　電設会社。
　435人以上の従業員の安全を FileMaker Go for iPad/iPhone で管理。
　SeedCode 社の GoMaps プラグインを併用し、従業員の現在地を GoogleMap で確認。

　今後は複数の業務処理の自動化に向けて、WebDirect を導入していく“予定”とのこと（予定なんで、これ、全然導入事例ではないです。GoMapsがCooｌそうなんで、思わず載せました。すみません）。

　参照元：http://www.filemaker.com/solutions/customers/stories/braun-electric-company.html　
　参考リンク：　GoMaps プラグイン（英語）

2. Annex Medical, Inc. （米国ミネソタ州）

 　医療用精密機器製造会社。
　従業員数 20人。
　社内のシステムを FileMaker Go for iPad でフル活用。
　品質記録、検品、工数管理、原料管理、在庫管理、配送、送り状作成までをトータルに行っている。

　作業効率化のためにダッシュボードをWebDirect で公開し、従業員の作業工数をチェックできるようになっている。 

　参照元：http://www.filemaker.com/solutions/customers/stories/annex-medical-inc.html

3. Cure Kids (ニュージーランド・オークランド)

　児童健康研究所。

　乳幼児突然死のリスク計算アプリを WebDirect メインで開発。

　データ入力を行うと、瞬時に死亡率のリスク計算ができるところがウリ。　
　開発期間が数週間だったにもかかわらず、ここ一年間で大きな修正はない。
　今後はカスタム開発を行い、ソリューションを完全レスポンシブな Web アプリケーションに発展させる予定（うーん、このWDソルーションはCWPソルーションに置き換わるのか。　WDで超高速開発して急場を凌だり、あるいはWDでプロトタイプを作成してエンドユーザに試用してもらう。で、本番システムはCWPで開発、みたいな）。

　参照元：http://www.teamdf.com/work/cure-kids
　開発元：http://www.teamdf.com/

---

【WebDirect 導入の具体例を示しているエンドユーザ】

1. Beko BBL　（ドイツ・ケルン）

　プロバスケットボールリーグ。
　32 人の審判と 10 人のスタッフ監督で運用中。

　全国バスケットボールリーグの所属審判を WebDirect および FileMaker Go で管理。

　（動画はドイツ語）

　
　スケジュール、評価、目標達成度、その他要素を含むすべての関連データを iPhone またはiPad で審判に公開。
　審判は、どこにいても iPhone または iPad を使い、 WebDirect　や FileMaker Go 経由でシステムにアクセスしてデータ入力可能。
　
　一元管理された目標達成やその他要素を含む情報は、リーグ管理者および審判が人選に利用。

　FileMaker プラットフォームで審判データベースを開発することにより、人材管理を実現。
　所在地情報をはじめ、年間出場試合数、身体データ、資格情報、関連情報、一般・技術審判の区分などを含む試合関連情報に関する個人データを管理。

　参照元：http://www.filemaker.com/de/solutions/customers/stories/bbl.html　

2. Akubra Hats （オーストラリア・ニューサウスウェールズ州）

　服飾品製造業。
　
　生産管理・受注管理に会計パッケージを統合させたシステムを FileMaker プラットフォームで開発。
　新たに導入されたレポート機能によって、季節ごとの商品在庫レベルを把握しやすくなり、在庫回転率が向上。
　早期受注にも対応でき、受注状況の確定も迅速化。

　システム導入後、一年間で受注レコード 2万件（受注明細レコード数 25万件、関連サイズ別レコードも含めると 56万件）を管理。
　工場および事務処理の一日 20 時間相当の業務をこのシステムで実現。
　今後のシステム最適化により、さらなる業務効率化が期待される。

　FileMaker Go と FileMaker WebDirect の併用により、モバイル顧客および遠隔顧客のニーズにも対応。
　また、2015 年の小売業者向けオンライン受注システム導入に向けて WebDirect によるモジュールをテスト運用中。


　参照元：http://www.filemaker.com/au/solutions/customers/local_stories/akubra-hats.html
　

3. サンラモン市街化区域（スペイン）

　都市開発事業。

　マドリードの民間開発区域、サンラモン市の 2000人の居住者を、18人の従業員により24時間体制で監視するシステムを運用。
　一日 3 シフト制でサンラモン市内を監視。
　訪問者・車両登録処理を含め、地域の安全を目指すのが基本目的。
　
　FileMaker Go および WebDirect によるアクセス。

　email を利用した居住者自宅訪問の実現。
　FileMaker Go for iPad を使ったレコード承認、訪問スケジュール管理
　WebDirect を使った居住者データベース管理
　
　より安全でシンプルな承認作業と堅牢なアクセス管理を実現。

　居住者に公開しているデータベースは二種類。
　居住者連絡先詳細データベースは地域事務所が WebDirect を使って更新。
　登録車両情報データベースは居住者自身が編集可能。

　訪問者がある場合は、e-mail または SMS で訪問者情報を監視員に送信。
　これにより 訪問者登録に要する時間を98% 削減。

　FileMaker Go for iPad による訪問者登録処理が可能になり、業務が簡略化されるとともにセキュリティログの記録量が 300% 増加。


　参照元：http://www.filemaker.com/es/solutions/customers/local_stories/Ciudad_San_Ramon.html

---

【WebDirect を使ったソリューションを提供している業者の開発例】

1. Contraflow （オーストラリア）

　道路交通網関連団体の計画作業と管理サービスを提供するシステムを構築。
　150人の従業員による内勤作業・オンサイト作業の両方に対応したあらゆる管理業務向けのソリューション。

　25 人の FileMaker Pro ユーザ、80人の FileMaker Go ユーザ、関連会社 5 社による WebDirect アクセスによりシステムを運用。

　【導入効果】
　コンプライアンスと安全性の向上、監査時不適合案件の減少、
　ワークフローのペーパーレス化。即時更新、各ステージの時間短縮、
　カオス化の完全排除、効率化されたプロセス、　自動 SMS 送信により電話による通話を廃止
　拠点呼び出しの時間と労力の削減、給与計算の自動化
　回転率の予測作業の迅速化と単純化、人員管理、必要車両とVIP 客の特定


参照元： http://info2.filemaker.com/Contraflow_Contraflow.html

2. SeedCode Calendar for WebDirect　（米国）

　WebDirect 対応の FileMaker Pro 向けカレンダープラグイン。
　カレンダーの週間表示、月間表示、　テーマ切替、ガントチャート表示などに対応。

（動画は英語）

　その他詳細は SeedCode 社の製品ページをご参照ください。
　SeedCode Calendar for WebDirect

弊社でも FileMaker 13 版 WebDirect 対応の在庫管理テンプレート製品『FMEasy在庫IWP/WD R1.5』を販売しております。

FMEasy在庫 IWP/WD R1.5 製品紹介ページはこちら
 
※この動画には WebDirect の動画部分は含まれていませんm( _ _ )m　インスタントWeb（IWP）の動画となっております。　14も出たことだし、WD部分の動画も作ろうか、と思う今日この頃です。
 　

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

(亀)

ファイル起動時にFileMakerからMySQLに投げられるクエリ

FileMaker Pro をフロントエンド、MySQLを バックエンドにしたアプリを起動する時には、以下のようなクエリが投げられるんですね。　
（FileMaker Pro 13使用時）

SET NAMES utf8　［参考URL］

SET NAMES indicates what character set the client will use to send SQL statements to the server. Thus, SET NAMES 'cp1251' tells the server, “future incoming messages from this client are in character set cp1251.” It also specifies the character set that the server should use for sending results back to the client.

A SET NAMES 'charset_name' statement is equivalent to these three statements:

SET character_set_client = charset_name;
SET character_set_results = charset_name;←A
SET character_set_connection = charset_name; 

SET character_set_results = NULL　［参考URL］

If you want the server to perform no conversion of result sets or error messages, set character_set_results to NULL or binary: 

SET SQL_AUTO_IS_NULL = 0　［参考URL］

If this variable is set to 1 (the default), then after a statement that successfully inserts an automatically generated AUTO_INCREMENT value, you can find that value by issuing a statement of the following form:

SELECT * FROM tbl_name WHERE auto_col IS NULL

If the statement returns a row, the value returned is the same as if you invoked the LAST_INSERT_ID() function.

つまり、INSERT直後、 AUTO_INCREMENT値は存在するにもかかわらず、IS NULL として認識されるというもろ刃の剣。

SET AUTOCOMMIT=0　 [参考URL]

The autocommit mode. If set to 1, all changes to a table take effect immediately. If set to 0, you must use COMMIT to accept a transaction or ROLLBACK to cancel it. By default, client connections begin with autocommit set to 1. If you change autocommit mode from 0 to 1, MySQL performs an automatic COMMIT of any open transaction.

set @@sql_select_limit=DEFAULT 　［参考URL］

The maximum number of rows to return from SELECT statements. The default value for a new connection is the maximum number of rows that the server allows per table, which depends on the server configuration and may be affected if the server build was configured with --with-big-tables. Typical default values are (2³²)–1 or (2⁶⁴)–1. If you have changed the limit, the default value can be restored by assigning a value of DEFAULT.
If a SELECT has a LIMIT clause, the LIMIT takes precedence over the value of sql_select_limit.
sql_select_limit does not apply to SELECT statements executed within stored routines. It also does not apply to SELECT statements that do not produce a result set to be returned to the client. These include SELECT statements in subqueries, CREATE TABLE ... SELECT, and INSERT INTO ... SELECT.　
※うちのDEFAULTは、 (2⁶⁴)–1=18446744073709551615　でした。こんなん返されても困るわ。

SET SQL_MODE='STRICT_ALL_TABLES'　［参考URL］

For transactional tables, an error occurs for invalid or missing values in a data-change statement when either STRICT_ALL_TABLES or STRICT_TRANS_TABLES is enabled. The statement is aborted and rolled back.

SELECT TABLE_NAME, TABLE_COMMENT, TABLE_TYPE, TABLE_SCHEMA FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA LIKE 'easyinv15' AND ( TABLE_TYPE='BASE TABLE' OR TABLE_TYPE='VIEW' ) AND TABLE_NAME LIKE '郵便番号'

INFORMATION_SCHEMA から、アプリで使用さているビューを含むテーブル情報を取得。

select database()

接続中のデータベース名を返す

describe `郵便番号`

当該テーブルのコラム情報を取得

SHOW KEYS FROM `easyinv15`.`郵便番号`

プライマリ等キー情報を取得、Cardinality ってここにあるのね。


SELECT TABLE NAME ～　から SHOW KEYS ～　（イタリック部）は、FileMaker ファイル内に登録されたすべてのMySQLシャドウテーブル（ビュー含む）に対して実行される（ｷﾘｯ


（土屋） 

Big Table Handling Model in FileMaker/MySQL Environment ― Tentative one

The ordinary FileMaker development model may be not effective for handling big SQL tables.
In this post, we will try to find out clues for handling big tables at a tolerable speed while avoiding the weird application behavior that is unique to SQL big tables.

Definition of terms

Big tables: MySQL tables with more than 10 mil. rows
FileMaker/MySQL development: development using FileMaker for frontend, MySQL for backend
Filemaker-alone development: development using FileMaker for both frontend and backend

Problems of FileMaker's common interface

FileMaker provides the common interface for both FileMaker-alone development and FileMaker/MySQL development, which make it possible that developers can use the almost same method in FileMaker/MySQL development as in FileMaker-alone development.

This is very nice, but as data of MySQL tables grow up, application users will notice a performance slowdown, the application's behavior will become so weird (FileMaker issues a lot of redundant and incomprehensible SQL queries), and operation may become almost impossible.

The following model is a tentative one for mitigating such problems:

Big Table handling model in FileMaker/MySQL Environment

The figure below illustrates how to handle database objects.
.

1. On MySQL, duplicate big tables and rename them as rpl_originalTableName which are used for replicating records SELECTed by users from original big tables.
2. In FileMaker relationship graph, place only small tables and Rpl. Tables (do NOT place any big tables as it causes slowdown).
3.  Create stored procedures in MySQL to SELECT records in big tables and replicate them to Rpl. Tables, and INSERT/DELETE/UPDATE them whenever related records in Rpl.Table are inserted, deleted or updated. The stored procedures are executed from FileMaker's layout.

Common Model vs Big Table Handling Model

The following table indicates the comparison of the common model which is commonly used in FileMaker application development and the Big Table Handling Model(BTHM) based on the figure above.

	Common Model	BTHM	Remarks
Fast development	Yes	No
Ease of operation	Good	No so good
Performance for big tables	Very poor	Good
Weird behaviors	Many	Minimum
Records order	Weird	OK	Maybe detailed later

Note:
BTHM may not be appropriate for the found set of over 0.1 million, and may not be appropriate for the large number of simultaneous users.



The above two models plus 1 are illustrated in the following video.





N. Tsuchiya

『FMEasy在庫』 のバックエンドを MySQL に変える（２） ― 在庫

　本稿では、リリース予定の『FMEasy在庫 on MySQL R1.5』（仮称）の商品画面の在庫に関して説明いたします。

　以下が商品画面となります。

　『FMEasy在庫 on MySQL R1.5』では、2つの方法で在庫を算出します。
　一つは「SQL Update方式」、もう一つは「FM計算方式」です。

　それではそれぞれに関して説明します。

SQL Update方式

※特徴
　この方式は“実行”ボタンをクリックすることにより、［在庫基準日］時点の全商品の在庫数を算出して記録します（技術仕様的には、入庫数計/出庫数計/在庫数を「upd在庫」という専用テーブルに記録します）。

　一旦記録されたデータは次に“実行”ボタンを実行するまで更新されません。
したがって、“実行”ボタンクリック時点には最新情報ですが、時間が経過するに従い、最新の在庫数とは異なる可能性が高くなります。

　“実行”ボタンクリック時に入出庫データが大量にある場合、処理に数秒～数十秒、1千万件を超えるような場合は数分かかる可能性がありますが、処理が終了してしまえば即座に数値を表示・印刷できます。
　「SQL Update方式」は、在庫表などで在庫情報をリスト形式で表示・印刷する場合、高速に処理することができます。

注：
　本機能はクライアント/サーバ環境に置いて、FileMaker ServerにODBC設定がされていれば、FileMakerクライアントにはODBCのインストール/設定は不要です。

※操作方法
　実行ボタン　―　任意の［在庫基準日］を指定して本ボタンを実行すると、［在庫基準日］時点の入庫数/出庫数/在庫数が算出・記録されます。

　当方のクライアント/サーバ環境下で、入出明細レコード170万件に対してこの処理を実行すると、30秒～1分程度の時間を要します。

　作成済在庫データ選択ウインドウ（FileMaker 13使用時のみ）　―　実行ボタン右横の黄色の部分をクリックすると、小さなウインドウ（下図）が表示されます。この時、プルダウンメニューをクリックすると、他のユーザ（アカウント）が作成した在庫データの一覧が表示されるので、ここでその内の一つを選択すると、以後、「SQL Update方式」には選択したアカウントが作成した在庫データが表示されます。

他のアカウント(admin/seminar/stockchecker)が作成した在庫データを照会できる。
アカウント右側の日付は、データ作成時に指定した［在庫基準日］

注：
　各ユーザ（アカウント）は［在庫基準日］を指定して“更新”ボタンを実行することにより、全商品の在庫データを作成・記録できます。
同アカウントが次に“更新”ボタンを実行すると、前回作成した在庫データは上書きされます。例えば、admin アカウント で［在庫基準日］に「2014/11/27」と指定して本ボタンを実行すると、全商品に対して［在庫基準日］時点の在庫データが作成されますが、次に adminアカウントが「2015/12/31」を指定して同操作を実行すると、「2014/11/27」時点のデータは上書きされます。

　尚、他のアカウントが作成した在庫データは上述の通り照会することはできますが、別のアカウントで上書きすることはできません。例えば、adminアカウントでログインしている場合、seminar が作成した在庫データの照会はできても、上書きすることはできません。

FM計算方式

※特徴
　この方式は旧来のFileMakerの計算式を使用した在庫算出方法（参考記事）です。この方法のメリットは、常時最新の在庫情報を表示される点です（下記注参照）。

　ディメリットは、入出庫明細にデータが多量にある場合、在庫情報の表示に時間がかかることがある点です。 例えば、入出明細レコードが170万件あり商品Aを含むレコードがその中に2万9千件ある場合、当方の低SPECなクライアント/サーバ環境下では商品Aの［在庫数］を算出するのに5秒強程かかります。

　商品画面で個々の商品情報を一つ一つ計算・表示する場合はまだいいのですが、複数の商品の［在庫数］をリスト形式で表示する場合はかなりのストレスを感じます。

注：
　ネットワーク上の他ユーザが照会中の商品の入出庫データを追加・更新した場合、“画面更新”をクリックすると、最新の在庫情報が表示されます。

※操作方法
　計算するチェックボックス　―　チェックすると「FM計算方式」の在庫情報が表示されます。チェックを外すと在庫情報の計算を行わないので、画面表示が高速になります。

　尚、「FM計算方式」の出庫数計/入庫数計/在庫数のフィールドをレイアウト上に配置するだけで、システム起動後に初めて商品レイアウトを開く際に時間がかかります。
入出明細に170万件のレコードがある場合、当方の環境下では、1分前後の時間を要します。

　この詳しい理由については割愛しますが、簡単に言うと入出明細テーブルのビューに対して、DISTINCT句を含むクエリを発するためです。
「FM計算方式」が不要であればこれらの3フィールドはレイアウト上から削除して構いません。

　その他の在庫関連記事を読む

以上

『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(2) ―― 在庫誤差調整伝票の作成

　前回の記事では、iPad のバーコード読み取りによる棚卸入力機能を実装するところまでをご紹介しました。

　『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(1) ―― 棚卸入力を実装する

　棚卸作業をしてみると、システム上の在庫数と、棚卸在庫数（実在庫）が一致しない　―　誤差がでる ― ことはよくあることです。

FMEasy在庫 R1.0/R1.5 に在庫誤差調整伝票作成機能を実装する

　今回は『FMEasy在庫 R1.0/R1.5』をカスタマイズし、入庫/出庫の調整伝票を作成することにより在庫誤差調整を行う機能の作成方法をご説明します。

　前回と同様、以下の用語を使っていきます。

【用語解説】

在庫数　―　システム上の在庫数。『FMEasy在庫 R1.0/1.5』で入出庫登録を行った結果、算出・表示される商品画面上の［在庫数］。以下の［棚卸在庫］とは異なる可能性がある

棚卸在庫　―　実際の存在する商品の在庫数、または『FMEasy在庫 R1.0/1.5』に入力されたその値。システム上の在庫数（=［在庫数］）とは異なる可能性がある

棚卸　―　 実際に存在する商品の数を（カスタマイズ後の）『FMEasy在庫 R1.0/1.5』に入力すること

在庫誤差調整　―　 「システム上の在庫数」と「棚卸在庫」の誤差を入庫/出庫の調整伝票を作成することにより修正すること、またはその機能

　それでは、こちらの動画をご覧いただいたあとで、実際のカスタマイズ方法をご紹介します。

【開発レベル】
中級（レイアウト修正、テーブル修正、スクリプト修正について理解している）

【用意するもの】
1. 『FMEasy在庫 R1.0』または『FMEasy在庫 IWP/WD R1.5』
『FMEasy在庫』はこちらからダウンロードできます。
2. iPad/iPad Mini
3. FileMaker Go 13 (iPad にインストール)
FileMaker Go 13 はこちらからダウンロードできます。

注意：
1. 作業を始めるまえに、必ず『FMEasy在庫』のバックアップをお取りください。
2. 作業の際、修正場所を間違えると、既存の機能が動作しなくなる可能性があります。

1. 在庫誤差調整に必要なフィールドを準備

　以下のフィールドを EasyData15.fmp12（R1.0の場合、EasyData.fmp12） の商品テーブルに追加します。

　[c在庫誤差]（計算）　―　在庫誤差、誤差がある場合、調整の対象となる
　式：　If(棚卸在庫 = ""; 0; c在庫数 - 棚卸在庫)   //[棚卸在庫]が空欄(未入力)の場合、誤差は 無いものとみなす

　[c入庫数調整]（計算）　―　[c在庫誤差] がマイナスのときに、この誤差を入庫対象数とする
　式：　If(c在庫誤差  <  0; Abs(c在庫誤差); 0)

　[c出庫数調整]（計算）　―　[c在庫誤差] がプラスのときに、この誤差を出庫調整伝票の対象とする
　式：　If(c在庫誤差  > 0; c在庫誤差; 0)

　[gNo]（数値型、グローバル）　―　入庫伝票No/出庫伝票No の入出明細取込用一時記憶フィールド、後述のスクリプトで使用

2. 在庫誤差調整伝票作成スクリプトを作成

　このスクリプトの仕様は以下の通りです。

1)  在庫基準日を本日の日付（棚卸作業実施日）にする。
2)  棚卸作業を行わなかった商品は調整対象から除外する。
3) [在庫数] - [棚卸在庫] の誤差がプラスの場合は 出庫伝票、マイナスの場合は 入庫伝票 を作成する。
4) [在庫数] - [棚卸在庫] が 0 になる商品については、調整伝票を作成しない。
5) 入庫伝票/出庫伝票 の[伝票区分]は [7:在庫調整]（新設）とし、通常の伝票区分とは区別する。
6) 入出明細::備考フィールドに[棚卸担当ID]を記録。

　上記の条件に従ってスクリプトを記述すると、たとえばこのようになります。

　スクリプトの流れ上、入力チェックやウィンドウ切替などのステップも含まれていますが、基本的には上記の赤囲みの部分が押さえられていれば調整伝票を作成できるようになります。

① システム在庫を本日時点のものにする

　棚卸作業が終わった直後、つまり本日時点のシステム在庫と、棚卸在庫の差違をみるため、[在庫基準日1]　に本日の日付を設定します（Get(日付)）。

② [c入庫数調整] に値が入っている商品データを検索します。　
　このデータが入庫伝票作成対象となります。
　対象レコードがみつかった場合は、入庫伝票を新規作成し、その[入庫No]を [gNo]に一時記録します。

　次に、対象商品データを入庫明細として「入出明細」テーブルに取り込みます。
　その際、[入庫No] として[gNo]を取り込みます。
　取り込み順は以下のとおりです。

(商品テーブル)	→	（入出明細テーブル）
商品ID	→	商品 ID
g在庫基準日1	→	入出庫日
単位	→	単位
仕入単価	→	仕入単価
JAN	→	JAN
棚卸担当ID	→	備考
c入庫数調整	→	入庫数量
gNo	→	入庫No

　※データ取り込みのデータ自動入力オプションはオンにします。

③[c出庫数調整] に値が入っている商品データを検索します。　
　このデータが出庫伝票作成対象となります。
　対象レコードがみつかった場合は、出庫伝票を新規作成し、その[出庫No]を [gNo]に一時記録します。

　次に、対象商品データを出庫明細として「入出明細」テーブルに取り込みます。
　その際、[出庫No] として[gNo]を取り込みます。
　取り込み順は以下のとおりです。

(商品テーブル)	→	（入出明細テーブル）
商品ID	→	商品 ID
g在庫基準日1	→	入出庫日
単位	→	単位
販売単価	→	販売単価
JAN	→	JAN
棚卸担当ID	→	備考
c出庫数調整	→	出庫数量
gNo	→	出庫No

　※データ取り込みのデータ自動入力オプションはオンにします。

　ここまでできたら、一度スクリプトを実行してみましょう。
　調整伝票が作成されるとともに、商品の[在庫数]と[棚卸在庫]がぴったり一致していれば成功です。

【入庫調整伝票の例】

【出庫調整伝票の例】

【在庫の一致を確認（テスト段階）】

　何度かテスト実行して、問題がなければ、上記スクリプト内でコメントアウトされている[棚卸在庫]および[棚卸担当ID]の全置換クリアステップを有効にします。

　これにより、棚卸調整在庫が作成された後は、自動的に棚卸情報がクリアされますので、次回の棚卸作業時に[棚卸在庫]および[棚卸担当ID]フィールドがクリアされていないということがなくなります。

【在庫誤差調整伝票スクリプトの配置場所】

　在庫誤差調整伝票作成の実行ボタンは、ここでは商品一覧画面に配置してみます。
　赤囲みのところにご注目ください。
　[棚卸在庫]フィールドを[在庫数]フィールドの下に配置することで、調整伝票作成前に棚卸状況を確認できるようになっています。

　そして、“調整実行”ボタンをフッタ位置に配置し、ボタンクリックで調整伝票を一括作成することができます。

　“調整実行”ボタンについては、ユーザ権限による制御を追加するなど、誤操作防止策を検討してみてください。


【重要：在庫誤差調整伝票を作成するタイミング】

　システム在庫は常に変動しています。
　このため、棚卸作業開始～在庫誤差調整伝票作成完了までの間、一般ユーザによるシステムの使用や入出庫作業を禁止する必要があります。

　「禁止！」と言っているのにアクセスしてくる困ったちゃんがいる場合、FileMaker Server を停止し、サーバ上で本スクリプトを実行します。
　これにより、在庫の誤差がなくなることになります。

　なお、繰越処理（在庫や各種残高を繰り越す処理）を行っている場合、繰越処理の中に本スクリプトを組み込むのも Good！と思います。

　その他の在庫関連記事を読む

（亀）