WebDirect は 16 で実用段階に近づくか？ ― JMeter による WebDirect 14/15/16 比較

　FileMaker 16 が 2017 年 5 月 10 日にリリースされました。　この新バージョンで小社が注目しているのは

　　　1.WebDirect 16 の実行速度と安定性の向上
　　　2.FileMaker  のSQLデータソース用帳票ツールとしての利用

の2点です。今回は上記1について調べてみました。

　FileMaker Server 13 で搭載された WebDirect （WD）は、当初はサークルアイコンが出っ放しになった末に無応答になるなど、導入を躊躇させる機能でしたが、リリースを重ねるごとに安定性が向上しているという感じはします。　そこで、今回は若干の期待をしながら FileMaker Server 16 の WebDirect のパフォーマンステストを行いました。

　前回の WebDirect のパフォーマンスに関する記事は、こちらをご参照ください。

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

　今回も、前回と同様に Apache JMeter （以下、JMeter）というパフォーマンステストツールを使用し、WebDirect （WD）16 のパフォーマンスを調べました。
　以下にその内容をレポートします。前回の実験で使用した WD14 および WD15 のデータもともに掲載してありますので、WD の採用を検討されている方の参考になれば幸いです。

テスト内容と結果

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

仮想サーバ構成

　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

注：

• WebDirect 14 および WebDirect 15 のテストデータは前回計測時のものを使用しています。
• Pause を設けずにシナリオを実行すると、ログアウトを待たずに次々にセッションが実行され、最大同時接続数25を超過するエラーが発生して伝票作成に失敗するため、WD15/WD16 では 1 秒、WD14 では 1.5 秒 の Pause　時間を設けました。両者で 0.5 秒の差があるのは、WD14 を 1 秒で設定すると、同様のエラーが多数したためです。
• シナリオ実行後は出庫伝票が 250 個作成されていることを目視で確認しています。未作成レコードがある場合、その数を下表の「Fails」列に記載しています。

テスト結果と考察

WD 14、WD15 及び WD16 出庫レコード作成時のパフォーマンス（Fails は作成に失敗したレコード数）

　過去の計測では、エラーによりレコードが作成されないことがありましたが、WebDirect 16 では連続アクセスを行ってもエラーの発生はありませんでした。

Peformance comparison graph on CPU cores and memory

※総評

　WD16 は WD15 に比し、2%～35%、実行速度が向上しています。サーバリソースの割り当てを増やすと、その差は顕著になります。
1core/2GBでは WD16 と WD15 間で実行速度の差は 2% とほとんど改善は見られませんでしたが、1core/2GB から 2core/4GB に増やすと 24%、 2core/4GB から 4core/8GB に増やすと35%改善しました。　コア数/メモリの割り当てがチューニングのキーとなる可能性があります。
　ただ、前回テスト時と同様に、リソース割り当てを増やすに従って、その改善率は徐々に鈍化するものと推定されます。

　

※ CPUの占有率

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



WebDirect 16

1 Core / 2 GB RAM

WD16 のときと同様に、CPU 占有率が 100% に達する状態が続く。しかも長い。よって同時アクセスユーザが集中する可能性のあるサーバは要注意

2 Core / 4GB RAM

WD15 に比しCPU占有率が高くなっているが、その分占有時間は短くなっている

4 Core / 8GB RAM

WD15に比しCPU占有率が高いが、その分占有時間は短くなっている

---

WebDirect 15

1 Core / 2 GB RAM

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

2 Core / 4GB RAM


4 Core / 8GB RAM

---

WebDirect 14

1 Core / 2 GB RAM

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

2 Core / 4GB RAM

4 Core / 8GB RAM

まとめ

FileMaker Server 13 がリリースされた頃の WebDirect は動作が不安定で、とても実用に耐えないと評価しましたが、今回は25台の仮想マシンから計250のレコードを一斉作成するテストを5回実行しても一度もエラーが発生しませんでした。　WebDirect は運用に耐えうるレベルに達しつつあるというのが今回の実感です。
　また、WebDirect からの PDF 出力も可能となりましたので、 FileMaker Pro クライアントの代わりに WebDirect を導入するという選択肢も視野に入ってきたように思います。

　ただし WebDirect と数多あるブラウザとの互換性の問題は依然存在しますし、ページをリロードすると画面が初期状態に戻ってしまうという現象も依然として発生します。
　また、WebDirect には不向きな処理（例：バッチ処理）を実行した場合に無応答状態になる可能性も解消したとは言い切れません。　WebDirect の設計に当たっては、通常処理とサーバサイドスクリプトに割り当てる処理の切り分けが重要になるかも知れません。
　WebDirect のクリティカルなシステムへの適用は、十分な設計とテストが必要と思います。

補足情報：拡張アクセス権限の変更について

　FileMaker Server 16 の WebDirect 環境で、 URL にスクリプトを指定して実行する場合は、当該のアカウントの拡張アクセス権限で「FileMaker WebDirect によるアクセス(fmwebdirect)」に加え、 「URL による FileMaker スクリプトの実行を許可（fmurlscript）」を有効にする必要があります。

　このオプションが有効になっていないと、実行時に以下のような権限不足エラーが発生します。

　不特定ユーザが使用する環境においては、この辺りのセキュリティに配慮してプログラムしないといけませんね。

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

(亀)

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の導入事例を渉猟す

　WebDirect の導入に際してやはり気になるのは先行する導入事例。　
　小社でも時たま導入事例の紹介記事を探していますが、記事は多くありません。

　FileMaker 13 の WebDirect は、FileMaker Pro レイアウトのレンダリングが魅力的である反面、動作条件の厳しさ（高スペックなハードウェアの要求）、デザイン時に考慮すべき点の多さ、実行速度の問題など、機能的にはまだまだ発展途上という感じでした（これらの問題については、WebDirect 開発の勘どころ　をご参照ください。）


　そんな折、2015年5月13日に FileMaker 14 が発売になりましたが、やはり WebDirect の進化に注目が集まるっているようですね。

　ということで、小社では改めてWebDirect(WD)の導入事例を探してみました。
　以下は見つかった記事の要約、編訳となります。　

※WebDirectが2013年12月にお目見えしてから1年半。まだまだ導入事例は少ない感じです。Ver14で状況は変わるのでしょうか。

【WebDirect の導入事例】

1. Braun Electric Company, Inc. （米国カリフォルニア州）

　電設会社。
　435人以上の従業員の安全を FileMaker Go for iPad/iPhone で管理。
　SeedCode 社の GoMaps プラグインを併用し、従業員の現在地を GoogleMap で確認。

　今後は複数の業務処理の自動化に向けて、WebDirect を導入していく“予定”とのこと（予定なんで、これ、全然導入事例ではないです。GoMapsがCooｌそうなんで、思わず載せました。すみません）。

　参照元：http://www.filemaker.com/solutions/customers/stories/braun-electric-company.html　
　参考リンク：　GoMaps プラグイン（英語）

2. Annex Medical, Inc. （米国ミネソタ州）

 　医療用精密機器製造会社。
　従業員数 20人。
　社内のシステムを FileMaker Go for iPad でフル活用。
　品質記録、検品、工数管理、原料管理、在庫管理、配送、送り状作成までをトータルに行っている。

　作業効率化のためにダッシュボードをWebDirect で公開し、従業員の作業工数をチェックできるようになっている。 

　参照元：http://www.filemaker.com/solutions/customers/stories/annex-medical-inc.html

3. Cure Kids (ニュージーランド・オークランド)

　児童健康研究所。

　乳幼児突然死のリスク計算アプリを WebDirect メインで開発。

　データ入力を行うと、瞬時に死亡率のリスク計算ができるところがウリ。　
　開発期間が数週間だったにもかかわらず、ここ一年間で大きな修正はない。
　今後はカスタム開発を行い、ソリューションを完全レスポンシブな Web アプリケーションに発展させる予定（うーん、このWDソルーションはCWPソルーションに置き換わるのか。　WDで超高速開発して急場を凌だり、あるいはWDでプロトタイプを作成してエンドユーザに試用してもらう。で、本番システムはCWPで開発、みたいな）。

　参照元：http://www.teamdf.com/work/cure-kids
　開発元：http://www.teamdf.com/

---

【WebDirect 導入の具体例を示しているエンドユーザ】

1. Beko BBL　（ドイツ・ケルン）

　プロバスケットボールリーグ。
　32 人の審判と 10 人のスタッフ監督で運用中。

　全国バスケットボールリーグの所属審判を WebDirect および FileMaker Go で管理。

　（動画はドイツ語）

　
　スケジュール、評価、目標達成度、その他要素を含むすべての関連データを iPhone またはiPad で審判に公開。
　審判は、どこにいても iPhone または iPad を使い、 WebDirect　や FileMaker Go 経由でシステムにアクセスしてデータ入力可能。
　
　一元管理された目標達成やその他要素を含む情報は、リーグ管理者および審判が人選に利用。

　FileMaker プラットフォームで審判データベースを開発することにより、人材管理を実現。
　所在地情報をはじめ、年間出場試合数、身体データ、資格情報、関連情報、一般・技術審判の区分などを含む試合関連情報に関する個人データを管理。

　参照元：http://www.filemaker.com/de/solutions/customers/stories/bbl.html　

2. Akubra Hats （オーストラリア・ニューサウスウェールズ州）

　服飾品製造業。
　
　生産管理・受注管理に会計パッケージを統合させたシステムを FileMaker プラットフォームで開発。
　新たに導入されたレポート機能によって、季節ごとの商品在庫レベルを把握しやすくなり、在庫回転率が向上。
　早期受注にも対応でき、受注状況の確定も迅速化。

　システム導入後、一年間で受注レコード 2万件（受注明細レコード数 25万件、関連サイズ別レコードも含めると 56万件）を管理。
　工場および事務処理の一日 20 時間相当の業務をこのシステムで実現。
　今後のシステム最適化により、さらなる業務効率化が期待される。

　FileMaker Go と FileMaker WebDirect の併用により、モバイル顧客および遠隔顧客のニーズにも対応。
　また、2015 年の小売業者向けオンライン受注システム導入に向けて WebDirect によるモジュールをテスト運用中。


　参照元：http://www.filemaker.com/au/solutions/customers/local_stories/akubra-hats.html
　

3. サンラモン市街化区域（スペイン）

　都市開発事業。

　マドリードの民間開発区域、サンラモン市の 2000人の居住者を、18人の従業員により24時間体制で監視するシステムを運用。
　一日 3 シフト制でサンラモン市内を監視。
　訪問者・車両登録処理を含め、地域の安全を目指すのが基本目的。
　
　FileMaker Go および WebDirect によるアクセス。

　email を利用した居住者自宅訪問の実現。
　FileMaker Go for iPad を使ったレコード承認、訪問スケジュール管理
　WebDirect を使った居住者データベース管理
　
　より安全でシンプルな承認作業と堅牢なアクセス管理を実現。

　居住者に公開しているデータベースは二種類。
　居住者連絡先詳細データベースは地域事務所が WebDirect を使って更新。
　登録車両情報データベースは居住者自身が編集可能。

　訪問者がある場合は、e-mail または SMS で訪問者情報を監視員に送信。
　これにより 訪問者登録に要する時間を98% 削減。

　FileMaker Go for iPad による訪問者登録処理が可能になり、業務が簡略化されるとともにセキュリティログの記録量が 300% 増加。


　参照元：http://www.filemaker.com/es/solutions/customers/local_stories/Ciudad_San_Ramon.html

---

【WebDirect を使ったソリューションを提供している業者の開発例】

1. Contraflow （オーストラリア）

　道路交通網関連団体の計画作業と管理サービスを提供するシステムを構築。
　150人の従業員による内勤作業・オンサイト作業の両方に対応したあらゆる管理業務向けのソリューション。

　25 人の FileMaker Pro ユーザ、80人の FileMaker Go ユーザ、関連会社 5 社による WebDirect アクセスによりシステムを運用。

　【導入効果】
　コンプライアンスと安全性の向上、監査時不適合案件の減少、
　ワークフローのペーパーレス化。即時更新、各ステージの時間短縮、
　カオス化の完全排除、効率化されたプロセス、　自動 SMS 送信により電話による通話を廃止
　拠点呼び出しの時間と労力の削減、給与計算の自動化
　回転率の予測作業の迅速化と単純化、人員管理、必要車両とVIP 客の特定


参照元： http://info2.filemaker.com/Contraflow_Contraflow.html

2. SeedCode Calendar for WebDirect　（米国）

　WebDirect 対応の FileMaker Pro 向けカレンダープラグイン。
　カレンダーの週間表示、月間表示、　テーマ切替、ガントチャート表示などに対応。

（動画は英語）

　その他詳細は SeedCode 社の製品ページをご参照ください。
　SeedCode Calendar for WebDirect

弊社でも FileMaker 13 版 WebDirect 対応の在庫管理テンプレート製品『FMEasy在庫IWP/WD R1.5』を販売しております。

FMEasy在庫 IWP/WD R1.5 製品紹介ページはこちら
 
※この動画には WebDirect の動画部分は含まれていませんm( _ _ )m　インスタントWeb（IWP）の動画となっております。　14も出たことだし、WD部分の動画も作ろうか、と思う今日この頃です。
 　

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

(亀)

Big Table Handling Model in FileMaker/MySQL Environment ― Tentative one

The ordinary FileMaker development model may be not effective for handling big SQL tables.
In this post, we will try to find out clues for handling big tables at a tolerable speed while avoiding the weird application behavior that is unique to SQL big tables.

Definition of terms

Big tables: MySQL tables with more than 10 mil. rows
FileMaker/MySQL development: development using FileMaker for frontend, MySQL for backend
Filemaker-alone development: development using FileMaker for both frontend and backend

Problems of FileMaker's common interface

FileMaker provides the common interface for both FileMaker-alone development and FileMaker/MySQL development, which make it possible that developers can use the almost same method in FileMaker/MySQL development as in FileMaker-alone development.

This is very nice, but as data of MySQL tables grow up, application users will notice a performance slowdown, the application's behavior will become so weird (FileMaker issues a lot of redundant and incomprehensible SQL queries), and operation may become almost impossible.

The following model is a tentative one for mitigating such problems:

Big Table handling model in FileMaker/MySQL Environment

The figure below illustrates how to handle database objects.
.

1. On MySQL, duplicate big tables and rename them as rpl_originalTableName which are used for replicating records SELECTed by users from original big tables.
2. In FileMaker relationship graph, place only small tables and Rpl. Tables (do NOT place any big tables as it causes slowdown).
3.  Create stored procedures in MySQL to SELECT records in big tables and replicate them to Rpl. Tables, and INSERT/DELETE/UPDATE them whenever related records in Rpl.Table are inserted, deleted or updated. The stored procedures are executed from FileMaker's layout.

Common Model vs Big Table Handling Model

The following table indicates the comparison of the common model which is commonly used in FileMaker application development and the Big Table Handling Model(BTHM) based on the figure above.

	Common Model	BTHM	Remarks
Fast development	Yes	No
Ease of operation	Good	No so good
Performance for big tables	Very poor	Good
Weird behaviors	Many	Minimum
Records order	Weird	OK	Maybe detailed later

Note:
BTHM may not be appropriate for the found set of over 0.1 million, and may not be appropriate for the large number of simultaneous users.



The above two models plus 1 are illustrated in the following video.





N. Tsuchiya

『FMEasy在庫』 のバックエンドを MySQL に変える（２） ― 在庫

　本稿では、リリース予定の『FMEasy在庫 on MySQL R1.5』（仮称）の商品画面の在庫に関して説明いたします。

　以下が商品画面となります。

　『FMEasy在庫 on MySQL R1.5』では、2つの方法で在庫を算出します。
　一つは「SQL Update方式」、もう一つは「FM計算方式」です。

　それではそれぞれに関して説明します。

SQL Update方式

※特徴
　この方式は“実行”ボタンをクリックすることにより、［在庫基準日］時点の全商品の在庫数を算出して記録します（技術仕様的には、入庫数計/出庫数計/在庫数を「upd在庫」という専用テーブルに記録します）。

　一旦記録されたデータは次に“実行”ボタンを実行するまで更新されません。
したがって、“実行”ボタンクリック時点には最新情報ですが、時間が経過するに従い、最新の在庫数とは異なる可能性が高くなります。

　“実行”ボタンクリック時に入出庫データが大量にある場合、処理に数秒～数十秒、1千万件を超えるような場合は数分かかる可能性がありますが、処理が終了してしまえば即座に数値を表示・印刷できます。
　「SQL Update方式」は、在庫表などで在庫情報をリスト形式で表示・印刷する場合、高速に処理することができます。

注：
　本機能はクライアント/サーバ環境に置いて、FileMaker ServerにODBC設定がされていれば、FileMakerクライアントにはODBCのインストール/設定は不要です。

※操作方法
　実行ボタン　―　任意の［在庫基準日］を指定して本ボタンを実行すると、［在庫基準日］時点の入庫数/出庫数/在庫数が算出・記録されます。

　当方のクライアント/サーバ環境下で、入出明細レコード170万件に対してこの処理を実行すると、30秒～1分程度の時間を要します。

　作成済在庫データ選択ウインドウ（FileMaker 13使用時のみ）　―　実行ボタン右横の黄色の部分をクリックすると、小さなウインドウ（下図）が表示されます。この時、プルダウンメニューをクリックすると、他のユーザ（アカウント）が作成した在庫データの一覧が表示されるので、ここでその内の一つを選択すると、以後、「SQL Update方式」には選択したアカウントが作成した在庫データが表示されます。

他のアカウント(admin/seminar/stockchecker)が作成した在庫データを照会できる。
アカウント右側の日付は、データ作成時に指定した［在庫基準日］

注：
　各ユーザ（アカウント）は［在庫基準日］を指定して“更新”ボタンを実行することにより、全商品の在庫データを作成・記録できます。
同アカウントが次に“更新”ボタンを実行すると、前回作成した在庫データは上書きされます。例えば、admin アカウント で［在庫基準日］に「2014/11/27」と指定して本ボタンを実行すると、全商品に対して［在庫基準日］時点の在庫データが作成されますが、次に adminアカウントが「2015/12/31」を指定して同操作を実行すると、「2014/11/27」時点のデータは上書きされます。

　尚、他のアカウントが作成した在庫データは上述の通り照会することはできますが、別のアカウントで上書きすることはできません。例えば、adminアカウントでログインしている場合、seminar が作成した在庫データの照会はできても、上書きすることはできません。

FM計算方式

※特徴
　この方式は旧来のFileMakerの計算式を使用した在庫算出方法（参考記事）です。この方法のメリットは、常時最新の在庫情報を表示される点です（下記注参照）。

　ディメリットは、入出庫明細にデータが多量にある場合、在庫情報の表示に時間がかかることがある点です。 例えば、入出明細レコードが170万件あり商品Aを含むレコードがその中に2万9千件ある場合、当方の低SPECなクライアント/サーバ環境下では商品Aの［在庫数］を算出するのに5秒強程かかります。

　商品画面で個々の商品情報を一つ一つ計算・表示する場合はまだいいのですが、複数の商品の［在庫数］をリスト形式で表示する場合はかなりのストレスを感じます。

注：
　ネットワーク上の他ユーザが照会中の商品の入出庫データを追加・更新した場合、“画面更新”をクリックすると、最新の在庫情報が表示されます。

※操作方法
　計算するチェックボックス　―　チェックすると「FM計算方式」の在庫情報が表示されます。チェックを外すと在庫情報の計算を行わないので、画面表示が高速になります。

　尚、「FM計算方式」の出庫数計/入庫数計/在庫数のフィールドをレイアウト上に配置するだけで、システム起動後に初めて商品レイアウトを開く際に時間がかかります。
入出明細に170万件のレコードがある場合、当方の環境下では、1分前後の時間を要します。

　この詳しい理由については割愛しますが、簡単に言うと入出明細テーブルのビューに対して、DISTINCT句を含むクエリを発するためです。
「FM計算方式」が不要であればこれらの3フィールドはレイアウト上から削除して構いません。

　その他の在庫関連記事を読む

以上

『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(2) ―― 在庫誤差調整伝票の作成

　前回の記事では、iPad のバーコード読み取りによる棚卸入力機能を実装するところまでをご紹介しました。

　『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(1) ―― 棚卸入力を実装する

　棚卸作業をしてみると、システム上の在庫数と、棚卸在庫数（実在庫）が一致しない　―　誤差がでる ― ことはよくあることです。

FMEasy在庫 R1.0/R1.5 に在庫誤差調整伝票作成機能を実装する

　今回は『FMEasy在庫 R1.0/R1.5』をカスタマイズし、入庫/出庫の調整伝票を作成することにより在庫誤差調整を行う機能の作成方法をご説明します。

　前回と同様、以下の用語を使っていきます。

【用語解説】

在庫数　―　システム上の在庫数。『FMEasy在庫 R1.0/1.5』で入出庫登録を行った結果、算出・表示される商品画面上の［在庫数］。以下の［棚卸在庫］とは異なる可能性がある

棚卸在庫　―　実際の存在する商品の在庫数、または『FMEasy在庫 R1.0/1.5』に入力されたその値。システム上の在庫数（=［在庫数］）とは異なる可能性がある

棚卸　―　 実際に存在する商品の数を（カスタマイズ後の）『FMEasy在庫 R1.0/1.5』に入力すること

在庫誤差調整　―　 「システム上の在庫数」と「棚卸在庫」の誤差を入庫/出庫の調整伝票を作成することにより修正すること、またはその機能

　それでは、こちらの動画をご覧いただいたあとで、実際のカスタマイズ方法をご紹介します。

【開発レベル】
中級（レイアウト修正、テーブル修正、スクリプト修正について理解している）

【用意するもの】
1. 『FMEasy在庫 R1.0』または『FMEasy在庫 IWP/WD R1.5』
『FMEasy在庫』はこちらからダウンロードできます。
2. iPad/iPad Mini
3. FileMaker Go 13 (iPad にインストール)
FileMaker Go 13 はこちらからダウンロードできます。

注意：
1. 作業を始めるまえに、必ず『FMEasy在庫』のバックアップをお取りください。
2. 作業の際、修正場所を間違えると、既存の機能が動作しなくなる可能性があります。

1. 在庫誤差調整に必要なフィールドを準備

　以下のフィールドを EasyData15.fmp12（R1.0の場合、EasyData.fmp12） の商品テーブルに追加します。

　[c在庫誤差]（計算）　―　在庫誤差、誤差がある場合、調整の対象となる
　式：　If(棚卸在庫 = ""; 0; c在庫数 - 棚卸在庫)   //[棚卸在庫]が空欄(未入力)の場合、誤差は 無いものとみなす

　[c入庫数調整]（計算）　―　[c在庫誤差] がマイナスのときに、この誤差を入庫対象数とする
　式：　If(c在庫誤差  <  0; Abs(c在庫誤差); 0)

　[c出庫数調整]（計算）　―　[c在庫誤差] がプラスのときに、この誤差を出庫調整伝票の対象とする
　式：　If(c在庫誤差  > 0; c在庫誤差; 0)

　[gNo]（数値型、グローバル）　―　入庫伝票No/出庫伝票No の入出明細取込用一時記憶フィールド、後述のスクリプトで使用

2. 在庫誤差調整伝票作成スクリプトを作成

　このスクリプトの仕様は以下の通りです。

1)  在庫基準日を本日の日付（棚卸作業実施日）にする。
2)  棚卸作業を行わなかった商品は調整対象から除外する。
3) [在庫数] - [棚卸在庫] の誤差がプラスの場合は 出庫伝票、マイナスの場合は 入庫伝票 を作成する。
4) [在庫数] - [棚卸在庫] が 0 になる商品については、調整伝票を作成しない。
5) 入庫伝票/出庫伝票 の[伝票区分]は [7:在庫調整]（新設）とし、通常の伝票区分とは区別する。
6) 入出明細::備考フィールドに[棚卸担当ID]を記録。

　上記の条件に従ってスクリプトを記述すると、たとえばこのようになります。

　スクリプトの流れ上、入力チェックやウィンドウ切替などのステップも含まれていますが、基本的には上記の赤囲みの部分が押さえられていれば調整伝票を作成できるようになります。

① システム在庫を本日時点のものにする

　棚卸作業が終わった直後、つまり本日時点のシステム在庫と、棚卸在庫の差違をみるため、[在庫基準日1]　に本日の日付を設定します（Get(日付)）。

② [c入庫数調整] に値が入っている商品データを検索します。　
　このデータが入庫伝票作成対象となります。
　対象レコードがみつかった場合は、入庫伝票を新規作成し、その[入庫No]を [gNo]に一時記録します。

　次に、対象商品データを入庫明細として「入出明細」テーブルに取り込みます。
　その際、[入庫No] として[gNo]を取り込みます。
　取り込み順は以下のとおりです。

(商品テーブル)	→	（入出明細テーブル）
商品ID	→	商品 ID
g在庫基準日1	→	入出庫日
単位	→	単位
仕入単価	→	仕入単価
JAN	→	JAN
棚卸担当ID	→	備考
c入庫数調整	→	入庫数量
gNo	→	入庫No

　※データ取り込みのデータ自動入力オプションはオンにします。

③[c出庫数調整] に値が入っている商品データを検索します。　
　このデータが出庫伝票作成対象となります。
　対象レコードがみつかった場合は、出庫伝票を新規作成し、その[出庫No]を [gNo]に一時記録します。

　次に、対象商品データを出庫明細として「入出明細」テーブルに取り込みます。
　その際、[出庫No] として[gNo]を取り込みます。
　取り込み順は以下のとおりです。

(商品テーブル)	→	（入出明細テーブル）
商品ID	→	商品 ID
g在庫基準日1	→	入出庫日
単位	→	単位
販売単価	→	販売単価
JAN	→	JAN
棚卸担当ID	→	備考
c出庫数調整	→	出庫数量
gNo	→	出庫No

　※データ取り込みのデータ自動入力オプションはオンにします。

　ここまでできたら、一度スクリプトを実行してみましょう。
　調整伝票が作成されるとともに、商品の[在庫数]と[棚卸在庫]がぴったり一致していれば成功です。

【入庫調整伝票の例】

【出庫調整伝票の例】

【在庫の一致を確認（テスト段階）】

　何度かテスト実行して、問題がなければ、上記スクリプト内でコメントアウトされている[棚卸在庫]および[棚卸担当ID]の全置換クリアステップを有効にします。

　これにより、棚卸調整在庫が作成された後は、自動的に棚卸情報がクリアされますので、次回の棚卸作業時に[棚卸在庫]および[棚卸担当ID]フィールドがクリアされていないということがなくなります。

【在庫誤差調整伝票スクリプトの配置場所】

　在庫誤差調整伝票作成の実行ボタンは、ここでは商品一覧画面に配置してみます。
　赤囲みのところにご注目ください。
　[棚卸在庫]フィールドを[在庫数]フィールドの下に配置することで、調整伝票作成前に棚卸状況を確認できるようになっています。

　そして、“調整実行”ボタンをフッタ位置に配置し、ボタンクリックで調整伝票を一括作成することができます。

　“調整実行”ボタンについては、ユーザ権限による制御を追加するなど、誤操作防止策を検討してみてください。


【重要：在庫誤差調整伝票を作成するタイミング】

　システム在庫は常に変動しています。
　このため、棚卸作業開始～在庫誤差調整伝票作成完了までの間、一般ユーザによるシステムの使用や入出庫作業を禁止する必要があります。

　「禁止！」と言っているのにアクセスしてくる困ったちゃんがいる場合、FileMaker Server を停止し、サーバ上で本スクリプトを実行します。
　これにより、在庫の誤差がなくなることになります。

　なお、繰越処理（在庫や各種残高を繰り越す処理）を行っている場合、繰越処理の中に本スクリプトを組み込むのも Good！と思います。

　その他の在庫関連記事を読む

（亀）

『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(1) ―― 棚卸入力を実装する

　今回は、iPadによる棚卸入力モジュールの開発方法をご紹介していきます。

FMEasy在庫 R1.0/R1.5 に棚卸入力モジュールを実装する

　ここでは弊社製品 FileMaker 在庫管理テンプレート『FMEasy在庫 IWP/WD R1.5』に沿って解説を進めていきますが、『FMEasy在庫 R1.0』を利用することもできます。

Q.　棚卸入力モジュールを使うと、倉庫の商品のバーコードを iPad で読み取って商品個数を入力するだけで、素早く、簡単に棚卸作業が進められるようになるの？

A.　（最初から期待を裏切ってしまうかもしれませんが）微妙です。
　皆様は棚卸作業の時、商品リストを印字して、倉庫に持っていき、一人が商品をカウントして読み上げ、もう一人が数量をリストに書き込む、というような作業をされいると思います。

　リスト上の商品が棚番でソートされているようであれば、カウントした商品数を素早くリストに書き込むことができ、リストに書き込んだ数値をExcelや在庫管理アプリに入力するというのも、立派なやり方と思います。

　ただ、棚番管理ができていない等の理由により、リスト紙ベースの棚卸がうまく機能していないようであれば、iPadなどの携帯端末による棚卸を検討されてはいかがでしょうか。　

　iPad/iPhoneによる バーコードスキャンは慣れが必要です。スキャンをすばやく実行できるようになれば、棚卸入力モジュールはかなり有望と思います（自画自賛＞＜）。

　それでは、以下の2つの機能に分けて、その作成方法をご説明していきます。

　1. iPad および FileMaker Go 13 のバーコード読み取り機能による棚卸入力モジュール
　2. 上記で入力した棚卸在庫数とシステム上の在庫数の誤差を修正する調整伝票作成機能

　　今回は 1. の棚卸入力モジュールにいて説明しますが、その前に少しだけ用語のご説明……

【用語解説】

在庫数　―　システム上の在庫数。『FMEasy在庫 R1.0/1.5』で入出庫登録を行った結果、算出・表示される商品画面上の［在庫数］。以下の［棚卸在庫］とは異なる可能性がある

棚卸在庫　―　実際の存在する商品の在庫数、または『FMEasy在庫 R1.0/1.5』に入力されたその値。システム上の在庫数（=［在庫数］）とは異なる可能性がある

棚卸　―　 実際に存在する商品の数を（カスタマイズ後の）『FMEasy在庫 R1.0/1.5』に入力すること

在庫誤差調整　―　 「システム上の在庫数」と「棚卸在庫」の誤差を入庫/出庫の調整伝票を作成することにより修正すること、またはその機能

iPadによる棚卸モジュールを作成する

まずは、こちらの動画をご覧ください。



　倉庫の商品棚のバーコードを iPad で読み取り、各々の商品の個数をタッチパネルで入力している様子です。

　操作手順は以下のとおり。

1. 画面上部の［JAN］フィールドをタップしてカメラをアクティグにする
2. バーコードにフォーカス。フォーカスが合うと、iPadが勝手に商品を検索してくれて、［棚卸在庫］がアクティブに。
3. 値一覧（1～9）の数値をクリックするか、テンキーから実際の在庫数を入力。
   
   以下、1～3 を繰り返して、各商品の［棚卸在庫］を入力していきます。

　さて、ご覧のように、バーコードは棚に貼りつけておくと、素早くスキャンできると思います。

　この動画では、私が棚卸作業をしていますが、バーコード読み取り時にカメラのフォーカスを合わせたり、数値をスムーズに入力したりするには少々コツがいります。
　慣れればかなり速くスキャンができるようになると思います。

　商品をひとつひとつ手に取り商品上のバーコードをスキャンすることもできますので、どちらが御社に適しているのか、検討してみてください。

　それでは、この棚卸作業用の画面を開発してみましょう。

【開発レベル】
中級（レイアウト修正、テーブル修正、スクリプト修正について理解している）

【用意するもの】
1. 『FMEasy在庫 R1.0』または『FMEasy在庫 IWP/WD R1.5』
『FMEasy在庫』はこちらからダウンロードできます。
2. iPad/iPad Mini
3. FileMaker Go 13 (iPad にインストール)
FileMaker Go 13 はこちらからダウンロードできます。

注意：
1. 作業を始めるまえに、必ず『FMEasy在庫』のバックアップをお取りください。
2. 作業の際、修正場所を間違えると、既存の機能が動作しなくなる可能性があります。

1. 取扱商品の JAN コードを商品マスタに登録

　社内の取扱商品の JAN コードを商品マスタに登録しておきます。
　商品マスタへのJAN コードフィールドの配置方法と登録のしかたについては、こちらの記事をご参照ください。

　iPad のバーコードスキャンで入庫伝票を作成 ― FMEasy在庫のカスタマイズ


2. 商品テーブルに棚卸作業用のフィールドを追加

　棚卸作業をするにあたり、以下のフィールドを EasyData15.fmp12/EasyData.fmp12 の商品テーブルに追加します。

　[棚卸担当ID]　（数値型） ―　棚卸担当の[社員ID]を入力するためのフィールド
　[棚卸在庫]（数値型） ― 倉庫棚の在庫数を入力するためのフィールド

3. JANコード検索用のフィールドを UI テーブルに追加

　棚卸用バーコードスキャン用のフィールドを EasyApp15.fmp12/EasyApp.fmp12 の UI テーブルにグローバルテキストフィールドとして追加します。

4. 棚卸担当者の氏名情報と担当者の過去の棚卸実績を照会するためのリレーションを追加


　以下の 3 つの TO を追加します。

　1) 社員_棚卸担当ID （社員テーブル）
　2) self_棚卸担当ID （商品テーブル） 任意
　3) self_商品ID（商品テーブル） 任意

1) [棚卸担当ID]と社員マスタのリレーション

　商品TOの[棚卸担当ID] と社員_棚卸担当ID TO の[社員ID]を関連付けます。

　2) 同じ[棚卸担当ID]が過去に棚卸処理をした商品を調べるためのリレーション

　商品 TO の [棚卸担当ID] と self_棚卸担当ID TO の [棚卸担当ID] どうしを関連づけます。

　これにより、ある担当者が過去に実行した棚卸実績を閲覧できるようになります。
　棚卸機能としては必須のリレーションではありませんが、棚卸作業もれや棚卸ミスをチェックできますので、用意しておくと便利でしょう。

　3) 棚卸実績の[商品ID]からその商品の情報に移動するためのリレーション

　上記で用意した self_棚卸担当ID TO の[商品ID] と self_商品ID TO の [商品ID] フィールドを関連づけます。

　これにより、棚卸実績の中からその商品情報に移動（照会）できるようになります。
　棚卸機能としては必須のリレーションではありませんが、棚卸作業時には、商品情報照会の操作性がアップしますので、用意しておくと便利でしょう。

5. 棚卸作業用のレイアウトを追加

　EasyApp15.fmp12/EasyApp.fmp12　のレイアウトモードで新規レイアウトを作成します。
　FileMaker Pro 13 では、下図のように視覚的にレイアウトを作成できます。

　このとき、表示するレコードは「商品」、レイアウト名は ipad 用の棚卸画面とわかる名前を指定しておきます。

　また、ここでは縦置きを前提にしたレイアウト選択を行っていますが、運用時に縦置きと横置きとでどちらが使い勝手が良くなるかを事前によく検討しておくと、後々のレイアウト調整の手間が省けます。

　あとは上記で用意した TO とリレーションを使って、[棚卸担当ID]、[棚卸在庫]、[gJAN] （スキャン用）などのフィールドを配置していきます。

　たとえば、レイアウトの加工例はこのようになります。
　最低限のユーザ入力が必要になるフィールドには赤囲みを付けておきますので、参考にしていただけると幸いです。

　図中、「タップでスキャン開始」となっているフィールドは UI TO の [gJAN] フィールドになります。
　操作では、このフィールドをタップした瞬間にバーコード読み取りモードに移り、iPad のカメラが起動させるようにします。


7. バーコード読取スクリプトを編集（または作成）

　iPad からバーコードを読み取るためのスクリプトを用意します。
　スクリプトの作成方法の詳細については、こちらの記事をご参照ください。

　iPad のバーコードスキャンで入庫伝票を作成 ― FMEasy在庫のカスタマイズ

たとえば、バーコード読取スクリプトの編集例はこのようになります。

8. JAN コードによる商品呼出スクリプトを追加

　ユーザが UI の [gJAN] フィールドにスキャンした JAN コードを使って商品検索を行うスクリプトを作成します。

　たとえば、以下の図のようになります。

9. [gJAN] フィールドにスクリプトトリガを実装

　[gJAN] フィールドを iPad でタップした瞬間（OnObjectEnter） にバーコード読取が実行されるようにスクリプトトリガを設定します。

　また、[gJAN]へのバーコード読み取りが終了した瞬間(OnObjectSave) に JAN コード検索が実行されるようにスクリプトトリガを設定します。

　たとえば、以下のようになります。

　ここまでできたら、iPad に FileMaker Go 13 をインストールして、棚卸入力テストを行ってみてください。

　本記事の棚卸操作のような動きになれば成功です。

【棚卸実績を表示させる】

　ここでは、画面右の棚卸実績ポータルの作り方について解説します。
　ご覧のように、同じ棚卸担当者（例：土屋）が行った棚卸実績が一覧表示されていると、棚卸在庫数とチェック漏れの確認ができて便利ですね。

　棚卸実績表示用のリレーションシップの設定については、前述の「4. 棚卸担当者の氏名情報と担当者の過去の棚卸実績を照会するためのリレーションを追加」をご覧ください。


　ポータル指定の際に使うリレーションは「self_棚卸担当ID」となります。

　
　このリレーションの参照先が商品テーブルとなっていますので、[商品名]と[棚卸在庫]を配置しておけばよいでしょう。

　本稿では省略しますが、“照”ボタンをクリックすることによって、その行の商品の詳細情報を別ウィンドウで表示させたりすると、より使い勝手がよくなるでしょう。

　在庫誤差調整機能については、次回の記事でご紹介したいと思います。

　「iPadでバーコードスキャンして、棚卸表ができました！」というだけでは「で？」と突っ込まれそうなので、入力した［棚卸在庫］とシステム上の在庫数の誤差を調整伝票を発行して修正する機能もつくりました。
　続きはこちらの記事をご覧ください。

　『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(2) ―― 在庫誤差調整伝票の作成 

　その他の在庫関連記事を読む

（亀）