　FileMaker って、、、あれかなぁ

2016-12-06

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アプリを作成・実行。

備考：

Slim フレームワークから FileMaker データベースへの接続オブジェクトは PDO(ODBC)です。
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	15000	30000	300000	600000	900000
FM API for PHP	0.22	0.34	1.76	3.28	4.74
XML	0.19	0.25	1.68	3.26	4.71
PDO	0.65	0.72	2.47	4.18	5.91
Slim REST PDO	0.46	0.63	3.86	7.3	10.69
RESTfm	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	100	500	1000	2500	5000	7500	10000
FM API for PHP	0.34	0.81	1.36	4.32	6.99	10.51
XML	0.25	0.55	1.09	2.88	6.04	10.58	16.19
PDO	0.72	0.74	1.28	3.45	5.18	7.46	10.24
Slim REST PDO	0.64	1.6	2.75	6.15	12.32	18.22	23.72
RESTfm	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件のレコードを検索して表示。

備考：

Slim フレームワークは、内部処理をある程度自由にプログラミングできるため、クライアント側から 100回 POST 要求を発行するパターンと、1 回の POST 要求で Slim フレームワーク側で 100 レコードをループ作成する方法で計測を行いました。
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)

（亀）

2016-12-01

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	15000	30000	300000	600000	900000
FM API for PHP	0.22	0.34	1.76	3.28	4.74
XML	0.19	0.25	1.68	3.26	4.71
PDO	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	100	500	1000	2500	5000	7500	10000
FM API for PHP	0.34	0.81	1.36	4.32	6.99	10.51	Error
XML	0.25	0.55	1.09	2.88	6.04	10.58	16.19
PDO	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使用のガイドラインは以下のようになると思われます。

基本は、FM API for PHP を使用する
XML は FM API for PHP より高速ですが、結果セット（resultset）の処理が面倒。
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に当たってみるのが正解」ということでした。

（土屋）

2016-11-17

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/

【操作手順】

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

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

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

ユーザーフレンドリ URL を選択
「ユーザーフレンドリ URL を有効にする規則の追加」ダイアログが表示されますので、[動的 Web アプリケーションで使用される内部 URL の例を入力してください]のボックスに、index.php への URL をフルで入力します。
たとえば、下図のように入力します。

[Web サイト訪問者のブラウザーに表示される、タイプするパブリック URL の例を選択してください]の項目は、ここでは無視してください。
受信規則の URL 書き換えリストに、前述の規則が追加されます。この規則をダブルクリックします。

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

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

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

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

アクション URL の書き換え

ここまで終わったら、右ペインの「適用」リンクをクリックすることによって、修正を反映させます。
この規則は、inventory ディレクトリの中に、web.config という xml 形式のファイルで保存されます（ Apache でいう .htaccess ファイルに相当するファイルです）。
アクセステストしてみましょう。

ためしに、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 フレームワーク公式サイトにあるコード記述方法にできるだけ沿った形でコード例をご紹介します。

接続情報の事前設定をします。

　以下は、ローカルホストの 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";   //データベース名

?>
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] );

?>
データベース接続の準備をします。

$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;

};
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 要求に対する処理を無名関数の中で行うように記述していますが、別途名前つきの関数を作って呼び出すようにしてもかまいません。
データベースに接続し、クエリを発行します。

　データベースの接続は、$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]+} と書き換えてあります。
テストしてみましょう。

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 開発者はサポートやめちゃったみたい...

2016-08-30

Record navigation in FileMaker PDO Custom Web Publishing is so slow... why?

Searching records in FileMaker Custom Web Publishing(CWP) using PDO(PHP Data Objects) can become pretty frustrating as a table grows much bigger, say the table has one million records.

A table with one million records is not THAT huge when it is of a MySQL table, but it is obviously too much to handle for FileMaker if you want to do some CWP using PDO.

FileMaker is compatible with ODBC, and PDO supports ODBC. This means you can perform SQL queries via PDO to retrieve data from FileMaker databases.

We will be talking about this issue using PDO in this post.

Here are a few things to consider if your tables have thousands of records:

Do not use SELECT COUNT (*)

select count(*) causes a server time out, and worse yet, the existing fmxdbc_listener.exe process eats up CPU usage and RAM while counting records, and then goes unresponsive.

This is serious, because you will end up killing and starting fmxdbc_listener.exe process manually, or restarting the FileMaker Server.

SELECT COUNT ( fieldname ) would not make the situation any better. :(
Do not use the ORDER BY clause

This also causes a server timeout and fmxdbc_lisner.exe turns into a CPU/RAM eating monster if you use the ORDER BY clause for a large volume of recordset.
Try not to retrieve a large recordset by using SELECT.

The query response becomes worse if the found recordset is huge, even if indexed fields are specified in a WHERE clause.

How would you navigate records in a found set?

You may find some different ways to navigate records in a found set if you google it.
However, when it comes to FileMaker CWP, your options are quite limited after you consider those don't's we have already explained above.

Method 1: Use PDO scrollable cursors

Here is a sample php script for retrieving the last record in a found set using a PDO scrollable cursor.


<?php
      //sets up a connection

 try {



    $dsn= "odbc:Driver={FileMaker ODBC};host=127.0.0.1;Database=test";

    $pdo = new PDO( $dsn, "cgi", "pwd" );

    $pdo->setAttribute( PDO::ATTR_EMULATE_PREPARES, false );

    $pdo->setAttribute( PDO::ATTR_CASE, PDO::CASE_NATURAL );



 } catch ( PDOException $e ) {



    exit( "Database connection failed.". $e->getMessage() );



 }



      //builds a query string

   $sql = "select recId, invoiceNo from invoice";



      //prepares a PDO statement and runs it

   $stmt = $pdo->prepare(  $sql, array( PDO::ATTR_CURSOR => PDO::CURSOR_SCROLL ) );

   $stmt->execute();



      //retrieves the last record in a found set

   $record = $stmt->fetch( PDO::FETCH_ASSOC, PDO::FETCH_ORI_LAST );



      //script goes on using $record....



?>

PDO::ATTR_CURSOR => PDO::CURSOR_SCROLL defines a scrollable cursor, and PDO::FETCH_ORI_LAST moves the cursor to the last row in a found set.

You may also consider using the following predefined PDO constants:

PDO::FETCH_ORI_FIRST --- moves the cursor to the first row in a found set.
PDO::FETCH_ORI_ABS --- moves the cursor to the specified row in a found set. The absolute position is specified in the third argument.
Example: $record = $stmt->fetch( PDO::FETCH_ASSOC, PDO::FETCH_ORI_ABS,$absPosi);

For more information, please visit http://php.net/manual/en/pdo.constants.php

Method 2: Use FileMaker's OFFSET n ROWS and FETCH FIRST n ROWS Clauses

Here is a sample php script for retrieving the 5000th record in a found set using FileMaker's OFFSET n ROWS and FETCH FIRST n ROWS clauses.

<?php
      //sets up a connection
 try {

    $dsn= "odbc:Driver={FileMaker ODBC};host=127.0.0.1;Database=test";
    $pdo = new PDO( $dsn, "cgi", "pwd" );
    $pdo->setAttribute( PDO::ATTR_EMULATE_PREPARES, false );
    $pdo->setAttribute( PDO::ATTR_CASE, PDO::CASE_NATURAL );

 } catch ( PDOException $e ) {

    exit( "Database connection failed.". $e->getMessage() );

 }

      //defines the offset value of 4999
   $offset = 4999;
      //builds a query string
   $sql = "select recId, invoiceNo from invoice OFFSET ".$offset." ROWS";

$sql .= " FETCH FIRST 1 ROWS ONLY";


      //prepares a PDO statement and runs it
   $stmt = $pdo->prepare( $sql );
   $stmt->execute();

      //retrieves a record
   $record = $stmt->fetch( );

      //script goes on using $record....

?>

$offset = 4999 defines to go to the 4999th row in a found set.
FETCH FIRST 1 ROWS ONLY defines to retrieve one row.
Thus, the 5000th row will be set to $record variable.

The Response is SO Slow Whatever the Method is....

Practically speaking, requiring five seconds to retrieve JUST one record is simply ridiculous.
But unfortunately this happens with FileMaker CWP when tables get bigger.

We have created sample scripts using those two data retrieving methods to navigate records in a found set, in order to show you how slow the FileMaker server response gets.

Method 1: Using PDO scrollable cursors

First button

The response is fairly good since the query does not have a WHERE clause.

Next button

It took 5.3859 seconds just to show the second record out of 939,623 records.
This outcome is pretty disappointing but this happens when the query has a WHERE clause and the found set is huge.

In this example, cRecId > 17538 results in 922,084 records and FileMaker Server's response goes slow, even though cRecId field is indexed.

Previous button

It took 5.4028 seconds when clicking Previous button to retrieve the previous record from the very last position.
This is another disappointing outcome because this huge found set caused the slow response.

In this example, cRecId < 957160 results in 939,622 records and FileMaker Server's response goes slow, even though cRecId field is indexed.

Last button

The response is alright, since the query does not require a WHERE clause.

Method 2: Using FileMaker's OFFSET n ROWS and FETCH FIRST n ROWS Clauses

This method requires two separate queries:

A query to get the record count from a table with SELECT clause.
A query to set the starting position (offset) in a found set and fetch the specified number of rows of records.

Performing two queries does not appear to be a very smart, however, there is no better way to know how many records there are in a table(especially when you want to know the total record count), and then perform OFFSET and FETCH ONLY n ROWS clauses.

First button

It took 1.0043 seconds to get the first row.
Please note the first query (QUERY1 in the figure below) does not have a WHERE clause.

Next button

It took 5.7659 seconds just to show the second record out of 939,623 records.
In this example, the first query's (QUERY1 in the figure below) cRecId > 17538 results in 922,084 records and FileMaker Server's response goes slow, even though cRecId field is indexed.

Previous button

It took 6.854 seconds when clicking Previous button to retrieve the previous record from the very last position.

In this example, the first query's (QUERY1 in the figure below) cRecId < 957160 results in 939,622 records and FileMaker Server's response goes slow, even though cRecId field is indexed.

Last button

It took 2.0451 seconds to get the very last row.
The first query (QUERY1 in the figure below) does not have a WHERE clause, so the response is faster than the Next and Previous buttons.

(亀/turtle)

2016-07-14

FileMaker によるレスポンシブな出庫画面プロトタイプ

　FileMaker をバックエンドに使用したレスポンシブな出庫画面を作ってみました。invoice.php という一つのファイルで PC、タブレット、スマホ（Androidを含む）に対応しています。FileMaker のようにデバイス毎にレイアウトを用意する必要が無いところが良いところです。　いまのところ照会専用（更新不可）です。しばらくの間、下記で公開しますので、興味のある方はお試しください。

レスポンシブな FMEasy在庫プロトタイプの試用会場へ
（しょっちゅう弄っているのでエラーを起こすことがあります。スミマセン。）

Windows Edge

　以下では本プロトタイプの諸機能を説明します。が、まだ照会部分がおおよそできただけで、動作しないモノが多いです。また、エクストリーム・プログラミング（別名：行き当たりバッタリ開発）っぽく開発しているので、ここに書いてる仕様は無かったことになる可能性もあります＞＜。ご了承ください。

オブジェクトのスライドと伸縮

以下は iPad Air 2 を横置した場合と縦置した場合です。スクリーンの幅が狭くなると右側にある［伝票番号］などのオブジェクト群が下にスライドします。また、オブジェクトによっては、左右に伸縮します。

iPad Air 2, Safari

表示項目数が変わるアコーディオンメニュー

　同じデバイスでもスクリーン幅に応じて、縦置き、横置きでメニューに表示される項目数が変化します。下図左は Nexus 7 Android 縦置の画面になりますが、同じNexus 7 でも横置にするとメニューの項目数が増えます（図右上）。上下にスクロールしてもこのメニューは常時表示されますが、メニューの左の青いバーをクリックするとメニューが折り畳まれ（下図右下）、商品情報表示を邪魔しないようにします。青いバーを再度タップすると、メニューは再度表示されます。

Nexus 7, Android

接続手段（ API ）について

　本プロトタイプには接続手段（ API ）を選択し、それぞれの実行速度を計測する機能が用意されています。選択できるAPIは以下の通りです。

FileMaker API for PHP
fx.php
FileMaker Server Custom Web Publishing with XML (以降 fm.xml)
PDO(ODBC)

　いずれも、バックエンドは同一のFileMaker Server で、アクセスするデータベースは同一の「FMEasy在庫 R1.5」となっています。

API の応答時間

　応答時間は、画面右上端に表示されます。

　
　この時間は、出庫データの問い合わせからページ表示までに要した時間を表しています。

APIの切り替え

　使用中の API 情報は、画面右上で確認できます。

　以下の例では、PDO を使用中で、このページの表示が完了するまでに 0.552 秒かかったことがわかります。

　API を切り替える場合は、メニューボタンエリアの右下端の

ボタンをクリック（タップ）します。
　すると、API 選択用のドロップダウンメニューが表示されます。メニューを展開させてから、希望の API を選択します。

　たとえば、FM API for PHP (専用)を選択すると、使用中の API が下図のように変更されます。

　API を切り替えてもデータの自動読み込みは行われませんので、

　ボタンを実行することによって、新しい API でのデータ読み込みを行ってください。
　尚、表示幅が狭く

ボタンが表示されない場合は、レコード移動用の

ボタンや

　ボタンを実行してください。

注：
上記のドロップダウンメニューで（既存）は「FMEasy在庫 R1.5」の既存のレイアウトを使用し、（専用）はWebアプリに不要な要素を排除し、レイアウトテーマに「クラッシック」を使用したカスタムWebに最適化されたレイアウトを使用しています。

出庫明細部

　出庫明細部（商品情報が繰り返し表示されるエリア）の表示項目は、［項目選択…］から選択することができます。お使いのデバイスのスクリーンに合わせて、表示項目を選択してください。

その他

　ボタンにはチップツールがついているので、PCでマウスポインタを合わせるとそのボタン機能がなんとなくわかりますが、現状、多くのボタンが開発中です＞＜

　左のボタンですが、ヘッダ部にある場合と、取引先や商品に隣接している場合があります。　ヘッダ部にある場合はクリックすると検索画面に移動するので、ユーザが検索条件を入力して実行すると検索結果が一覧表示され、目的のレコードを選択すると元の画面に戻り、選択したレコードが表示される仕様となります。一方、取引先や商品に隣接している場合は一覧表示されて選択するところまでは同様ですが、こちらの場合は選択した取引先（部署）または商品が入力されます（入力支援機能）。このあたりは、FileMaker Pro、インスタントWeb、WebDirect の機能に準じるものになる予定です。　

（亀）

関連記事： FileMaker でレスポンシブなWebアプリを作る

登録: 投稿 (Atom)

メニューバー

2016-12-06

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

テスト環境

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

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

CREATE テスト

DELETE テスト

UPDATE テスト

結論：

2016-12-01

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

テスト環境

Readテスト 1

Readテスト 2

Create テスト

Delete テスト

Update テスト

まとめ

2016-11-17

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

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

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

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

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

2016-08-30

Record navigation in FileMaker PDO Custom Web Publishing is so slow... why?

How would you navigate records in a found set?

Method 1: Use PDO scrollable cursors

Method 2: Use FileMaker's OFFSET n ROWS and FETCH FIRST n ROWS Clauses

The Response is SO Slow Whatever the Method is....

Method 1: Using PDO scrollable cursors

Method 2: Using FileMaker's OFFSET n ROWS and FETCH FIRST n ROWS Clauses

2016-07-14

FileMaker によるレスポンシブな出庫画面プロトタイプ

オブジェクトのスライドと伸縮

表示項目数が変わるアコーディオンメニュー

接続手段（ API ）について

API の応答時間

APIの切り替え

出庫明細部

その他

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