ラベル FileMaker Go の投稿を表示しています。 すべての投稿を表示
ラベル FileMaker Go の投稿を表示しています。 すべての投稿を表示

2017-10-17

iBeacon の適用モデルを考える 2 ― 定位置ビーコン監視モデル

 前稿の末尾で iBeacon の「常時監視・単品管理モデル」に少し触れましたが、これは倉庫等の保管場所にある商品に iBeacon を取り付け、その存否(存在するのか、しないのか)を iPad 等の端末により常時監視するというものです(下図)。本稿ではこのモデルを掘り下げて考えてみます。

天井等、高所に取り付けた端末で商品に取り付けられたビーコンを監視

 

モデルの再定義

本モデルは、iBeacon が取り付けられた商品(以下、ビーコン)が多数存在し、システムでビーコンの存否情報を管理することを目的とします。各ビーコンを監視する端末は1つに定められており、その端末がビーコンの電波を受信しなくなった時点で商品は存在しないものとシステムは認識します。ビーコンは倉庫内を移動することは無い(例えば、上図のA区画から他の区画へ移動することは無い)ものと規定します。このモデルを「定位置ビーコン監視モデル」と呼びます。 これに対して、ビーコンが倉庫内を移動し、移動するビーコンを監視・管理するモデルを「移動ビーコン監視モデル」と呼びます。本稿では、「定位置ビーコン監視モデル」についてのみ扱います。


シナリオ

上図のように定位置にある多数のビーコンを監視するために、必要十分な数のiOS端末(以下、端末、iOS以外の端末に言及する場合はその旨を表記)を配置します。端末にはビーコンの存否(ビーコンの信号検知時には存在、非検知時には存在しないと認識)を監視するシステムをインストールしておきます。端末がビーコンの電波を検知しない場合、データベースのビーコンテーブルのレコードに記録(×で表示)し、ユーザにビーコンが消失したことを通知します。

ビーコンの選択

まず肝心要のビーコンを調達しなければなりません。本モデルでは個々の商品にビーコンを取り付けるので、多数のビーコンを使用することが想定されます。よって、ビーコンの信頼性、保守性、価格、プロダクトライフサイクルが重要になります。また、ビーコンの保守(UUID、Major、Minor、Measured  Power 、出力等の設定・更新)を行うには、多くの場合、ベンダ独自のクラウドサービスを利用することになるので、企業・組織によってはベンダーロックインを懸念し、面倒でも複数ベンダーのビーコン運用を要件とするかも知れません。

ビーコンメーカーとビーコン製品の選択

日本のビーコンベンダーでは、Aplix社アクセス社が有名なようです。Aplix社が料金やマニュアル等の情報を公開しているのに対し、アクセス社はユーザ登録を行わないと詳しい情報が得られないようです。今回は情報がオープンなところを良しとし、Aplix社の製品・MyBeacon® 汎用型 MB004Ac-DR1 (下写真の黒いビーコン)を調達しました。

 一社だけではなく異なるベンダーの製品もチェックすべきと考え、海外のメーカー1社からもビーコンを調達することにしました。海外では Estimote社が有名なので当初はここを第一候補としたのですが、2017年7月に問い合わせたところでは「現行製品には技適マークを取得したものはなく、8月に1製品で技適マークを取得する予定」とのことでした。この世界最大手のビーコンメーカーは米国等他の市場に手一杯で日本市場には手が回らない様子のため、今回はEstimote を見送ることにしました。

 次に候補に挙がったのが Onyx社で、ここは世界第4位のビーコンメーカーとどこかに書いてありました。同社の各製品は技適マークを取得しているところが高ポイントで、営業担当のビアンカさんの応答もとっても早かったです。ということでOnyx社から技適取得の製品 Beacon One (写真の白く小さな円形ビーコン)とEnterprise Beacon (白く大きな円形ビーコン)を3つ調達。2メーカー、3製品の計21個のビーコンでプロトタイプ(後述)によるテストを行うことにしました。

写真左の青いタグ型ビーコンは Gimbal社製 Gimbal Proximity Beacon Series 10
残念ながら今回のテストには間に合わず 

ビーコンの保守・管理

ビーコンの導入時や故障時には、その UUID、Major、Minor 等を設定・変更する必要があります。多くのビーコンベンダーは、ビーコンのクラウドサービスにアクセスさせ、購入したビーコン情報を登録・更新させた後、メーカー独自のビーコンアプリケーションをインストールしたiOS/Android端末をビーコンに近づけて、その端末からビーコンの情報(UUID、Major、Minor、Measued Power、出力等)を登録・更新させます。下図は Aplix社のビーコン管理クラウドサービスの画面で、この画面でビーコンの各種情報を更新します。

【Aplix社のビーコン情報管理用クラウドサービスの画面】
Aplix のビーコン CMS 画面
AplixのサービスはビーコンのCSVデータを取込/書出できる為、多量のビーコンを管理し易い


 Aplix社のケースでは上記で登録した情報に iOS/Android 端末上の MyBeaconTool でアクセスし、同端末をビーコンに近接させた上でビーコン情報の更新を行うことができます。



【iPad 上のAplix MyBeaconToolの画面】
Aplix MyBeaconTool
MyBeaconTool がクラウド上のデータを基にビーコンへの書き込みを行う。

ビーコンの性能・安定性

本モデルに限らずビーコンを使用したシステムでは、当然ながらビーコンが安定して動作することが重要です。下表は小社で開発したビーコン監視システムのプロトタイプ(以下、プロトタイプ、詳細は後述)を使用して、21個のビーコンを約60時間、監視テストした結果です。「Distance」はビーコンと端末の間の距離です。テスト中、ビーコンは移動していないので、本来であれば端末は常にすべてのビーコンを検知した状態でなければなりません。Aplixの10個のビーコンについては、60時間で端末が非検知と認識したのは1個体の1回のみで、高い安定性を示しましたが、Onyxは非検知が多く発生し、各個体で性能にバラつきがありました。
 尚、今回のテストにあたっては、各ビーコンの出力は初期値のまま使用しています。

Result of beacons heart-beats monitoring using iPad and FileMaker Go
Distance
Aplix MB004
Onyx One
Onyx Ent.*1
  M/M*2 Results M/M Results M/M Results
 0.1m 1/6 OK        
1m 0/2 OK        
2m 0/3 OK 39/20112 OK 1/7319 OK
0/4 OK 39/20168 OK    
5m 0/5 OK-1 39/20841 OK 1/7320 NG-288
1/1 OK 39/20862 NG-222    
9m 1/2 OK 39/21289 OK 1/7321 OK-4
1/3 OK 39/21351 OK    
9m  w/obst.*3 1/4 OK 39/21903 NG-14    
1/5 OK 39/21920 OK-1    
Total 10   8   3  
*1 Onyx Beacon Enterprise
*2 Major/Minor
*3 Beacons with obstacles placed nearby are 9 m away from device
*4 OK without number indicates  "Always detected by device"(signal never lost during test), Numbers beside OK/NG indicate the number of times beacons lost.


プロトタイプについて

今回、上表のテスト実施時に使用した FileMaker 16 によるプロトタイプの開発・テスト環境と仕様は以下の通りです。

■開発・運用環境
使用端末 iPad/iOS10.3.3
運用ソフト FileMaker Go 16
開発用ソフト FileMaker Pro Advanced 16
サーバソフト FileMaker Server 16
ベースソフト FMEasy在庫 IWP/WD R1.5」をベースにカスタマイズ
■仕様
UUID関連(下図) ・UUID/Major/Minor(テーブル、以下UMM) は階層構造とする
・UMMテーブルは商品テーブルとは分離する
監視(下図) ・RangeBeacon関数により指定されたUUID(複数指定可)を発信するビーコンを繰り返しスキャン
・設定した閾値を超えてビーコンが連続して非検知の場合、当該ビーコンのレコードに記録する(例えば、閾値を3とした場合、端末が3回連続してビーコンを検知しない場合、レコードに「×」と書き込む)


【UUID管理画面】0
FMEasy在庫の UUID 管理画面カスタマイズ例
上図の[監視]をチェックすると端末の監視対象となる

ビーコンの存否の監視は、天井などに固定されたiPad(端末)で行います。端末が3回連続してビーコンの検知をしないとそのビーコンは存在しないものと認識して、[存否]フィールドに「×」を書き込みます。
注:
閾値を1にして、1度でも非検知が発生したら即刻レコードに「×」を入力することも可能ですが、人、台車、移動中の物品に電波を遮られることを想定し、3に設定しています。

【iPad のビーコン監視画面】
FMEasy在庫のビーコン常時監視カスタマイズ例
監視端末 = iPad の画面。「×」は非検知ビーコン。複数のUUIDを持つビーコンを監視できる。

 

プロトタイプによる事前テストについて

 ビーコン導入のプロジェクト、特に多数のビーコンの導入を伴うようなプロジェクトでは、プロジェクトの初期段階でプロトタイプを用いたテストを実施すべきと思います。プロトタイプによりユーザの要求仕様の実現に目途をつけると共に、ビーコンの総数や、端末がビーコンの信号を安定して受信するためには端末をいくつ用意し、どのように配置するかという計画もこの段階で立てるようにします(じゃないと、概算費用も見積もれませんよね?)。

 上表の監視テストは、当方の事務所内で、なるべく障害物を置かない状態(上表の*3を除く)で、実施しています。ただ、表のテストとは別時間にほぼ同環境で実施したテストでは、端末から9mは離れたAplix社のビーコンが検知されないことがありました。Aplix社のサイトでは、端末がビーコン信号を受信できる距離について、「非常に大まかな目安」として「端末を手に持った状態で50~100m程度、鞄やポケットの中にある場合は30m前後」と述べる一方、「展示会などの人混みの多い場所では低い位置に設置したBeaconが人の列に阻まれ5mの地点でも受信できないケース」もあるとしています。また同サイトは受信の可否について以下が影響を与えるとしています。

    1.Beaconの送信出力、アンテナのゲイン、放射パターン
    2.受信側スマートフォンの感度、アンテナの向き等
    3.スマートフォンOS内の処理(Bluetoothスタックの振る舞い他)
    4.周囲環境(建材、人体等)による反射・吸収・回折

 倉庫などでは、多段のラックに商品を配置し、ビーコン信号がラックや他の商品に遮断されてしまうことも考えられます。
 プロトタイプによる事前テストでビーコンと端末の配置計画を作成します。実運用開始後もビーコンの非検知が多発するようであれば、非検知のエリアに端末を増設できるようにシステムを構築し、運用を工夫する(例:端末を増設した場合、その端末に担当させる商品群の Major は別の Major に変更する)ことも重要でしょう。

端末のスキャン速度

 本プロトタイプでは、端末が常時あるいは一定の間隔で対象とするビーコンをスキャンするのですが、その時に使用する FileMaker の関数が RangeBeacons という関数で、この関数にはスキャンするビーコンの UUID(Major/Minorも追加指定可)とタイムアウト(スキャンする時間)を引数として指定します。

 今回のテストでは21個のビーコンに3種類のUUIDを設定しました。RangeBeaconsを実行するには最低限 UUID を指定しなければならないため、21個のビーコンをスキャンするには異なる3つのUUIDを指定し、RangeBeaconsを3回実行する必要があります。また、タイムアウトをあまり短く設定するとスキャン漏れが発生するため、5(秒)に設定しています。つまり、21個のビーコンを1回スキャンするために3回RangeBeaconsを実行するので、それだけで15秒を要することになります。

 端末が担当する全ビーコンの1回あたりのスキャンをできるだけ短くするには、ビーコンの UUID または UUIDとMajorを合わせた値を1つに限定し、1回のビーコンスキャンで実行する RangeBeacons の回数を1回にします。

 【プロトタイプのビーコン監視タブの下部に表示されるスキャン情報】
iBeacon スキャン結果
RangeBeacons3回で15秒だがその他の処理もあるため、実際は22.2秒(平均)を要した。

監視端末と課題

本モデルにおいて、ビーコンと同様またはそれ以上に重要な要素は、監視端末です。ビーコンが安定していても、それを検知する端末が不安定ではシステムは機能しません。

 また、ビーコンを配置するエリアが広いと、端末数も普通は多くなります。野球のグラウンドのような一辺が100メートル、1万平米の倉庫にある商品にビーコンを取り付けるケースで、10m×10mの区画に分けて端末を配置するには100台の端末が、5m×5mの区画に分けて端末を配置するには400台の端末が必要になります。iPad が1台3.5万円、FileMaker Go ライセンスが1万円/年とすると端末1台に必要な初期導入費用は4.5万円、これだけで高額なシステムとなってしまいます。そもそもこのモデルで使用する端末はビーコンを監視し、その結果をデータベースに書き込むという単純なものなので、多数の端末を導入するケースでは、 iPad や FileMaker Go に代わるソルーションが求められます。

端末で考慮すべきこと

ここでは主に端末の価格について書きましたが、多数の端末を管理・運用する場合、小社が端末に求める要件は以下の通りです。
  1. 廉価性 ― 1台、数千円程度
  2. 遠隔操作により本体の起動、再起動、その他の管理ができること
  3. 遠隔操作によりビーコン監視ソフトを起動、再起動、管理できること
  4. 遠隔一括管理 ― 上記2と3の起動、再起動などを遠隔から全端末に対して一斉に実行できること
  5. 高信頼性 ― 24時間/365日稼働すること
  6. 端末の死活(ハートビート)監視 ― 端末故障時にユーザに通知する機能

次回は iPad/FileMaker Go を使用しない端末ソルーションについて考えてみます。


(土屋)

参考サイト
http://business.aplix.co.jp/beacon/beacon_faq.html


IoT/M2M関連リンク

2017-05-24

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 のパフォーマンスに関する記事は、こちらをご参照ください。


 今回も、前回と同様に 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)」を有効にする必要があります。


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


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



(亀)

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-05-25

FileMaker 5.5/6 をモバイルで使う

 FileMaker 15 がリリースで盛り上がる?中、前回は FileMaker 5.5/6 って最高!という記事を書きました。

 開発サイドとしては、機能強化された最新の FileMaker を利用していただけると助かるのですが、コスト、対応デバイス、環境変更の手間等々の事情により、そう簡単にアップグレードできない企業・組織ユーザも多いのでは、と思われます。そうしたユーザの中には「現行の FileMaker システムは順調に稼働しているので苦労してアップグレードはしたくない。でも、モバイルでは利用したいよね」、みたいなところもあるのではないかと思います。

 そんなわけで、「この会社は一体何を考えているのか」という冷ややかな視線を感じつつ、今回は FileMaker 5.5/6 によるモバイル使用を試してみます。
 とは言いつつも、モバイル用のリモートデスクトップアプリを介してFM5.5/6を使用する、というだけなので、「なにを今さら」と思う方もいらっしゃると思います。小社でも以前、いくつかのリモート接続ツール(Remote とか iRdesktop とか iTapRDP )を試してみて、「これでFMデータベース操作するのは厳しい」と思い込み、最近は完全ノーマークでした。ところが Microsoft 社からリリースされているモバイル用 Remote Desktop Client というアプリを恥ずかしながら最近知り、これならなんとか使えるかも、と思い始めた次第です。

注:
言わずもがなですが、iPhone/iPad 上のFileMaker Go を使用すれば FileMaker Server に直接接続できます。本稿は、FileMaker Go は利用できない、あるいは Android やSurface で FileMaker を使用したいという方向けへの記事ともなっています。 

概要と準備するもの


 モバイル機器からの FileMaker データベース接続イメージはこのようになります。

モバイル機器による旧バージョン FileMaker データベース接続イメージ

 上記のように構成する場合は、以下の環境が必要となります。


 FMモバイルアクセス環境
  1. FileMaker Server
  2. FileMaker Pro アプリケーション(クライアント数分のライセンスが必要)
  3. タブレットPCやスマートフォンなどのモバイル機器
  4. リモートデスクトップサーバやVDI等の仮想デスクトップ環境(ここで FileMaker Pro を起動し、サーバにアクセス)
  5. モバイル用Microsoft Remote Desktop(Android / iOS

 FileMaker Server、FileMaker Pro、仮想デスクトップ環境(上記4)の各種設定の説明は省略しますが、 仮想デスクトップ環境では、下図のようにPC のプロパティより「リモートの設定」を選択してリモート接続を許可する点にご留意ください。




操作手順


 今回は FileMaker Server 5.5でデータベース(本例では、小社の旧商品「売上猫くん 4.5」(FileMaker 5.5/6対応)を公開し、仮想デスクトップ環境を介してAndroid タブレット PC (Nexus7)からアクセスする方法を順を追ってご紹介します。

  1. タブレット PC に Microsoft Remote Desktop アプリをインストールします。

    Google Play を開き、MS Remote Desktop を検索し、インストールします。



    【iOS用の Microsoft Remote Desktop アプリ】

    iOS をご利用の方は、Apple ストアから Microsoft Remote Desktop アプリを入手してインストールすれば、同様に操作できるようになります。

  2. RD Client アイコンをタップします。

    ホーム画面に RD Client アイコン(←Microsoft Remote Desktop のアイコン)が表示されますので、これをタップします。


  3. リモートデスクトップ接続を追加します。

    Remote Desktop Client アプリが起動します。
    画面右上の+アイコンをタップします。


  4. Desktop を選択します。

    追加可能な項目の一覧が表示されますので、その中から Desktop を選択します。

  5. リモートデスクトップ接続情報を入力します。

    表記はすべて英語となりますが、最低限接続先のPC名(または IP アドレス)とユーザ名を設定するだけでも接続できるようになります。

    下図では、フレンドリ名として nekodemo を入力していますが、これは必須ではありません。



  6. 共有先の Windows PC に接続します。

    接続情報を保存すると、nekodemo という名前のアイコンが画面に追加されますので、これをタップします。

  7. ログイン情報を入力します。

    共有先の PC に接続すると、ログインダイアログが表示されますので、Windows PC へのログイン情報を入力し、“Connect”ボタンをタップします。



    ※このアプリの仕様と思われますが、接続後の画面設定は縦置き表示ができないため、以降は、デバイスを横置きにした状態で操作を進めます。
  8. マウスポインタをタッチパネルに切り替えます。

    ログインに成功すると、おなじみのリモートデスクトップ画面がモバイル PC 上に表示されます。



    画面上部のポインタ切り替えアイコンをタップします。すると、画面表示が以下のように変わります。

    画面右の“Touch”アイコンをタップすることによって、マウスポインタをタッチパネルモードに切り替えます。

  9. ズームインモードに切り替えます。

    モバイル PC 上のリモートデスクトップ画面はとても文字が小さいという難点があります。
    リモート共有 PC側でフォントサイズを大きくしても、これは Remote Desktop アプリでは有効にならないため、文字サイズは小さいままとなります。

    ここで、ズームモードに切り替えて操作してみましょう。
    画面上部の虫眼鏡アイコンをタップします。

    すると、デスクトップがズームインされ、画面に十字矢印のアイコンが表示されます。



    この十字矢印に指を乗せて画面をなぞることによって、デスクトップの表示領域を移動します(多少の慣れが必要です)。
    以降、しらばらくはズームイン状態のまま操作します。
  10. FileMaker 起動後、スクリーンキーボードを使って『売上猫くん4.5』にログインします。

    画面上の FileMaker Pro 5.5/6.0 アイコンを二回連続でタップすると、FileMaker Pro アプリケーションが起動します。
    共有ファイルより、『売上猫くん4.5』のメニューファイルを開きます。

    以下は FileMaker Server 5.5 で公開されている『売上猫くん4.5』のログイン画面が表示されたところです。
    [パスワード]入力ボックスをタップしてもスクリーンキーボードは表示されませんので、画面上部に配置されているスクリーンキーボードアイコンをタップします。



    スクリーンキーボードが表示されますので、パスワードを入力して Enter キーをタップしてログインします。

  11. 『売上猫くん4.5』を操作してみます。

    リモートデスクトップ共有で『売上猫くん 4.5』を操作しているため、ご覧のようにファイルメーカー Pro のメニューバーは表示されたままの状態となります。



    “顧客(仕入先)”ボタンをタップすると、顧客仕入先画面が表示されます。
    ご覧のように、表示はモバイル PC 用に最適化されていないため、画面の一部が切れた状態となります。



    ここで、画面上部に表示されている虫眼鏡アイコンをタップすることにより、ズームイン状態を解除します。



    これにより、デスクトップ全体表示に戻ります。
    各画面の情報照会はズームインモード、一覧データを照会する際はデスクトップ全体表示にするなど工夫が必要かもしれません。

    (参考:住所録表示)

  12. 日本語入力に切り替えて、テキストを入力します。

    Remote Desktop アプリケーションは、接続直後の入力モードは英語(EN)となります。
    日本語のテキストを入力するには、日本語入力モードに切り替えてから使用する必要があります。



    リモートデスクトップの右下に表示されている EN アイコンをタップし、JP (日本語)に切り替えます。

    そして、日本語を入力したい画面のテキストボックスをタップし、手順10.の要領で画面上のキーボードアイコンをタップしてスクリーンキーボードを呼び出します。

    このとき、お使いのモバイル PC によってはキーボードが英語のままになっているため、キーボード下部の English をタップすることによって、日本語キーボードに切り替えます。





    日本語入力をしてみましょう。以下は「てすとにゅうりょく」とローマ字打ちしてから、候補の中から「テスト入力」を選ぼうとしているところです。



    ご覧のように、[備考]フィールドに「テスト入力」と入力できました。


 以上、使い勝手はモバイルに最適化されたFileMaker Go にはかないませんが、モバイル版Microsoft Remote Desktop による FileMaker データベースの操作は、想像以上に快適に思いました。もともとリモートデスクトップはLAN上の仮想デスクトップで処理を行い、画面イメージのみをリモート端末に送るので高速です。また、モバイル機器に比べて、プリンタ等の周辺機器もPC同様に使用できるメリットもあります。
 種々の事情から FileMaker Go を利用できないユーザの方は、Microsoft Remote Desktop の利用を検討されてはいかがかと思います。

 時間があれば、旧FileMaker のアプリをモバイル用に無理やりカスタマイズしたらどのくらい操作性が向上するのか、とかも記事にしたいなぁと思っています。
 
 なお、セキュアなモバイル接続については、下記のページが参考になるかと思います。
 最終回 遠隔地のAndroid/iOS端末から社内PCにリモートデスクトップ接続する (1/2)


参考リンク:
Microsoft Remote Desktop アプリダウンロードページ(Android)
Microsoft Remote Desktop アプリダウンロードページ(iOS)


土屋企画では、FileMaker レガシーシステムの延命、拡張、仮想マシンへの移行に関するご相談を請け賜わっております。ご希望の方はこちらからお問い合わせください。


(亀)

2014-12-01

『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入出庫日
単位単位
仕入単価仕入単価
JANJAN
棚卸担当ID備考
c入庫数調整入庫数量
gNo入庫No

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

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

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

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


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

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

【入庫調整伝票の例】



【出庫調整伝票の例】



【在庫の一致を確認(テスト段階)】



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

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

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

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


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

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


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

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

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

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



(亀)