ラベル カスタム Web の投稿を表示しています。 すべての投稿を表示
ラベル カスタム Web の投稿を表示しています。 すべての投稿を表示

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/


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

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は以下の通りです。

  1. FileMaker API for PHP
  2. fx.php
  3. FileMaker Server Custom Web Publishing with XML (以降 fm.xml)
  4. 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 の機能に準じるものになる予定です。 


2016-07-06

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

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

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


この表からは、
圧倒的ではないか、カスタムWebは

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

開発環境

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


開発方針・目標

第1フェイズ


以下の方向で、FMEasy在庫の出庫関連機能をWebアプリ化→プロトタイプを作成する。
  1. マルチデバイス対応、RWD(Responsive Web Design)採用
    たとえばこんな感じで……。

    【PC利用時】

    Windows Chrome


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

    Nexus 7, Android, Chrome --- Portrait


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

    Nexus 7, Android, Chrome --- Landscape


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

    FreeTel Priori 3, Android, Chrome

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

第2フェイズ

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

第3フェイズ

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

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


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

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


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

(亀) 

2016-06-06

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 にアクセスしたときの問題点


(亀)