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 の機能に準じるものになる予定です。　

（亀）


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

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、ｊQuery Mobile
対応デバイス： PC、タブレット、スマホ（非iOSデバイスを含む）

開発方針・目標

第１フェイズ

以下の方向で、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出力機能作成

第２フェイズ

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

第３フェイズ

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

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

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

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

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

（亀）　

WebDirect 14 vs 15 ― JMeter による負荷テスト

　FileMaker インスタント Web の後継版として、FileMaker 13 より WebDirect （以下、WD）が登場しました。インスタント Web に比べ、 WD の操作性はより FileMaker Pro に近づいたものの、パフォーマンスや安定性にかなり問題があるんじゃないか、みたいなことを約1年前に記事にしました。 その折は、WD13 と WD14 の2つのサーバ上で、複数のクライアントPCを用意し、各PCで複数のブラウザウインドウを開いた状態で、それぞれのウインドウからスクリプトを手動実行して負荷をかける、というものでした。
　今回は Apache JMeter （以下、JMeter）というパフォーマンステストツールを使用し、WD14 と WD15 のパフォーマンス比較をしたので、以下にその内容をレポートします。WD の採用を検討されている方の参考になれば幸いです。

テスト内容と結果

　今回のテストでは、小社製品「FMEasy在庫 IWP/WD R1.5」を使用し、出庫伝票を作成するスクリプトを作成。JMeter によりこのスクリプトを 25 のセッションで 10 回ずつ実行し、その所要時間を測定するとともに、CPUの占有状況を観察しました。　また、このテストは FileMaker 14 と 15 の双方で行うとともに、サーバのリソース（コア数とメモリ）を増やすことにより、パフォーマンスがどの程度改善するかも測定しました。

仮想サーバ構成

　CPU： 3.0Ghz
　コア数/メモリ： 1core/2GB、2core/4GB、4core/8GB　の3パターン
　Windows Server 2012 R2 (64bit)

JMeterシナリオ

　JMeter により、「FMEasy在庫 IWP/WD R1.5」の出庫伝票を1つ作成後にログアウトするスクリプトを以下のシナリオに基づき実行。　

　Threads： 25
　Loops：10
　Ramp-up：1sec
　Pause： 1sec or 1.5 sec

注：

• Pause を設けずにシナリオを実行すると、ログアウトを待たずに次々にセッションが実行され、最大同時接続数25を超過するエラーが発生して伝票作成に失敗するため、WD15 では 1 秒、WD14 では 1.5 秒 の Pause　時間を設けました。両者で 0.5 秒の差があるのは、WD14 を 1 秒で設定すると、同様のエラーが多数したためです。この点からも、WD15 のパフォーマンスが改善していることがわかります。
• シナリオ実行後は出庫伝票が 250 個作成されていることを目視で確認しています。未作成レコードがある場合、下表に記載しています。

テスト結果

WebDirect 14 vs 15 出庫レコード作成時のパフォーマンス（Fails は作成に失敗したレコード数）

Peformance comparison graph on CPU cores and memory

考察

※WD14 vs WD15 の比較

　サーバリソースにかかわらず、WD15 は WD14 に比し、30%程度実行速度が改善されました。

※サーバリソースと実行速度の改善

　サーバリソースを 1core/2GB から 2core/4GB に増やすと、WD15 で約 50%、WD14 で約 40%、実行速度が改善されました。
　さらにリソースを 2core/4GB から 4core/8GB に増やすと速度は改善されたものの、改善率はそれぞれ 20%弱と 15%弱となりました。このことから、リソース割り当てを増やせば実行速度は改善するが、その改善率は徐々に鈍化するものと推定されます。

　

※ CPUの占有率

　以下の図は JMeter 実行時の CPU 占有率です。　1コアの場合、CPU を使い切ってしまうことが多々ありました。やはり、CPU 占有率が 100%になるような状況は避けたいです。リソースを増やすに従い、CPU の使用率は下がります。


FM WebDirect 15

1 Core / 2 GB RAM

CPU 占有率が 100% に達する状態が続く。同時アクセスユーザが集中する可能性のあるサーバは要注意。

2 Core / 4GB RAM

4 Core / 8GB RAM

---

FM WebDirect 14

1 Core / 2 GB RAM

長時間にわたり高負荷状態が発生。WD15 に比べると処理により多くのサーバリソースを消費することがわかる。

2 Core / 4GB RAM

4 Core / 8GB RAM

JMeter テスト環境と運用環境の違い

　最後にJMeterテスト環境と実際の運用環境との違いについて簡単に触れます。下図左のグラフは JMeter でにより伝票作成スクリプトを 1 セッションで 1 回実行したときのもので、右のグラフはブラウザ上から手動により伝票作成スクリプトを1回実行したときのものです。サーバのリソースは共に 1core/2GB です。 JMeter では CPU のピーク時の占有率が約 20%であるのに対して、ブラウザでは 80％弱となっています。

　今回は WD14 と WD15 の比較とサーバリソースの増減によるパフォーマンスの変化をテーマとしているためあまり問題ではないと思いますが、実際の運用環境を JMeter によりシミュレートしようとする場合は、JMeter のシナリオを如何に運用環境に近づけるかが大きな課題となります。ただ、JMeter は実行するタイミングによってパフォーマンスにばらつきが出たり（実機でもそうですが）、シナリオを WD の運用環境に近づけるのはかなり難しかったりするため、その差分を係数化し、JMeter ではその係数分の負荷を余計にかける、などの補正が必要かもしれません。
　たとえば、下図のような状況であれば係数を 0.25 とし、運用環境で 20 ユーザが 10 秒間に 1 回レコード保存を実施すると想定されるのであれば、Ramp-up は 10 秒ではなく、2.5 秒に設定し、必要な回数のループを実行する、というのは一案と思われます。　


　それでも納得できないお客様に遭遇してしまった場合ｗは、必要台数分の仮想マシンや VDI 環境を用意し、FileMaker スクリプトを各仮想マシンから一斉に実行するような仕掛けが必要になるかもしれません。
　

その他の情報

ここでは、今回の JMeter による WD パフォーマンス測定で得られたその他の情報をまとめます。

1. JMeter で WebDirect にリクエストを発行すると、タイムスタンプが狂う
   
   レコード作成日時を記録するためのフィールドをタイムスタンプ型にしておくと、JMeter 経由で WD のレコードを作成／修正すると、タイムスタンプが協定世界時刻（UTC）になってしまうことがあります。
   
   

   

   この設定では、JMeter 経由でのレコード作成時に協定世界時が記録されてしまう

   
    つまり、日本時刻では 9 時間のズレが生じることになりますが、以下のようにホストのタイムスタンプを自動入力させることでこれを回避できます。
   
   

   

   Get( ホストのタイムスタンプ ) を計算値として自動入力することで時刻の狂いを回避

   
   または、Get ( 現在の時刻 UTC ミリ秒 ) を使って日本時間を算出することもできます。
   
   計算式：
   GetAsTimestamp ( ( Get ( 現在の時刻 UTC ミリ秒 ) + ( 9 * 3600000 ) ) / 1000 ) 
   
   
2. WD14 と WD15 の挙動の違い
   
   WD14 でレコードを作成したり、修正したりすると、FileMaker で記録されるユーザ名は [WebDirect] ですが、WD15 では [WebDirect-XXXXX]という形式でユーザ名が記録されます。
   
   この XXXXX の部分は WD 実行時のセッションID（32桁、16進数文字列）の最後の 5 桁となり、各 WD ユーザを識別しやすくなっているといえるでしょう。
   
   FileMaker Pro 15 のヘルプにもこの解説がありますので、興味のある方は参考にしてみてください。
   
   Get ( ユーザ名 ) の説明
   Get ( 持続 ID ) の説明
   
   

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

(亀)