太古の FileMaker システムを延命させる！

 小社では 「売上猫くん 4.0」という自社製パッケージ製品（一部改変）をもう20年程、社内の見積・売上・請求管理システムとして使用しています。　「売上猫くん」は初期には FileMaker 3/4 により開発されたものです。　この太古のシステムは現在、  仮想マシン（Windows Server 2008）上のFileMaker Server 5.5 で公開され、Windows 10 を含む最新のWindows 機上のFileMaker Pro 5.5/6 から毎日アクセスされて使用されています。
　小社同様、FileMaker 5.x/6.0 でシステムを運用している企業・組織は一定数あり、当方の客先にも何社かはそのようなところがあります。
　このような FileMaker のレガシーシステムを運用する場合、まずネックとなるのがハードウェアの老巧化や故障によるリプレイスです。　本稿では「FileMaker レガシーシステムの仮想化による延命方法」を小社の客先である某社を例にご紹介します。

1. 某社の状況

1998年： 某社より生産・購買・販売・在庫管理システムの開発業務を受注。FileMaker 4 により開発を開始。数ヶ月後に首尾よくリリースに漕ぎ着ける。某社本社の Macintosh 上に FileMaker Server 5.5 を配置し、NTTの専用線  Digital Access による WAN を介して複数拠点で運用を開始。

2001年： FileMaker 5.5 へアップグレード。fmj から  fp5 へのファイル構造の変換が伴うアップグレードにも関わらず、難なく終了。 この際、サーバを Windows Server 2000 に変更。

2008年*1： Windows Terminal Service （後のRemote Desktop Service）を導入し、FileMaker Pro 5.5 をインストール。拠点のユーザはこのサーバ上の FileMaker クライアントを実行することにより、アプリの実行速度を改善。この際、FileMaker Serverを運用するサーバ機も Windows Server 2008 に変更（参考記事）。さらに、ネットワークの高速化とコスト低減を目的に Digital Access から インターネットVPN へ変更。　 インターネットVPNへの変更に伴うセキュリティ上のリスクへの備えとして、SonicWALL による IPS 、Gateway Antiviurs 等も併せて導入。

導入以来、数多の仕様変更を繰り返しながら、現在もFileMaker 5.5 の環境で運用中。

*1
2008年当時、小社内で Windows Server 2008 と FileMaker Server 5.5 の組み合わせによる運用実績はあったのですが、このようなレガシーシステムの運用はベンダーによる動作保証の対象外となることを事前に客先に十分説明しなければなりません。　レガシーシステムの延命は客先のリスクに関する理解と許容が重要だと思います。

2. さらなる延命へ

2008年に導入した RDSサーバですが、経年劣化によるリプレイスを検討するように、客先に数年前からお願いしていたところ、先ごろ、ようやくリプレイス案を出すように求められました。　ただ、運用実績のある Windows Server 2008 は既に発売中止になっていました。そこで以下のような図と共に提案書を客先に提出しました。

仮想環境はWindows Server 2012/2016 Standard 付属のHyper-V（ゲストOSが2ライセンス付属）

A案は単純リプレイス型ですが、新サーバを導入し、そこに現行のOS（Windows Server 2008）をインストールし、RDTアカウントやFileMakerが動作する環境を新たに構築し直す、というものです。　問題となるのは、前述のように Windows Server 2008 に公式対応するサーバ機が2017年現在ほとんど存在しないので、それを覚悟の上での実装となります（参考：Microsoft社のサポート期限一覧）。

B案は現行サーバを P2V （Physical to Virutal）し、これを　Hyper-V 2.0 で運用するというものです。これが上手くいくと 旧サーバのハードディスク情報をそのまま仮想マシン化でき、OSやアカウント情報の再構築・再設定が不要になるので、大変便利です。　半面、まったく異なるハードウェア環境へ移動することになるので、各種ドライバでエラーが発生したり、悪くすると初回起動時にブルースクリーンが表示されたりします。　安定運用期に入るまで気をぬけません。

C案は 新規にWindowsサーバを導入、ゲストOS も新たに作成し、その上にRDTアカウント等の再度設定しなおすものです。ゲストOS上での作業はほとんどA案と同様になります。P2Vに比べハードウェアの差異によるエラーやブルースクリーンやらの可能性はほぼなくなりますが、すべて一からの作業となります。

　提案書と概算見積をご提示した後に打ち合わせをしました。結果、サーバ故障時やリプレイス時に仮想マシンであれば迅速に復旧可能であることも勘案し、Windows Server 2016 を使用したB案で進行することになりました。ただ前述のように P2Vが失敗するリスクがあることをご説明し、B案不首尾の場合は、A案、C案、さらには Windows Server 2016 の 2012 へのダウングレード（D案*2） もバックアップとしてご提示しました。

*2
D案の提案理由は  SATO のあるラベルプリンタが Windows Server 2012 へは公式対応している一方、Windows 2016 に非対応であることによります。重要な周辺機器との互換性もレガシーシステムの延命を行うときには“要注意”となります。

3.　テスト環境での実装

新しいサーバ機の納品までしばらく時間があるため、客先の旧サーバを予め P2V してVHD(X)にし、当方の Windows Server 2016 の Hyper-V に入れ、事前にテストを行いました。仮想マシンを起動するとエラーイベントが複数発生していたので、一つ一つ潰していきました。　次に FileMaker Pro 5.5 （以下、FM5.5）を起動してテストを実施。　下図のようにクライアントPCから仮想サーバにRD接続。 FM5.5 を使用し FileMaker Server 5.5 （以下、FMS）上の12万件のデータが入った郵便番号ファイルを開き、ソートを実行・・・　「ん？ 」、なんかかなり遅い感じ。

確認のため、仮想サーバではなく、別の物理マシンのRDS から郵便番号ファイルにアクセス（クライアントPC→物理マシンRDS+FMP→FMS）すると、なんと3倍！速い。　クライアントPC→Win Server 2016 RDS+FMP→FMSで実行してもやはり3倍速い。

　ならば、仮想サーバ上に郵便番号.fp5 を配置して、ネットワークを介さずローカルで実行するとどうか？　一瞬 ＝ 数秒～10秒程度！で終了してしまいます。　ということで、仮想サーバの通信速度（上図の「FMP⇔FMS接続」）に問題があることが判りました。　実はここからがすごく大変で、 「Hyper-V ゲストOS 遅い」や「Hyper-V Guest OS slow」などをキーワードに、数日間、ググって試す、ググって試すを繰り返しました。　ググってまず最初に出てくるのが、NICの仮想マシンキュー（VMQ、Virtual Machine Queue）を オフ にせよ、というもの。これは内外のいろいろなところで書かれており、小社の別のHyper-V環境下のゲストOSでは劇的な効果があったのですが、今回の仮想マシンについては全く効果無しでした。　NICの「IPV4チェックサムオフロード」をオフにしろ、という記事も多く見かけましたがこれもダメ。
NICの設定は、ホスト側からだけではなく、仮想マシンからもいじってみましたがうまくいかず。
万策尽きたか、と思ったところで、突然光明が差しました。　それは、「レガシーネットワークアダプタ」の使用（下図）。

　仮想マシンのネットワークアダプタを作成する際、「ハードウェアの追加」を選択。この時、通常は「ネットワークアダプタ」が推奨されますが、ここで「レガシ ネットワーク アダプター」を図のように選んで“追加”します。　これを行うことにより、

ping -l 60000 hostname

の応答時間も劇的に改善し、12万件の郵便番号ソートも劇的に速くなりました。

　今回のゲストOSは Windows Server 2008 で、このOSは Hyper-V の「統合サービス」に対応しているので、上図では「ネットワーク アダプター」を選択するのがセオリーだと思うのですが、、、
ネットで調べてもレガシはオバーヘッドが多いので、「ネットワークアダプター」を使いなさいという記事しか見当たらりませんでしたが、レガシーのままテストを続行することにしました。

尚、上記の記事に関する後日談はこちらをご覧ください。


（土屋）


追記
「売上猫くん3.0」は1997年に FileMaker Pro 3 により開発されたものですが、 いまだにご愛用頂いているお客様がいらっしゃいます。 ただ、ハードウェアの老巧化の問題があるのでできる限り新バージョンへのアップグレードをお勧めしてます。　それはそれとして、 FileMaker Pro 3/4 のシステムを Windows NT 4.0 の仮想マシンで運用するというのは、実際やったことはありませんが、チャレンジしてみたい気もします。

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

参考リンク：
物理マシンを Hyper-V 仮想マシンに移行する（P2V）
Performance Tuning for Hyper-V Servers
Hyper-V network adapter differences
Windows Server 2012 Hyper-V の SR-IOV 構築手順 (1)

Google サイト（Google Sites）をバックアップする方法

　Google サイトを使っていらっしゃる方は、サイトのバックアップをどうするか悩むところかと思います。

google-sites-liberation で公開されているツールは動かない

 　ツールの最新版は、2011/04/27 で google-sites-liberation-1.0.4.jar  の公開が終わっています。

google-sites-liberation で公開されているツールの一覧

　　しかしながら、google-sites-liberation-1.0.4.jar　を実行すると、以下の認証エラーが出ます。

google-sites-liberation-1.0.4.jar を実行すると表示される認証エラー

GitHub からツールの最新版をダウンロードしてバックアップする

 　google-sites-liberation - issue #107 （ソースは英語）を確認すると、https://github.com/sih4sing5hong5/google-sites-liberation　の方で開発が続行しているので、そちらを確認します。


　操作手順は次のとおりです。

　1. Google Sites Import/Export Tool のセクションからツールをダウンロードします。
　最新バージョンは 1.0.6 です（2017/01/23 現在）。

Google Sites Import/Export Tool のダウンロード

　2. google-sites-liberation-1.0.6-jar-with-dependencies.jar　がダウンロードされますので、ダブルクリックで実行します。
　実行にあたっては事前に Java をインストールしておく必要があります。

 

Google Sites Import/Exportツール

　3. 必要事項を入力してから、“Get a token from browser” をクリックします。
　すると、google がユーザ許可を求めるページが表示されますので、“許可”ボタンをクリックします。
　※事前に Google アカウントにログインしておく必要があります。

google-sites-liberation のアクセスを許可する

　4. トークンが発行されますので、クリップボードにコピーします。

表示されたトークンをクリップボードにコピー

　5. コピーしたトークンをツールに貼りつけてから、“Export from Sites”　をクリックすると、バックアップが始まります。

　※当然のことながら、トークンには有効期限があります。トークンが無効になった場合は、“Get a token from brower”をクリックすることによって、トークンを取得しなおしてください。

　6. Export　Complete が表示されたらバックアップ完了です。

　その他のバックアップツールとして、弊社では WinHTTTrack を使用していますが、このツールの使い方については、また機会をあらためてご紹介したいと思います。

Slim フレームワークの REST(PDO) および RESTfm を使って CRUD のテストをしてみた

　先日の記事『Slim フレームワークの REST による FileMaker データベースへのアクセス』では、REST URI 経由で FileMaker DB アクセス実験を行うために Silm フレームワークを採用しました。
　この記事ではWeb クライアントからの GET 要求を受領してから、 FileMaker データベースに PDO 経由で SELECT クエリを発行してデータを戻すという、Slim REST 側の操作方法を簡単にご紹介しました。

　今回はこの Slim フレームワークの REST 機能のパフォーマンステストに加え、RESTfm でもテストを行ってみました。
　RESTfm は、Goya 社 MIT ライセンスで公開しているオープンソースの PHP コードであり、 FileMaker Server で公開されているデータベースに対する REST API 機能を簡単に実装できます。

　とても便利！と思ったのは、REST に不慣れなプログラマが「 あるテーブルのレコードにアクセスする方法を知りたい」と思ったときに、RESTfm 環境の index.html にアクセスするだけで、その URI を知ることができることです。 
　例えば、「EasyApp15‗p」データベースにログインすれば、任意のレイアウトのそれぞれのレコードへの URI が自動表示され（下図）、商品レイアウト上のレコード ID 10951 へのレコードにアクセスするためのリンクが表示されていることが確認できます。

　また、URL の最後の部分のファイル拡張子は .html ですが、これを .json、.xml、.txt、.fmpxml　などに書き換えるだけで、自動的に変換表示してくれるのもよいですね。これは、PHP でプログラムしたことがある方ならわかりますが、結果セットを簡単に見ることができ、とても楽ちんです。


　さて、本題に戻りますが、今回のパフォーマンス検証では、クライアントの Web ページから GET（取得 READ）、POST（新規作成  CREATE）、PUT（更新 UPDATE）、DELETE（削除） 要求を発行しました。

　比較用として、記事「 FileMaker API別にCRUDのテストをしてみた」で採用した API も一緒にグラフに掲載しておりますので、 併せて参考にしてください。

テスト環境

サーバ： Xeon 2.2GHz(1Core)/4GB RAM（Hyper-V 仮想マシン）
OS/Webサーバ： Windows Server 2012/IIS 8.0
FileMaker Server： Ver 15
使用言語： PHP
使用DB： FMEasy在庫 IWP/WD R1.5 （パイロット版）
使用REST API：
　Slim フレームワーク（PDO を使用）
　RESTfm 4.0.8 (FileMaker API for PHP を使用)
テスト概要：
　Slim フレームワーク REST URI 経由、および RESTfm の URI 経由でCRUD（Create/Read/Update/Delete）を行う簡単な Webアプリを作成・実行。

備考：

1. Slim フレームワークから FileMaker データベースへの接続オブジェクトは PDO(ODBC)です。
2.  RESTfm はその仕様上、内部的には FileMaker API for PHP で FileMaker Server に接続します。

　Slim フレームワークは Composer を使ってインストールします。
　詳しくは以下のリンクをご覧ください。
　https://www.slimframework.com/docs/start/installation.html

　RESTfm の最新版は 4.0.8 です。（2016/12/06 現在）
　以下のリンクよりダウンロードできます。
　https://github.com/GoyaPtyLtd/RESTfm/releases

　各テストはそれぞれ5回実施して開始から終了までの時間をプログラム上で測定。各5回の平均値を基にデータを作成しました。

Slim フレームワークを使用し、100件のレコードを REST URI 経由で検索・表示した際のブラウザウインドウ（FireFox）

RESTfm を使用し、100件のレコードを REST URI 経由で検索・表示した際のブラウザウインドウ（FireFox）

GET メソッドによる Readテスト 1

テスト内容：
　94万レコードを持つテーブルから該当件数が N 件になるようにレコードを検索し、その中から100レコードのみを表示

結果：　XML圧勝！　Slim は遅いね

該当件数がN件になるようにレコードを検索し、その中から100件を表示

No. of found                     recs APIs	0	15000	30000	300000	600000	900000
FM API for PHP	0	0.22	0.34	1.76	3.28	4.74
XML	0	0.19	0.25	1.68	3.26	4.71
PDO	0	0.65	0.72	2.47	4.18	5.91
Slim REST PDO	0	0.46	0.63	3.86	7.3	10.69
RESTfm	0	0.88	0.91	2.32	3.91	5.4

補足：
　対象レコード件数が 1万件前後までは他の API とさほどパフォーマンスの差は感じられませんが、2万件あたりから差は開いていき、3万件を超過すると Slim REST PDO グラフ線（エンジ色）の傾斜は急激にきつくなっています。

　これに対し、RESTfm （黄色のグラフ線）は、該当件数が90万件でも、その中から 100件取り出す程度であれば、PDO よりもパフォーマンスは良いようです。

GET メソッドによる Readテスト 2

テスト内容：
　94万レコードを持つテーブルで 該当件数が3万件になるように検索し、N 件のレコードを表示

結果：　FM API for PHP と XML が有利　Slim と RESTfm はやはり遅い

該当件数が3万件なるように検索し、その中から N件を表示

No of fetched          　　        recs APIs	0	100	500	1000	2500	5000	7500	10000
FM API for PHP	0	0.34	0.81	1.36	4.32	6.99	10.51
XML	0	0.25	0.55	1.09	2.88	6.04	10.58	16.19
PDO	0	0.72	0.74	1.28	3.45	5.18	7.46	10.24
Slim REST PDO	0	0.64	1.6	2.75	6.15	12.32	18.22	23.72
RESTfm	0	0.97	4.31	7.97	19.25

補足

　100 件程度のデータを取り出すなら、やはり FM API for PHP および XML がパフォーマンスに優位性がみられます。
　取得件数が 5000 件を増えると PDO が優位になってきます。

　全体的にみて、Slim も RESTfm も取り出すデータ件数が増えるにしたがい、極端にパフォーマンスが低下しているのがわかります。

　2500件取得時には、Slim（注：Slimは PDO を使用） は PDO（注：Slim不使用の生PDO） の約 1.8倍の応答時間となっており、RESTfm は PDO の約 5.6倍の応答時間となっています。
　1万件取得時には、Slim は PDO の約 2.3倍の応答時間、RESTfm （注：FM API for PHP を使用）にいたっては、5000 件以降はサーバタイムアウト（30秒）が発生し、計測不能となっています。

CREATE テスト

テスト内容：
　94万レコードを持つテーブルに対して 100件のレコードを PHP のループにより作成。その後、作成した100件のレコードを検索して表示。

備考：

1. Slim フレームワークは、内部処理をある程度自由にプログラミングできるため、クライアント側から 100回 POST 要求を発行するパターンと、1 回の POST 要求で Slim フレームワーク側で 100 レコードをループ作成する方法で計測を行いました。
2. RESTfm は、URI のパターンは定型化されていますが、1件レコード作成用の URI と複数のレコード作成を一回のリクエストで実現するバルク処理用の URI が用意されているため、それぞれで計測を行いました。
   
   1件レコード作成用　RESTfm  URI パターン
   /RESTfm/{datagase}/layout/{layout}
   
   バルク作成用　RESTfm 　URI パターン
   /RESTfm/{database}/bulk/{layout}
   
   それぞれ、POST メソッドにて json 形式のデータを送信。

結果：　PDOの圧勝！ただ、バルク処理なら Slim PDO もいい感じ

100レコード連続作成結果

補足

　クライアント側から 1 回リクエストを発行し、REST 側で 100 回レコード作成したほうが、クライアントから 100 回リクエストを発行し、そのたびに 1 回レコードを作るよりパフォーマンスがよくなるのは当然ですけどね…

DELETE テスト

テスト内容：

　94万レコードを持つテーブルを使用。FM API for PHP と XML では100レコードが対象となるように検索を実行。その後に PHP のループによりレコードを1件ずつ削除。PDO および Slim では DELETE table WHERE ～により、100件を一度に抽出して一括削除。

 RESTfm では、100レコードが対象となるように検索を実行後、バルク処理を使ってレコードを一括削除。

備考：

バルク作成用　RESTfm 　URI パターン
/RESTfm/{database}/bulk/{layout}

DELETE メソッドにて json 形式の削除対象データを送信。

結果：　PDO 圧勝だが、Slim も RESTfm もバルク処理ならパフォーマンスはよい

100レコード削除結果

UPDATE テスト

テスト内容：
　94万レコードを持つテーブルを使用。FM API for PHP と XML では100レコードが対象となるように検索を実行。その後に PHP のループによりレコードを1件ずつ更新。　PDO および Slim では　UPDATE table SET ～ WHERE ～により、100件を一度に抽出して一括更新。　更新後、更新対象となったレコード100件を検索して表示。

　RESTfm では、100レコードが対象となるように検索を実行後、バルク処理を使ってレコードを一括更新。

備考：

バルク更新用　RESTfm 　URI パターン
/RESTfm/{database}/bulk/{layout}

注：PUT メソッドにて json 形式の更新データを送信。

結果：　PDO圧勝！Slimも奮闘。ただ、RESTfm は連続更新は苦手みたい

100レコード更新結果

結論：

　Web アクセスをする場合、間に何か挟めば余分なトラフィックが発生しますので、低速になるのはあたりまえです。というわけで、これは納得の結果です。

　すべてが自己完結するような Web アプリケーションを一から組めば、パフォーマンスに優れ、かつかゆいところに手が届くものができるかもしれませんが、それなりのコストと時間がかかってしまうことがネックとなります。

　多少パフォーマンスを犠牲にしてしまうことが許容される業務環境で、Web アプリケーションをなるべく短期間で開発する場合は、Slim のような REST フレームワークや、RESTfm のような既成 REST モジュールを採用することは選択肢としてありでしょう。

　しかしながら、どれを採用するにしても、覚えることが増えることには変わりません。

　Slim フレームワークの場合は、GET/POST/PUT/DELETE などの送信メソッドに対応した便利な機能が多数用意されていますが、それらを組み合わせてそれぞれの要求に応答した処理を行うには、担当プログラマが検討してコーディングする必要があります。
　組み方によっては、効率的にデータベースアクセスができるものが仕上がるという柔軟性はあります。

　RESTfm に関しては、操作用の定型 URI があらかじめ提供されているため、開発者がやりたいことさえ把握していれば、比較的高速に Web アプリケーションを完成させられるでしょう。Slim フレームワークに比べれば、覚えることが少ないのは良いと思います。
　ただし、RESTfm は FileMaker API for PHP を経由しますので、FileMaker API for PHP のパフォーマンスに縛られます。さらに、RESTfm 内部でも処理を行いますので、その分の処理コストが上乗せされます。
　つまり、FileMaker API for PHP が不得手な処理を RESTfm 経由で連続してやらせたりすると、パフォーマンスは極端に低下してしまいます。


　Web プログラミングは、長い目で見れば開発コストよりも運用コストの方がものを言います。特に、多数のクライアントを抱える Web サイトや、短時間に何人ものユーザが集中的にアクセスするようなサイトですと、Web サーバのパフォーマンス問題は避けては通れない話です。

　それぞれの特徴やパフォーマンスをある程度比較検討したうえで、業務要件に適したツール選択を行うのが失敗しない Web 開発につながるでしょう。

参考リンク：
Slim フレームワーク (英語)
Slim フレームワーク ユーザガイド (英語)
RESTfm （Goya 社）(英語)
RESTfm オンラインマニュアル (英語)
RESTfmがオープンソースに (Not only FileMaker)


（亀）

FileMaker API別にCRUDのテストをしてみた

　FileMaker をバックエンドに Webプログラミング（カスタムWeb、CWP とも呼ばれる）を行う場合、実行速度的に一番有利な API はどれか？ と悩んだ方もおられるかと思います。
　今回、FileMaker  API for PHP、XML、PDO(ODBC) を使用し、それぞれが CRUD（Create/Read/Update/Delete）に要する時間を測定してみました。みなさんが Webプログラミングを行う際の参考になればなによりです。

テスト環境

サーバ： Xeon 2.2GHz(1Core)/4GB RAM（Hyper-V 仮想マシン）
OS/Webサーバ： Windows Server 2012/IIS 8.0
FileMaker Server:  Ver 15
使用言語： PHP
使用DB： FMEasy在庫 IWP/WD R1.5 （パイロット版）
テスト概要：
CRUD（Create/Read/Update/Delete）を行う簡単な Webアプリを FileMaker API for PHP、XML、PDO(ODBC) 別に作成・実行。各テストはそれぞれ5回実施して開始から終了までの時間をプログラム上で測定。各5回の平均値を基にデータを作成しました。

FM API for PHP を使用し、100件のレコードを検索・表示した際のブラウザウインドウ（FireFox）

Readテスト 1

テスト内容
94万レコードを持つテーブルから該当件数が N 件になるように検索し、その中から100レコードのみを表示

結果：　XML圧勝！　PDO惨敗

No. of　found recs APIs	0	15000	30000	300000	600000	900000
FM API for PHP	0	0.22	0.34	1.76	3.28	4.74
XML	0	0.19	0.25	1.68	3.26	4.71
PDO	0	0.65	0.72	2.47	4.18	5.91

補足
折れ線グラフではあまり目立ちませんが、該当件数が少ない場合、FM API for PHP または XML を使用したほうがPDOより3倍程高速であることが上表のオレンジ部分から解ります。表示する件数が100ほどの場合、検索時の該当件数（resultset）が増えるに従い、FM API for PHP / XML のPDOに対する優位性が薄れます。

Readテスト 2

テスト内容
94万レコードを持つテーブルで 該当件数が3万件になるように検索し、N 件のレコードを表示

結果：　FM API for PHP と XML が有利

No of fetched          　　        recs APIs	0	100	500	1000	2500	5000	7500	10000
FM API for PHP	0	0.34	0.81	1.36	4.32	6.99	10.51	Error
XML	0	0.25	0.55	1.09	2.88	6.04	10.58	16.19
PDO	0	0.72	0.74	1.28	3.45	5.18	7.46	10.24

補足

100件の表示を行うのであれば、FM API for PHP と XML が有利ですが、表示件数が2500になると PDO の優位性が出てきます。ただ、画面上に2000件以上のレコードを表示する Webアプリ はあまりないと思われるので、FM API for PHP と XML に軍配を上げました。

注：
以前、郵便番号検索アプリを使用し、「北海道」を検索してレコードを表示するテストをAPI別に行いました。「北海道」を検索すると8000件強のレコードが検索されるので、このようなケースではPDOが優位となります。Webサーバの負荷を考えると、8000件一括表示は普通やらないほうが良いでしょう。

Create テスト 

テスト内容：
94万レコードを持つテーブルに対して 100件のレコードを PHP のループにより作成。その後、作成した100件のレコードを検索して表示。

注：
レコードを1件のみ作成するテストもやってみようかと思ったのですが、1件のみでは一瞬で処理が終了してしまい、他のプロセスが測定結果に大きく干渉すると思われたため、100件のレコードを作成することにしました。

結果：PDOの圧勝！

Delete テスト

テスト内容：94万レコードを持つテーブルを使用。FM API for PHP と XML では100レコードが対象となるように検索を実行。その後に PHP のループによりレコードを1件ずつ削除。PDO では DELETE table WHERE ～により、100件を一度に抽出して一括削除。

結果：　PDO圧勝！

Update テスト

テスト内容：

94万レコードを持つテーブルを使用。FM API for PHP と XML では100レコードが対象となるように検索を実行。その後に PHP のループによりレコードを1件ずつ更新。　PDO では　UPDATE table SET ～ WHERE ～により、100件を一度に抽出して一括更新。　更新後、更新対象となったレコード100件を検索して表示。

結果：　PDO圧勝！

まとめ

 上記のテストより、Read（検索/表示）では FM API for PHP/XML が有利であることがわかりました。　Create/Update/Delete では PDO（ODBC） が有利でした。
API使用のガイドラインは以下のようになると思われます。

1. 基本は、FM API for PHP を使用する
   XML は FM API for PHP より高速ですが、結果セット（resultset）の処理が面倒。
2. 2000件を超えるレコードを表示したり、数十以上のレコードを頻繁に Create/Update/Delete するアプリでは、PDO（ODBC）を使用する 

　また、FM API for PHP/XML のクエリ機能は貧弱なので、SQL を使用しないと実現が面倒な DISTICT や UNION 等の処理については、PDO（ODBC）の使用を検討すべきでしょう。逆に、FileMaker ODBC で内外結合（JOIN）を行い結合先のテーブルに対してクエリを行うと恐ろしく速度が劣化します。JOINを使うのであれば、FM API for PHP により 関連テーブル（TO）にアクセスしましょう。　

　今回のテストを通じて感じたのは、「実行速度に問題が生じた場合は、1つのAPIに固執せず、別のAPIに当たってみるのが正解」ということでした。

（土屋）

Slim フレームワークの REST による FileMaker データベースへのアクセス

　FileMaker では API for PHP、FX.php、XML、ODBC を介して Webプログラミングを行うのが通常ですが、昨今巷で REST なる言葉を聞くようになりました。　そこで今回は REST を使用した FileMaker DB アクセスにトライしてみました。

　開発環境は以下のとおりです。

Slim フレームワークを使った REST 構成で FileMaker Server にアクセス

　ご覧のように、Microsoft IIS  Web サーバに FileMaker Server 15 と PHP をインストールしたうえで、 Slim フレームワークをインストールしています。

REST についてモヤモヤっとしがちなところ

 　REST （REpresentational State Transfer） とは、サーバ上の情報（リソース）に対し、一意の URI を提供するためのアーキテクチャ（仕組み）です。 
　この 一意の URI と、Web クライアントから渡ってきた HTTP メソッドの組み合わせにより、リソースを操作します。

メソッド	処理
GET	取得。idempotent
POST	新規作成。not idempotent
PUT	更新。idempotent
DELETE	削除。idempotent (限定的)

　表中の idempotent は冪等（べきとう）性を指します。これは、何度操作しても同じ結果が返ってくるという意味です。これはステートレスという、REST の特徴になっています（ステートレスについては後述します）。

　idempotent について例を簡単に示します。

　GET メソッド  --- Amazon でたとえば PlayStation 4 Pro という商品の情報を得るためのGET リクエストは、https://www.amazon.co.jp/dp/B01LRHPUZ4/　です。

　これは固有の URI として一般公開されているため、Web ユーザがこの URI に何度アクセスしても、このリンクが存在するかぎりは同じ商品にたどりつくことを意味します。よって、この処理は idempotent （冪等性がある）となります。

　POST メソッド ---  Amazon の例でたとえると、出品者が Amazon に商品情報を追加したいときの URI は専用のものを使いますが、その URI だけでは、追加された商品（リソース）にたどりつくことができません。
このため、この URI そのものはリソースの一意性を保障できないため、not idempotent （冪等性がない）となります。
 
　PUT メソッド ---  特定のリソースを更新しますので、この URI は idempotent （冪等性がある）となります。

　DELETE メソッド --- 削除処理が完了するまでの間はリソースの URI は有効なため、 idempotent （冪等性がある）ですが、削除が完了するとそのリソース自体が消滅するため、not idempotent （冪等性がない）になります。これが限定的に idempotent とな理由です。


　アクション部分は HTTP メソッドで指定し、URI 各項目を名詞で表現するというルールを実装することによって、URI の一意性がもたらされます。
　また、実際の操作を実行するファイル名や引数名の隠匿性も高くなります。

ステートレスとステートフル

　REST の特徴としてステートレスな通信であることが挙げられます。
　しかし、Web アプリケーションの目的によっては、ステートレスですべての要求がまかなえない、つまり REST だけではシステム設計に無理が出てくることもあります。

　以下に例を示します。

　ニュースサイトでニュースを見るとき、見たいニュースのリンクをクリックすると、ニュースの内容が表示されたら処理は完結します。ユーザが今の時点まで どんなニュースを見てきたかという処理の流れについてはサーバは関知しません。 このような通信はステートレスであるといいます。

　ユーザが条件を指定するというパターンでは、Google Map サービスが良い例となるでしょう。
　住所を入力すれば、その住所の地図が即座に表示されますが、Web サーバはユーザとのやり取りを保持しません。しがたって、この通信もステートレスです。

　それでは、オンラインでショッピングカートに入れた商品を買う場合はどうでしょうか？
　ユーザは購入内容の確認からクレジットカード決済の処理にいたるまでの一連の処理をサーバと対話形式で行っていく必要がありますね。処理が完了するまで、サーバはユーザとのやりとりを保持しますので、この通信はステートフルになります。

 REST に関する参考リンク：

REST [WikiPedia]
CHAPTER 5 Representational State Transfer (REST) [REST を提唱したロイ・フィールディングの博士論文] 英語

Slim フレームワーク を使った REST 環境の構築

　Slim フレームワークは、REST 対応の軽量 PHP フレームワークです。
　HTTP メソッド別の処理のルーティングがあらかじめ想定されているため、比較的少ないコード量でデータベースアクセスルールと応答処理の実装ができます。

　インストール方法は公式サイトをご覧ください。

　Slim フレームワーク 公式サイト[英語]

Microsoft IIS 向け REST 構成のためのルート URL 書き換え

　Apache の .httaccess 書き換え方法は割といろいろなところで見つかりますが、IIS 向けの情報があまりないようですので、まとめてみました。
　
　たとえば、Web アプリケーションのルートディレクトリが inventory のとき、出庫ID=123 の商品を照会するための index.php へのアクセスはこのようになるでしょう。

　http://hostname/inventory/index.php?act=outgoing&id=123

　REST 構成の URI は、スラッシュで文字列を区切った形式となります。
　このため、GET リクエストを発行するユーザに提供する URI は以下のようになります。

　http://hostname/inventory/outgoing/123

  上記の赤色の URI は、本来は http://hostname/inventory/index.php ですが、これを http://www.hostname/inventory/ と書き換えることによって、ユーザに index.php ファイルを通知しないようにするとともに、後続のスラッシュで区切られた文字列をそのまま index.php に通知するように URLを書き換える必要があります。

　 http://hostname/inventory/index.php
　↓
　 http://hostname/inventory/


【操作手順】

1. あらかじめ、ユーザに公開する inventory ディレクトリを wwwroot 配下に作成しておきます。
2. Windows Server のインターネット インフォメーション サービス（IIS） マネージャを起動します。
3. 左ペインで、ユーザに公開する inventory までディレクトリを展開し、「URL書き換え」アイコンをダブルクリックします。
   
   

   

   inventory ディレクトリの「URL書き換え」アイコンをダブルクリック

   
   　「URL 書き換え」ペインが表示されますので、右ペインのメニュー項目より「規則の追加...」リンクをクリックし、「受信規則と送信規則」のセクションの中から[ユーザフレンドリ URL]を選択して“OK”ボタンをクリックします。
   
   

   

   ユーザーフレンドリ URL を選択

   
   
   
4. 「ユーザーフレンドリ URL を有効にする規則の追加」ダイアログが表示されますので、[動的 Web アプリケーションで使用される内部 URL の例を入力してください]のボックスに、index.php への URL をフルで入力します。
   たとえば、下図のように入力します。
   
   
   
   
   
   
   [Web サイト訪問者のブラウザーに表示される、タイプするパブリック URL の例を選択してください]の項目は、ここでは無視してください。
5. 受信規則の URL 書き換えリストに、前述の規則が追加されます。この規則をダブルクリックします。
   

   

   今追加した規則をダブルクリック

   
   URL 書き換えの詳細ペインが表示されます。
   [パターン(T)]のボックスには、^inventory/index.$ という記述になっていますが、これを ^(.*) という記述に書き換えます。
   
   

   

   受信規則のパターンの書き換え

   
   　つぎに、画面下部の「アクション」のセクションで、URL書き換えの不要な文字列を取り除きます。現在、inventory/index.php という記述になっていますが、これを index.php という記述に変更します。
   
   

   

   アクション URL の書き換え

   
   
   ここまで終わったら、右ペインの「適用」リンクをクリックすることによって、修正を反映させます。
   この規則は、inventory ディレクトリの中に、web.config という xml 形式のファイルで保存されます（ Apache でいう .htaccess ファイルに相当するファイルです）。
6. アクセステストしてみましょう。
   
   ためしに、Hello World! と記述した html ファイルを index.php という名前で保存し、inventory ディレクトリに配置します。
   
   このファイルに、以下のリンクパターンでアクセスしてみましょう。
   
   http://hostname/inventory/
   http://hostname/inventory/outgoing/
   http://hostname/inventory/outgoing/123
   
   このように、各パラメータを渡したときにも、ページが見つからないというエラーが返ってこなければ、URL 書き換えは成功です。
   
   
   
   
   パラメータ別に所定の処理が動作するようにするには、Slim フレームワーク側でそれぞれのパラメータを受け取るようにコード記述を行います。
   

Slim フレームワークで FileMaker に接続するためのコード記述例

　ここでは、Slim フレームワークから FileMaker データベースに PDO(ODBC) 接続し、GET 要求されたデータを返すためのコード記述例を簡単に説明します。

　ユーザに公開するための出庫データ取得用 URI の形式は以下を想定します。

　 http://hostname/inventory/outgoing/123

　赤で示した部分は、URL 書き換え設定を行った URI です。つまり内部的には http://hostname/inventory/index.php にアクセスすることになります。

　outgoing/123 は　パラメータ1/パラメータ2 という並びになりますので、ここではoutgoing（出庫）と123(ID)という、2つのパラメータを取ることになります。

　
【コードの記述】

 　ここでは、Slim フレームワーク公式サイトにあるコード記述方法にできるだけ沿った形でコード例をご紹介します。

1. 接続情報の事前設定をします。
   
   　以下は、ローカルホストの FileMaker Server 15 で公開中のデータベースファイルへの接続情報となります。
   　将来的にこの接続設定を複数のファイルで使いまわしたい場合は、以下の部分を外部ファイル化（ config.php など）しておいて、実装時にインクルードするとよいでしょう。
   
   
   <?php
   
       $config['displayErrorDetails'] = true;
       $config['addContentLengthHeader'] = false;
       $config['db']['host']   = "localhost";         //ホスト名
       $config['db']['user']   = "webuser";          //ユーザ名
       $config['db']['pass']   = "password";             //パスワード
       $config['db']['dbname'] = "testdatabase";   //データベース名
   
   ?>
   
   
   
2. Slim フレームワークオブジェクトのインスタンスを生成します。
   
   
   　いよいよ、 Slim REST API の本体となる index.php ファイルを書いていきます。ユーザへのURI を提供するのがこのファイルとなります。
   
   　$app = new \SlimApp(); で $app という名前の Slim オブジェクトのインスタンスが生成されますが、あらかじめ接続情報を読み込ませておく場合は、$app = new \Slim\App( ['settings' => $config] ); のように記述します。
   
   
   <?php
   
       use \Psr\Http\Message\ServerRequestInterface as Request;    //要求インタフェース
       use \Psr\Http\Message\ResponseInterface as Response;　      //応答インタフェース
   
       require_once '../slim/vendor/autoload.php';    //Slim への相対パス
       require_once 'config.php';                            //外部ファイル化された接続情報（任意）
   
                                                                   //Slim インスタンス生成
       $app = new \Slim\App( ['settings' => $config] );
   
   ?>
   
   
3. データベース接続の準備をします。
   
   $app に実装済のデータベース接続情報の取り出しは、getContainer() メソッドで行います。
   そして、コンテナの db 要素に PDO オブジェクトを返すように設定しておきます。
   
   
                           //コンテナ取り出し
   $container = $app->getContainer();
   
                           //コンテナにデータベース接続を定義しておく
   $container['db'] = function ( $c ) {
   
       $db = $c['settings']['db'];
       $pdobj = new PDO("odbc:Driver={FileMaker ODBC};host=" . $db['host'] . ";Database=" . $db['dbname'],$db['user'], $db['pass']);
       $pdobj->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
       $pdobj->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);
   
       return $pdobj;
   
   };
   
   
   
4. GET リクエストを受信したときの動作を記述します。
   
   　GET リクエストを受信した場合に応答する場合は、get メソッドを使います。
   　$app->get(); が原形となりますが、GET で受け取る引数と処理の記述は、たとえば以下のような形式となります。
   
   　赤字がユーザから受け取る引数のリスト（スラッシュ区切り）、青字が処理内容です。
   　引数のリストの可変部分は中カッコ{}で囲み、中にその識別名を入れておきます。
   　以下の場合は、出庫ID を想定した識別名を id とし、{id} のように記述しています。
   
   　ユーザから渡された id を取り出すには、要求オブジェクト $request から getAttribute メソッドを呼び出すことで実現します。
   　以下のコードのように書くことで、ユーザから渡された id が $id にセットされます。
   
   
   $app->get( '/outgoing/{id}', function ( Request $request, Response $response )   {
   　　　　                        //パラメータ取り出し
           $id = $request->getAttribute( "id" );
       }
   );
   
   $app->run();
   
   最後の $app->run(); でユーザからのリクエストを受け付けます。
   
   上記は GET 要求に対する処理を無名関数の中で行うように記述していますが、別途名前つきの関数を作って呼び出すようにしてもかまいません。
5.  データベースに接続し、クエリを発行します。
   
   　データベースの接続は、$this->db; で行います。これにより、3. のデータベース接続が実行されるとともに、PDO オブジェクトが返ってきますので、それを使ってデータベース操作を行います。
   
   　たとえば、前述の get メソッドの部分をまとめて書くと、以下のようになります。
   最後に結果を return することで呼び出し元に json フォーマットのデータを返しています。
   
   
   $app->get( '/outgoing/{id:[0-9]+}', function ( Request $request, Response $response ) {
   
                           //パラメータ取り出し
       $id = $request->getAttribute( "id" );
          
       try {
   
                           //$this->db の形で接続確立し、$pdo オブジェクトを生成
               $pdo = $this->db;
   
               $sql = 'SELECT * FROM "出庫" WHERE "出庫ID"='.( int )$id;
               $stmt = $pdo->prepare( mb_convert_encoding( $sql, "shift-jis" ) );
               $stmt->execute();
   
                               //対象レコードカウント
               $recordCount = $stmt->rowCount();
              
               if( $recordCount == 0 ){
   
                           //レコードなし
                   $result = 401;
   
               }else{
          
                           //レコード取り出し
                   $data = $stmt->fetchAll();
              
                   if( isset( $data ) ){
   
                       mb_convert_variables( 'UTF-8','shift-jis',$data );
   
                       $result =  json_encode( $data );
   
              
                   }else{
   
                           //レコードなし
                       $result = 401;
                  
                   }
               }
   
               $pdo = null;
          
           } catch( PDOException $e ) {
   
               $result = '{"error":{"text":'. $e->getMessage() .'}}';
              
           }
   
           return $result;
          
       });
   
   重要：
   
   • PDO(ODBC) でクエリを発行する際は、文字コードは shift-jis 形式で渡さなければエラーが発生します。
   • 戻りデータの文字コード shift-jis になりますので、必要に応じて文字コードを変換してから使用する必要があります。
   • PDO(ODBC) では bindParamやbindValue による引数のバインドがうまくいかない模様です。このため、SQL インジェクション対策として、{id}　で受け取る引数を数値に限定するように {id:[0-9]+} と書き換えてあります。
   
   
6. テストしてみましょう。
   
   Web ブラウザから、http://hostname/inventory/outgoing/任意の数字 を入力して送信したときに、json 形式の結果がブラウザページに表示されれば成功です。
   
   

　応用編として、Web インタフェースを作り、出庫ID指定による一覧呼び出しを行った例が、以下のようになります。 内部的に Slim アクセスへの URI を呼び出しを行い、戻ってきた json データを整形して一覧表示しています。

内部的に Slim URI を呼び出している Web インタフェースの例

　Slim は軽量とはいえ、間にフレームワークを挟めば処理速度は低下します。
　こちらの記事でパフォーマンスについてご紹介しておりますので、併せてご覧いただけると幸いです。
　Slim フレームワークの REST(PDO) および RESTfm を使って CRUD のテストをしてみた


　Slim フレームワーク以外でも FileMaker で使用できるオープンソースの REST 環境がいくつかあるようです。
　

参考リンク：
　
　RESTfm (Goya)
　RESTfmがオープンソースに (Not only FileMaker)
　fmEasyAPI  開発者はサポートやめちゃったみたい...