大容量のSQLテーブルもOK！ ― FileMaker 16 を帳票作成ツールとして使う

　FileMaker Server 16 （以下、FMS16）ではPDF出力をサポートするようになりました。FileMaker Pro はもともと帳票/レポートを簡単に作成できるツールして利用されてきましたが、サーバサイドでPDFが作成できるようになり、面倒なWeb帳票の設計・実装が実に簡単、且つ短時間のうちに行えるようになりました。　データベースは FileMaker でも SQL/XMLデータベースでもOKです。　本稿では MySQL の1500万件のテーブルからデータを抽出し、遅延無くPDFを出力する方法の概要を記します。

開発・運用環境

FileMaker Pro (Advanced) 16　―　帳票作成ツール*1
FileMaker Server 16/IIS/PHP　―　サーバ*2

　*1 帳票を作り、簡単なスクリプトを書くだけであればFileMaker Pro 16(￥4万前後)で事足りますが、複雑なスクリプトを書くには開発用（デバッガ付）の FileMaker Pro Advanced （￥7万前後）が必要です。
　*2 FileMaker Server 16 はFM社直売で￥99,000 （税抜）です。

　FileMaker Server 16 （の カスタムWeb公開 ＝CWP）の理論上の最大接続数は 2,000、検証接続数は500 ですので（詳細はこちら）、￥20万弱で本格的な帳票開発・運用環境が構築できる可能性があります。

本稿の目的と概要図

Webブラウザ上でから 入出庫システム（バックエンドはMySQL）にアクセスし、入庫伝票をPDF形式で作成・表示することを目的とします。　帳票を構成するテーブルに1000万件単位レコードが存在する場合にも、ユーザにストレスを与えない程度の実行速度で、入庫伝票PDFを表示することも目指します。以下が実装手法の概要図となります。

実装手法

入出庫明細テーブルには 約1500万のレコードがあります。　FileMaker で数十万件を超すテーブルからデータを抽出してPDF帳票を遅延無く作成するには、上図の FMS ⇔ MySQL 間の設計がキモとなります。今回は一般的な FileMaker ESS（External SQL Source 機能）を使う手法 と、原始的な ODBC データ取込を使う2つの手法を実装・テストしました。

実装手法1　―  FileMaker ESS を使用 　データ件数が多くなると低速化する

1. 本手法では ESS を使用し、MySQLのテーブルを FileMaker のファイル内に直接配置します。下図の「_入庫」や「_取引先_入庫」などがそれに相当し、これらはシャドウテーブルとも呼ばれます。

ESSは FileMaker 内から直接 MySQL のテーブルを読み書きでき便利なのですが、数十万行を超す大きなテーブルを扱う時には速度が低下するなどの問題があります。ESSの問題点については、古い記事になりますがこちらを参考にしてください。

2. 入庫伝票レイアウトの開発は FileMaker Pro (Advanced) のGUIを利用し、テーブル内のフィールドや罫線、テキストなどのオブジェクトを配置しながら作成すると、慣れた人なら 短時間で完成すると思います。　　

FileMaker Pro により作成した入庫伝票イメージ

3. 次に FileMaker のスクリプトメーカーで、PHP から渡ってきた入庫No による検索、入庫伝票レイアウトの選択、PDF保存などを行うスクリプト（「実装手法概要図」の「特定のスクリプト」）を作成します。
4. 最後に PHPファイルからそのスクリプトを実行するように指定します。

実装手法2　―　ODBCデータ取込 を使用　データ件数にかかわらず高速

1. 本手法では独立した FileMaker ファイルを一つ用意し、その中に FileMaker のテーブル（vw入庫伝票、下図参照）を用意します。
   
   このテーブルに MySQL から必要最低限のデータを取り込み、そのデータを FileMaker レイアウトを使用してPDF形式で出力します。
   
   注：ESS は使用せず、したがって MySQL のシャドウテーブルも配置しません。

2. MySQL側に入庫伝票に必要なテーブル（本例では、入出庫明細、取引先、入庫、商品の4テーブル）を結合した入庫伝票用ビューを作成します。
   
   
   ビューの作成は必須ではありませんが、ビューが無いとFileMaker内に4つのテーブルを用意し、4回SELECTクエリを発行して用意したテーブルに対応するMySQLのテーブルデータを取り込む必要があります。ビューを使用すれば、テーブル、クエリー、取込とも1つ/1回で済むので、実行速度的にも有利です。特別な事情がなければ、ビューを使用しましょう。
   
   
3. FileMaker を使用して入庫伝票レイアウトの作成します。テーブル構成が異なるので実装手法1とはその作成方法は異なりますが、FM開発者にとっては容易な作業と思います。
4. 次にPHPから渡ってきた 入庫No を使用し、 ビューに対して SELCTクエリーを発行し、結果を　vw入庫伝票テーブルに取り込み、入庫伝票レイアウトを選択して、PDFを保存するスクリプトを作成します。
5. PHPからこの FileMaker スクリプトを実行して、PDFを作成・表示する部分は実行手法1と同様です。

テスト結果

上記2つの手法による実装をブラウザからテストしてみました。HTTPリクエストからPDFが表示されるまでの時間は以下の通りです（テストは各5回ずつ実行し、その平均値を記載しています）。

実装手法1：　77秒
実装手法2：　1.2秒　

　その差は圧倒的でした。シャドウテーブルを配置するESSは、SQLクエリーの発行を FileMaker がすべてやってくれるので便利な反面、膨大なクエリーを発行するため速度低下を招きます。　その点、 ファイル内にESSシャドウテーブルを配置せず、SQL SELECT文を自身で指定し、その結果を FileMaker テーブルに取り込む ODBCデータ取込は大きなSQLテーブルに対しては圧倒的に有利です。

思ったこと

実装手法2であれば、数千万件のデータを持つSQLデータベースの帳票作成環境として、その使用に耐えそうです。　実装手法1は10万～20万件程度のテーブルであれば利用可能と思われます。

本稿では SQLデータベースを取り上げましたが、旧FileMaker Server の Webシステムを温存しつつ、下図のように　FMS16 を併行運用し、FMS 16 は PDF出力用サーバとして使用する方法も考えられます。

PDF出力をしたいが、 FM16へのアップグレードはできない場合、検討の価値はあるかと思います。

（土屋）

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

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

Hyper-V VMを使用しFileMakerスタンバイサーバーのテスト環境を構築する

　FileMaker Server 14 でスタンバイサーバーが導入されたことにより、システムメンテナンス時や障害時にもすみやかに FileMaker データベース作業を再開できるようになりました。


　スタンバイサーバー - 概要


　プログレッシブバックアップを利用した現用系（プライマリ）と予備系（スタンバイ）のサーバ切替が可能になった分、突然のデータロスの可能性を低減できることは大きいと思います。

　しかしながら、切替制御が自動でないため、人為作業がどうしても発生してしまう点や、緊急時に FileMaker Server 管理者が対応不能の場合に作業が一時中断してしまう点などの問題は残りますので、緊急時の作業規則をあらかじめ社内で決めておくことが大切です。

　今回は、Windows OS で FileMaker Server 14 のスタンバイサーバー機能の動作検証を行いたい方のために、スタンバイサーバーのテスト環境を Hyper-V の仮想マシンを使って手っ取り早く構築する方法をご紹介します。

Hyper-V 上の仮想マシン（VM）のイメージ ― 1台のホストOS上で複数のVMを運用する

準備するもの

1. Hyper-V サービスがインストールされたコンピュータ 1 台
　今回は Windows Server 12 を使用しています。

2. FileMaker Server 14 が動作する Windows Server ライセンス 2 つ
　今回は Windows Server 2008 R2 を使用しています。

3. FileMaker Server 14 ライセンス 1 つ
　スタンバイサーバーを構成する場合、必要な FileMaker Server 14 のライセンスは1つのみです。

Hyper-V 環境の構築方法

1. 一台めの仮想マシンを作成してから仮想ハードディスクを接続します。
　その後、Windows Server OS と　FileMaker Server 14 をインストールし、必要なデータベースファイルを Data/Databases ディレクトリの中に入れておきます。

新規仮想マシンと Windows Server OS および FileMaker Server 14 のインストール

ポイント：
　― Windows Server の IP アドレスを正しく設定し、Windows 認証を済ませておきます。
　― FileMaker Server 14 をインストールしたら、すぐにプログレッシブバックアップ設定をしておきます。



　このとき、プログレッシブバックアップ先のパス名の指定を忘れないようにしてください。
　上図では便宜的に filewin:/C/FMSProgBkup/ を指定してあります。

2. 一台めの仮想マシンをシャットダウンします。
そして、仮想マシンから仮想ハードディスクを削除（切断）します。

仮想マシンから仮想ハードディスクを切り離す

3. 仮想ハードディスク1 (VHD1) を複製して仮想ハードディスク2(VHD2=スタンバイサーバー用VHD）を作成します。
 Windows Server OS と FileMaker Server 14 がインストールされた状態の仮想ハードディスクを複製するため、インストール作業の二度手間を大幅に省くことができます。

仮想ハードディスクを複製する

4. 一台めの仮想マシンに仮想ハードディスク1(VHD1)を再接続し、無事に起動してきたら、二台めの仮想マシンを新規作成し、仮想ハードディスク2(VHD2)を接続し、同様に起動します。

仮想マシンを新規作成して、二台の仮想マシンを稼働させる

ポイント：
　― Active Directory に参加しているサーバを複製した場合は、二台めのサーバはドメインに参加できなくなります。
　このため、一旦ローカルログインし、IP アドレスの変更、コンピュータ名の変更、ワークグループへの切り替えを行ったあとで仮想マシンを再起動し、再度 ActiveDirectory に参加するようにする必要があります。

参考記事：ドメインにログインできなくなって泣かされる

　― Windows OS は新たに仮想ハードディスクを接続すると、Windows 認証作業が必要になります。
　　ボリュームライセンス利用者の場合は、「自動ライセンス認証が始まるまで XX　日です。今すぐ行う場合はここをクリックしてください」をクリックし、指示どおりに操作します。



　シングルライセンス利用者の場合は、「プロダクトキーの変更」をクリックして、二台めの Windows ライセンスを入力します。

　― FileMaker Server 14 のプログレッシブバックアップの設定はプライマリサーバと共通になるので作業は不要です。FileMaker Server に付ける名前だけ変更すれば OK です。

FileMaker Server 14 スタンバイサーバーの設定方法

1. プライマリサーバの公開済データベースを全部閉じます。

　コマンドプロンプトから以下のコマンドを入力します。

fmsadmin standby connect スタンバイサーバーの名前または IP アドレス

　接続およびログインに成功すると、8桁のセットアップコードが表示され、待ち状態となります。
　このセットアップコードをメモしておきます。


2. スタンバイサーバー側でコマンドプロンプトを開き、以下のようにセットアップコードを入力します。

fmsadmin standby accept XXXXXXXX

ログイン成功後、スタンバイサーバー切替のメッセージが出るので y を選択後、ログインします。

3. プライマリサーバに戻り、待ち状態のコマンドプロンプトで Enter キーを押すとスタンバイサーバーへの接続が完了します。

ポイント：
　― スタンバイサーバーでセットアップコードを入力して受理されたものの、セットアップコードが不正だった場合は Enter キーを押すとエラー終了になります。この場合は、手順 1. のコマンド入力からやり直してください。

4. プライマリサーバのコマンドプロンプトで、以下のコマンドを入力します。

fmsadmin standby update

　ログイン成功後、プライマリサーバのデータベースがスタンバイサーバーの公開データベース環境にコピーされます。

5. プライマリサーバのデータベースを再度公開します。

　すると、プライマリサーバとスタンバイサーバーのデータベース同期が行われるようになります。

　このとき、スタンバイサーバーの FileMaker Server Admin Console を開こうとすると、以下のように待機状態であることが確認できます。

　スタンバイサーバーのさらに詳しい設定方法および、スタンバイサーバーの動作確認方法（メンテナンス時、障害発生時のサーバ切替）は、FileMaker 社の公式動画がおすすめですので、ご覧になってみてください。

おまけ： FileMaker Server 14 プライマリサーバとスタンバイサーバの同期関係を解除する方法

　これまで、FileMaker Server 14 でプライマリサーバとスタンバイサーバーで同期が取れるように設定しましたが、逆に同期を解除したいという要望も出てくることでしょう。

　そのようなときは、プライマリサーバ側でコマンドプロンプトより以下のように切断コマンドを入力します。

fmsadmin standby disconnect

　本当にスタンバイサーバーを切断してよいかと聞いてきますので、y を選択し、ログインすると、スタンバイサーバーとの接続が切断されます。

　これにより、今までスタンバイサーバーだった FileMaker Server 14 はスタンドアロンサーバとして動作するようになります。

以上

（亀）

FileMaker バックアップ関連記事：

データベースのバックアップ方法
FileMaker Server のプログレッシブバックアップ機能の考え方と使い方


Hyper-V 関連記事：

Hyper-V の仮想マシンの移行方法（エクスポート＆インポート）
Hyper-V の仮想マシンのエクスポート時の注意点
物理マシンを Hyper-V 仮想マシンに移行する（P2V）
Hyper-V のゲスト OS を起動しようとすると、「一般のアクセスが拒否されました」というメッセージが表示される
計画停電対策(1) --- ノートPCサーバとHyper-Vで乗り切る

【関連する土屋企画の講習】
FileMaker Server とバックアップ(対象者：中級、5時間×1日)

新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 関連記事を読む

（亀）