2017-11-14

FMクライアントからサーバ上のODBC/node.js経由でデータベースをCRUDする

 FileMaker(以下、FM)から FileMaker Server (以下、FMS)上のデータベースに接続し、SQLクエリでデータを CRUD する場合に考えられる方法は、通常は以下の2つです。

  1. FM クライアント機に ODBC を入れて、SQL を実行スクリプトステップを使用する
  2. FM クライアント機に ODBC は入れ、ODBCはサーバにのみ入れ、サーバサイドスクリプトで SQL を実行スクリプトステップを使用する

 1. のデメリットは、全てクライアントにODBCを入れる必要があり、保守が面倒なこと、
 2. のデメリットは、サーバサイドスクリプト内はデバッガが使用できず、またクライアントで実行する場合と動作が異なることがあること、です。
また、「\"」のエスケープが面倒で醜いというのは両者に共通した欠点と思います。

 さて、上記の2つの方法のデメリットを回避する方法として、サーバに ODBC/node.js と当方で開発した tpcsql.js を置き、FM クライアントから FMS に対して SQL を発行して CRUD する方法をご紹介します。

 以下で詳述のデータベースサーバ側でクエリ文を待ち受けする Node.js スクリプト tpcsql.js は、以下のページより無償ダウンロードいただけます。

tpcsql.js を使った CRUD テスト方法

以下、環境構築の方法を記します。

注:
  • cURLを使用するため、FileMakerクライアント は Ver.16 以降が必須となります。
  • FMSは Ver16 でのみ検証を行っています。  
  1. FMS 16 の Admin Console で ODBC/JDBC を有効にします。

  2. FM 付属の FileMaker ODBC ドライバを、サーバにインストールします。
    クライアントへのODBCのインストールは不要です。
  3. FMS サーバ環境に Node.js をインストールします。
  4. 上記のサイトより、tpcsql.js をダウンロードし、サーバ 上の任意の場所に配置します。
  5. tpcsql.js に付属の Readme.txt に従って、Node.js 関連パッケージ群をインストールします。
  6. コマンドプロンプト画面から、node tpcsql.js と入力し、Enter キーを押下します。
    以下のようなメッセージが画面に表示されたら、クエリ待ち受け状態となります。

    ここでは、Web サーバのデフォルトポート 80 で待ち受けしますが、すでに他の Web サーバが稼働中の場合は、tpcsql.js に記載されているポート番号を変更(例: 80→8080)し、再起動してください。
  7. 付属のサンプルファイル「TpcQueryTester10.fmp12」 をFMSに配置し、公開します。
    FMクライアントからアクセスできるように、必要に応じて、ファイヤウォールの設定を変更します。
  8. FMクライアントを起動し、上記7で公開したTpcQueryTester10.fmp12 を開きます。
    ログイン情報は tpcsql.js に付属のドキュメントを参照してください。
  9.  [URI]フィールドの hostname の部分を FMS16 のホスト名、または IP アドレスに変更し、“Go”ボタンを押してみてください。

    上記で、[odbcDriver]、[host]、[uid]、[pwd]、[database]フィールドは、FMS16 側から見た場合の設定をあらかじめ入力してありますので、そのまま “Go”で実行できます。
  10. 以下のようにクエリ結果が [result]フィールドに戻ってきたら成功です。
  11.  Data テーブルには 1000 件分のテストデータがあらかじめ登録されています。
    クエリ内容を変更することによって、CRUD 操作をお試しいただけます。
 本稿では データベースは FileMaker Server を使用していますが、MySQL や SQL Server など、ODBC対応であれば他のデータベースでもここに記載した方法は使用できると思います。

tpcsql.jsの他のプラットフォームでの利用

 当初、tpcsql.js は Raspberry Pi 等で iBeaconの情報を収集・加工し、リモートのデータベースをSQLで簡単にCRUDするという M2M な利用を意図して企画したのですが、「FMクライアントから使えたら便利かも?」と思い、公開することにしました。
 もともと、FMのサーバサイドで「SQLを実行」がサポートされているので、「?」な方もいらっしゃるかと思いますが、「役にたったよ」という方が現れたらウレシイです。
 尚、tpcsql.js のラズパイでの利用は、稿を改めてご紹介できればと思います。


(亀澤)

関連リンク

2017-11-05

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

 前稿では、iOS と FileMaker Go を使用して定位置にあるビーコンを監視する方法について記しました。この方法は簡単でとても導入しやすいのですが、ビーコンを監視する端末が多数となる場合、iPad や FileMaker の費用負担がのしかかってきます。また、数十台から百台を超える端末を管理するとしたら、iPad/iPhoneでは大変でしょう。 そこで小社では、FileMaker Go に依存せず、様々なプラットフォームで利用可能なビーコン情報収集サブシステム(以下、TpcBScan.js)を作りました。

多様なデバイスで動作する TpcBScan.js  

TpcBScan.jsは node.js、express.js、nobe.js等の node.jsファミリー群の環境下で稼働する ビーコン情報収集サブシステムで、Windows、Macintosh、iOS、Android、Linux 等をOSとするデバイスで動作します*1。デバイスはBLE対応である必要があり、BLEアダプタ未搭載の場合、BLEアダプタ(ドングル)が必要となります。
 その機能は FileMaker の RangeBeacons関数に準じますが、http リクエストに対して戻り値を返します。 戻り値にはRangeBeacons形式とJSON形式を指定できます。Macintosh/Windows の FileMaker から TpcBScan.js を利用する場合は、「URLから挿入」スクリプトステップを使用します。

*1 Windows (WebDirectを含む)、Maintosh、iPad、Linux (Raspbian) で動作することを確認しています


「FMEasy在庫 IWP/WD R1.5(開発版)」のユーザの皆様には、TpcBScan.js β版 をダウンロード頂けます。詳しくはこちらをご参照ください。(2017/11/8更新)

Raspberry Pi をビーコン監視端末にする

今回、ビーコン監視を行う端末には、安定性、廉価性、保守性に優れるRaspberry Pi(BLE と LANに対応する機種)を使用することにしましたが、BLE/LANであれば Raspberry 以外のデバイスでも構いません。

 システムを構築するにあたっては、各種処理をサーバを中心に行わせる方法と、 端末を中心に実行させる方法の2種類が想定されます。

左がWi-Fi/BLE付の Raspberry Pi Zero W(¥3,000位)、右が Wi-Fi/BLEアダプタを取り付けた Pi Zero(無印)


端末駆動型システム構成

2種類の方法の1つが「端末駆動型」(下図)で、Raspberry端末がビーコン管理に必要な情報(端末が担当するビーコンのUUID/Major/Minorのリストや 、テーブルに保存されている存否情報のリスト=ManagedBeaconsList)をアプリケーションサーバを経由しデータベースサーバから取得します。端末は担当するビーコンが発信する情報(ActiveBeaconsList)を TpcBScan.js を使用して取得します。端末は取得した ManagedBeaconsList と ActiveBeaconsList を比較し、差異があれば アプリケーションサーバに対してデータベース更新等のリクエストを行います。差異が全くない場合は、サーバに更新リクエストは行いません。端末が多くの処理を行うのに対し、アプリケーションサーバの処理はレコードの送信と更新に限られます。 この端末駆動型は端末数やビーコン数が多くサーバ負荷を軽減したい場合に有効なシステム構成と思われます。


図1

サーバ駆動型システム構成

もう一つの方法が下図のサーバ駆動型で、この場合、Rapberry 端末はサーバからのリクエストに応じて自身が担当するビーコンの情報(ActiveBeaconsList)をサーバに返すのみです。一方サーバは、上述の「監視端末駆動型」で端末が担った ActiveBeaconsList 作成処理以外の全てを行うことになります。サーバは各端末に順繰りにリクエストを送り、戻り値を処理していくため、端末が増えると「監視端末駆動型」に比べてサーバの負荷はグッと増えます。この構成は監視端末の数が少なく、サーバが過負荷にならない場合に有効なシステム構成と思われます。
図2

サーバ駆動型を FileMaker Server でやってみる

実は当初、「端末駆動型」システムでも「サーバ駆動型」システムでも、Raspberry(Linux) を使うのであれば、node.js/JavaScript や PHP 等によるWebプログラミングは必須だと思いこんでいたのですが、下図の構成であれば、FileMaker による開発のみで、「サーバ駆動型」を実現できることに気づきました。というのは FileMaker スクリプトには、「URLから挿入」と言うスクリプトステップがあり、このステップは FileMaker Server から実行できるからです。具体的には FileMaker Server から この「URLから挿入」を使用して、各 Raspberry 端末上の node.js に対して、ビーコン情報を返すように http リクエストを送ります。あとは「サーバ駆動型システム構成」で書いたように、FileMaker Server がすべての処理を行います。

図3

 ということで、小社では上図のシステム構成に基づき、多端末対応のFileMaker プロトタイプを作成し、4つの Raspberry と1つのWindows ― 計5台のビーコン監視端末を使用してテストを行いました。本来であれば500台程ビーコンを用意して、各端末に100台ずつビーコンを割り当ててテストしたいところですが、手持ちのビーコンが21台しかないため、各端末が同じ21台のビーコンを監視するように設定しています。

 下図が今回のテストで FileMaker で作成したプロトタイプの画面です。監視端末があるビーコンの情報を受信しない場合は当該ビーコンの[存否]フィールドに「×」が、受信した場合は「OK」が入力されます。


図4 FMPから“Multi-term. TpcBScan”を実行すると、後述のサーバサイドスクリプトが実行される

英語版の動画




 実際にFileMaker からサーバサイドのビーコン監視スクリプトを実行した時の FileMaker Server Console 画面が以下です。通常、[クライアント]にはコンピュータ名が表示されるのですが、サーバサイドスクリプトを実行している場合は、実行されているスクリプト名が表示されるます。 赤枠部がサーバから実行されているスクリプトで、このスクリプト([srv]subTpcB監視~)が5台の端末に対して ActiveBeaconsList (ビーコンから受信した情報)を FileMaker Server に送信するようにリクエストし、それを受信すると ManagedBeaconsList と比較して、必要に応じてデータベースの更新や、メール/SMSの送信等の必要な処理を行います。本「定位置監視ビーコンモデル」は継続してビーコンを監視し続けるモデルですので、赤枠部の各スクリプトは中止命令を受けるまで、常駐して処理を続けます。


図5

 さて、当初の予想ではこのシステム構成は サーバに大きな負荷がかかると思っていたのですが、実際にCPUのパフォーマンス(下図)を見てみると、予想ほどの負荷はかからないようです。
 FileMaker Server 16 は理論上は無制限(検証値的には500)の接続が可能ですので、理論上は無制限のビーコン監視端末を管理できます。

図6

SQL データベースの利用

前項では、FileMaker Server (FMS)は、ビーコン情報を取得し、ビーコンの存否を判断し、データベースを更新するというアプリケーションサーバとデータベースサーバの2つの機能を兼ねています。 一方、図3右下の点線部のように、ODBC対応のデータベースサーバ(以下、SQL DB)を利用する場合は、FMS をアプリケーションサーバとして使用することも可能と思われます。この場合、FMS は SQL DB に対する CRUD を担うことになりますが、CRUD には FileMaker の ESS と サーバサイドからの「SQL を実行」が使えます。以前、 FMS をSQL DB の帳票作成サーバとして使うという記事を書きましたが、FMSをアプリケーションサーバとして使用すると、いろんなことが簡単にできる可能性が広がると思います。


以上


(土屋)



関連リンク

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


関連リンク

2017-09-07

太古の FileMaker システムを延命させる! ― 後日談


 今年の4月に FileMaker Pro 5.5 を運用する Windows Server 2008 (32bit版、Remote Desktop Serviceを運用)をP2Vにより仮想マシン化するプロジェクトに関する記事を書きました。あれから4カ月、先月末、ようやく納品が終わりました。いろいろあってとっても苦労しました、トホホ… 以下、古いFileMakerシステムを仮想マシン化してHypervisor上で運用したい、という方の参考に多少ともなれば幸いです。

1. FileMaker Pro 5.5/6を仮想マシン上で運用する

今回、特に問題となったのは、仮想マシン上のFileMaker Pro 5.5/6(FMP)からFMSにアクセスしたときの操作が極端に遅くなること。今回、新マシン(下図のVM)と旧マシン(下図Win Server 2008)上の FMP から FileMaker Server 5.5(FMS)上の郵便番号.fp5(レコード12万件)に対しソートを実行し、この実行時間を遅速判断の1つの基準としました。




12万件ソートの時間計測は、異なる5つのHypervisor機(Dell PowerEdge 2台、HP Proliant 1台、Lenovo X 2台)上に仮想マシンを作成し、様々なチューニングを試しながら繰り返し行いましたが、最速で20秒、最遅では2分強と、サーバ個体やNICの設定により結果が大きく異なったのには閉口しました。

 では、仮想マシン上の Remote Desktop Service に FMP を乗せ、FMSにアクセスするシナリオで、旧マシンに比べ仮想マシンが遅い場合の対処方法を小社の今回の経験からご紹介します。
※一つずつ試してください。
  1. 物理NICが Broadcom NetXtreme Gigabit Ethernet の場合、NICの詳細設定で Virtutal Machine Queues を Disable にするとともに、Hyper-V Manager の仮想マシンの「ネットワークアダプター」で「仮想マシンキューを有効にする」のチェックを解除。
  2. NICの詳細設定で、「TCP/UDP Checksum Offload (IPv4)」と、「TCP/UDP Checksum Offload (IPv6)」を Disable にする。
  3. Hyper-V Manager で、(普通のネットワークアダプターではなく)レガシネットワークアダプターを構成する。
  4. ネットでHyper-Vのチューニング情報を漁って試す(例:Performance Tuning for Hyper-V Servers)。
  5. そもそもロジックボード設計が Hyper-V に適していない→マシンを変える
小社の今回の経験では、上記3が有力と思います。5の状況にならないようにするには、導入前にベンダーのSEに聞いてみるか、導入実績のあるサーバを導入するか、試用機を借りて事前テストする、位でしょうか。


2. FileMaker Server 5.5 を仮想マシン上で運用する

これについては、レガシネットワークアダプターよりも、普通のネットワークアダプタの方が有利(速い)というテスト結果です。

 同じ仮想マシンであるにもかかわらず、サーバとして利用するのと、クライアントで利用するのとで、採用すべき仮想NICの構成が異なるというのは不思議です。


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


(土屋)

2017-07-07

FileMaker 16 と iBeacon の適用モデルを考える

 FileMaker 16 では「領域監視スクリプトステップを構成」というスクリプトステップが新たに加わりました。これにより、 iOS端末が予め指定する iBeacon の電波を受信すると、スクリプトをトリガすることができるようになりました。本稿では、FileMaker Go と iBeacon の利用モデルについて少し掘り下げたいと思います。

 尚、本稿を執筆するにあたって、 iBeacon と iOS端末を使用したテストを行っておりますが、実装を伴わない思考実験的な内容も含まれていることをお断りしておきます。

iBeacon 適用モデル

本稿では、よく紹介される展示施設でビーコン接近時に展示物等の案内や説明を端末に表示する「少数非近接ビーコンモデル」と、倉庫等で多数のビーコンが近接存在する環境で目的のビーコンを特定する必要がある「多数近接ビーコンモデル」について、続稿では倉庫等で物品一つ一つにビーコンを取り付け物品の存否等を管理する「単品管理モデル」について、計3つの適用モデルについて考えます。

少数非近接ビーコンモデル

 iBeacon の利用例記事で見かけるのは、美術館などの展示施設で iBeacon を配置し、iOS端末でビーコン信号を受信時に展示物の案内を表示する、というものです。
下図の例は、各展示エリアの入口(各円の中心部)に iBeacon を配置し、iOS端末を手にする訪問者が入口に接近するとビーコン電波を受信し、端末にはエリアの展示物の案内が表示される、というものです。

 FileMaker 16上の「領域監視スクリプトステップを構成」スクリプトステップは、最大20までの領域監視を設定できるので、図のような小規模なものであれば、アプリ開発者は同スクリプトステップの引数の UUID、Major、Minor を指定し、各エリアに配置された当該のビーコン信号を拾った時に当該エリアの案内を表示するようにアプリを開発するだけとなります。順路を逆戻りして一度見たエリアをまた見たいという訪問者は、そのエリアの入口付近に近づけば、再度スクリプトが実行されて案内が表示されます。

 それでは、20を超えるエリア(監視領域)がある場合はどうでしょう? 順路を設定できるケースではエリアを離れた時点でその領域監視を削除し、新たな領域監視を構成すればよいかもしれません。上図を例にとれば、邦画エリアを出て浮世絵エリアの監視領域に入った時点で邦画エリアの領域監視を削除し、21番目のエリアの領域監視を構成する、といった具合です。

多数近接ビーコンモデル

 次に倉庫の棚卸を考えてみます。メーカーA社は複数の倉庫を有し、まず調布倉庫で棚卸の効率化を行おうと考えています。現在は、複数の棚卸作業者が商品リストを片手に倉庫内を回り、棚にある商品を数えてその数をリストに書き込み、その作業が終了するとデスクに戻って棚卸数をPCに入力しています。

システム要件

 現在の棚卸方法に不満のあるA社の経営者は、新たに以下の要件を満たす iBeaconシステムを導入したいと考えています。
  1. 倉庫内にある各棚(下図の各区画(A~I)の「棚1」~「棚25」、計150台)の正面中央にiBeacon を設置。
  2. 複数の作業者が iOS端末を持ち、「各棚に接近して“近い商品検索”ボタンをタップすると最も接近した棚にある全商品が端末画面上に一覧表示される」(最近接棚商品表示要件)。
  3. 各作業者は上記3で表示された商品の棚卸数を入力。その棚の全商品の入力を終えたら次の棚へ移動し、同様の差作業を行う(以下、この繰り返し)。
    これにより、棚卸作業に要する時間を短縮する。
各棚の正面に iBeacon を設置

 上記の依頼を受けた開発者T君は、第一段階としてシステムのプロトタイプを作成してA社の要求仕様に合致するシステムが作成できるかテストすることにしました。まずデータベーステーブルの設計を考えます。iBeacon には UUID(32桁の16進数)、Major(0~65535)、Minor(0~65535)(UMM)を設定でき、iOS 端末は UMM を含むビーコン情報を受信し、さらに FileMaker Go 16 はこのビーコン情報を BeaconRange 関数で取得することがでます。 T君は iBeacon と各棚をデータベース上で1対1で結び付けるように、以下のようなテーブル/リレーション設計を行いました。

 このリレーションを使用して以下のようなレイアウトを作成し、倉庫/UUID、倉庫区画/Major、棚名/Minor を登録できるようにします。

各区画/各棚毎に領域監視の設定と解除のボタンも配置しているが、本モデルのテストでは不使用

 さらに商品テーブルには [UUID](倉庫)、[Major](区画)、[Minor](棚)フィールドを用意し、各棚とその棚に置かれる商品を関連付けます。こうしておけば、特定の棚(iBeacon)にある商品を UUID/Major/Minor により検索できるようになります。

 次にT君は“近い商品検索”ボタンの仕様について考えます。上述の「最近接棚商品表示要件」という条件を満たすために、調布倉庫の一区画を図にしてみました。ビーコンは各棚の正面に設置されています。

A区画図
iBeaconは各棚正面の真中(棚3と6では円の中心)に配置、円内がiBeacon信号の到達範囲

 iOS端末をPの地点へ持って行き“近い商品検索”ボタンをタップしたと想定すると、端末に最も近い棚1にある全商品を検索する必要があります。そこでT君はまず RangeBeacons 関数の引数に調布倉庫の UUID とA区画の Major を指定して、端末が受信するすべての棚ビーコンの情報を取得することにしました。この時、RangeBeacons 関数 は棚1ビーコンのほか、2、6、7、11もしかすると棚3のビーコン情報も拾ってきます。幸いなことに、RangeBeacons 関数はUUID、Major、Minor(UMM)の他に「精度」(ビーコンと iOS端末間の距離)も返してくれるので、この「精度」が最小の値をもつ ビーコンが最も近接した棚ということになります。こうしてT君は最近接の棚ビーコンを特定し、そのビーコンの UMM を持つ商品レコードを検索・表示するスクリプトを作成し、“近い商品検索”ボタンに割り振りました。これでプロトタイプが完成です。

 A区画でプロトタイプのテストを行う前に、A区画の棚1~棚25の全てに UUID、Major、Minor を設定した iBeacon を取り付け、A区画の棚にある全商品レコードの[UUID]、[Major]、[Minor] の各フィールドには当該iBeaconの UUID、Major、Minor を入力し、商品と棚(iBeacon)を関連付けしました。これでテスト準備完了、いよいよテストです。T君は iOS端末を上図のP地点へ持って行き、作成したプロトタイプを起動、“近い商品検索”ボタンをタップしました。この時、RangeBeacons 関数は下表の値を返していました。表で最小の[精度]を持つ棚は「棚1」であり、よってiOS端末P は「棚1」に最も近接しているので、T君の考えた「最近接商品表示ロジック」によるスクリプトが的確に動作し、「棚1」にある商品を画面上にすべて検索・表示しました。

棚番
UUID
Major
Minor
近さ
精度
rssi
棚1 BA80FEBE-6823-42ED-AA6A-XXXXXXXXXXXX 0 1 2 0.68 -62
棚6 BA80FEBE-6823-42ED-AA6A-XXXXXXXXXXXX 0 6 3 3.64 -74
棚2 BA80FEBE-6823-42ED-AA6A-XXXXXXXXXXXX 0 2 3 6.71 -83
棚7 BA80FEBE-6823-42ED-AA6A-XXXXXXXXXXXX 0 7 3 10.56 -83
棚11 BA80FEBE-6823-42ED-AA6A-XXXXXXXXXXXX 0 11 3 21.33 -88
上表は説明を補助するための表で、表の値とA区画図は一致しない可能性があります。

 ここでまではとても良くできたT君でしたが、一つ問題に気づきました。それは、RangeBeacons 関数の「精度」が不安定で常に値が変動する点です。特に数十cm以上離れると実際とは数倍異なる距離を返すことがあります。上記の調布工場のケースでは各ビーコン間の距離が結構はなれており、相対距離は正しい(最近接ビーコンの距離値が最小)になると想定されるので問題にならないかもしれませんが、ビーコン同士がより近接する環境では、上記の「最近接棚商品表示要件」を満たせない可能性があります。
 その場合は、電波を遠くに飛ばさない近接特化型ビーコンや、(上記システム要件を一部変更する必要がありますが)ボタンを押したときだけに電波を発信するタイプのビーコンの採用を検討する必要があるかもしれません。

参考:

常時監視・単品管理モデル

本モデルでは、各物品に iBeacon を取り付け、常時物品の所在を管理します。倉庫の天井などに固定した端末を通じて、物品に異動があるった場合は常にサーバ上のデータベースを更新し、異常があった場合の自動メール送信処理等も重要になります。単品管理が必要な物品は高額あるいは貴重なものとなるので、iBeacon の信頼性に加え、iBeacon の管理機能(多数あるビーコンの電池残量や製品寿命の管理や、故障時の交換処理の簡易性等)も重要になると思われますが、このモデルについては稿を改めたいと思います(次項)。




(土屋)


参考リンク
関連リンク

2017-06-27

FileMaker データベース認証に oAuth を利用する

 FileMaker 16 の新機能を使用して弊社在庫管理システムテンプレート『FMEasy在庫』の機能を拡張するというテーマで、前回までに WebDirect を使用した宅配便送状の印刷と、AfterShipから配送データを取得してアプリ内で荷物追跡情報を表示する方法をご紹介してまいりました。今回はその締めくくりとして、oAuth による FileMaker データベース(以下、FileMaker DB)へのログインについてご説明します。

 一回目:FileMaker と WebDirect 16 で宅配便送状を印刷し、配送状況を追跡する
 二回目:cURL と REST API を使用し、FileMaker アプリ内で配送状況を追跡

oAuth 認証で FileMaker にログインし、出庫画面から送状発行と追跡をする
出庫画面から運送業者の送状を発行し、配送状況を追跡するまでの流れ

 oAuth は一連のデータベース操作の窓口を担う認証機能になりますが、FileMaker DB にパスワードを記憶させないという利点があります。

オープン認証 (oAuth) をざっと説明

 oAuth を簡単に説明すると、外部の Web サービスに登録されているユーザ情報を使うことによって、アプリケーションに代理ログインできるしくみです。Google アカウントや Microsoft アカウントなどを使って外部サービスにログインされた方もいらっしゃると思います。

 FileMaker 16 が oAuth 対応になり、通常の FileMaker アカウントの代わりに Google、Microsoft Azure Active Directory、および Amazon アカウントを使って FileMaker データベース(以下、FileMaker DB)にログインできるようになりました。


oAuth 経由で FileMaker にログインするための事前準備

 oAuth で FileMaker DB にログインするためには、以下のものをそろえる必要があります。

  1. FileMaker Server 16 と必要数分のアクセスライセンス
  2. 有効なドメインのサーバ証明書
  3. クライアント ID、シークレット、テナント ID (Asure の場合)
  4. oAuth 用ログインユーザアカウント

FileMaker で oAuth を有効にする方法

 oAuth 経由で FileMaker にログインするための具体的な手順を以下に示します。
ここでは、Google アカウントを例に進めていくことにします。

 作業の手順は FileMaker 公式にまとめられていますので、以下もご参照ください。
 オープン認証 (OAuth) 資格情報を使用したソリューションへのアクセス

  1. FileMaker Server にサーバ証明書をインポートします。
    FileMaker Server Admin Console にログインし、データベースサーバ→セキュリティの順にすすみ、「データベース接続に SSL を使用する」にチェックをつけて“証明書のインポート...” ボタンをクリックします。

    カスタムサーバ証明書をインストールする
    SSL を有効にし、証明書のインポートを選択する


     証明書のインポートダイアログが表示されますので、署名入りの証明書ファイル、プライベートキーファイル、中間証明書ファイルを指定してインポートします。

    カスタム証明書インストール用ダイアログ
    カスタム証明書インポートのダイアログ
  2. FileMaker Server を再起動します。
  3. http://console.developers.google.com/ にログインします。
  4. 認証情報→認証情報を作成の順にすすみ、「oAuth クライアント ID」 を選択します。

    oAuth クライアント ID を登録
  5. oAuth 同意画面を選択し、メールアドレスとサービス名を入力して保存します。
    oAuth 同意画面を登録
    oAuth 同意画面を登録
  6.  アプリケーションの種類の選択ページでは、「ウェブアプリケーション」を選択し、任意の名前を指定してから、リダイレクト先を指定します。

    oAuth のリダイレクトリンク先を登録
    oAuth 認証をウェブアプリケーションにし、そのリダイレクト先を指定する

    リダイレクト先は https://ドメイン名/oauth/redirect になるように指定します。
  7. 無事 oAuth クライアント ID が作成されると、以下のようなダイアログが表示されますので、クライアント ID とクライアントシークレットをメモしておいてください。

    oAuth クライアント ID とクライアントシークレットをメモする
    oAuth クライアントのクライアント ID とクライアントシークレットを取得する
  8. 再び FileMaker Server Admin Console にログインします。データベースサーバ→セキュリティの順にすすみ、クライアント認証を 「FileMaker と外部サーバーアカウント」に変更して設定を保存します。
    クライアント認証を「FileMaker と外部サーバアカウント」に変更
    クライアント認証を「FileMakerと外部サーバーアカウント」に変更する
  9. 外部サーバーアカウントとして Google の歯車アイコンをクリックすると、Google の設定ダイアログが表示されますので、手順 7. でメモしておいた Google クライアント ID と Google クライアントシークレットを入力し、“保存”ボタンをクリックします。
    Google クライアント ID とシークレットを入力する
    Google クライアント ID と Google クライアントシークレットを入力
  10. FileMaker Server を再起動し、手順 11. の Google アカウントのスライダーを有効にします。

 これで FileMaker Server で oAuth が使えるようになりました。

補足事項:
  • サーバ証明書をインポートした直後は、FileMaker Server を再起動しても FileMaker Server が証明書を認識しない場合があります。その場合は、いったんサーバ機を再起動すると認識されることがあります。
  • サーバ証明書のインポートに失敗した場合は、FileMaker Server のディレクトリでコンソールウィンドウを開き、fmsadmin certificate delete コマンドを実行すると、カスタム証明書を削除することができます。削除後はいったん FileMaker Server を再起動してから、証明書のインポートをやりなおしてみてください。


FileMaker データベースファイルへのユーザアカウントの登録

 FileMaker Server 側の oAuth 認証受付の準備が終わったら、データベースファイルにログインユーザアカウントを登録します。

  1. FileMaker Pro から管理者権限でデータベースファイルを開き、FileMaker のメニューより「管理」→「セキュリティ」の順に進みます。
  2. アカウントの一覧が表示されますので、認証方法を「Google」にし、そして「ユーザ名」にはGoogleにログインするためのメールアドレスをフルで指定します。

    oAuth ログイン用アカウントを FileMaker DB に登録する
    アカウント管理画面に oAuth ログイン用のユーザアカウントを登録する
  3. 同じ要領で、クライアント数分のアカウントを登録します。
補足事項:
  • 分離モデルを採用している FileMaker データベースシステムの場合は、関連するすべてのファイルに oAuth 用のアカウントを登録する必要があります。


oAuth による FileMaker データベースのログイン

 oAuth による FileMaker ログインの設定が終わったら、実際にログインして動作を確認します。

FileMaker Pro16 によるログイン

 FileMaker Server 16 で公開されているデータベースファイルに FileMaker Pro 16 クライアントからアクセスすると、以下のようなダイアログが表示されます。

oAuth 対応の FileMaker Pro 16 ログインダイアログ
oAuth 対応のFileMaker Pro 16 ログイン画面
ここで、Google ボタンをクリックすると、以下のようなアカウント選択ページが表示されますので、適切なアカウントを選択し、パスワードを入力してログインします。

FileMaker DB にログインする Google アカウントを選択
ログインする Google アカウントを選択
上図は、Web ブラウザに Google アカウントが記録されている場合のページですが、Web ブラウザにアカウントが記録されていなければ Google ログイン用のメールアドレスを入力するよう促されますので、正しいメールアドレスを入力します。

 Google アカウントのログインに成功すると、以下のようなダイアログが表示されますので、“許可”をクリックします。

ブラウザから表示される FileMaker プログラムの実行許可を求めるダイアログ
プログラムの実行許可

 すると FileMakerアプリの画面に戻ります。後の操作は FileMaker のユーザ権限にしたがって通常通りに行えます。

oAuth による FileMaker ログイン直後の Main Menu 画面(FileMaker)
oAuth によるFileMaker ログイン直後の FMEasy在庫 Main Menu 画面

WebDirect によるログイン

 WebDirect 用の公開リンクにアクセスし、開きたいデータベースファイルをクリックすると、以下のようなログインページが表示されます。

oAuth 対応 WebDirect サインインページ
WebDirect 用の oAuth 対応サインインページ


 ここで、Google ボタンをクリックすると、以下のようなアカウント選択ページが表示されますので、適切なアカウントを選択し、パスワードを入力してログインします。

WebDirect にログインする Google アカウントを選択
ログインする Google アカウントを選択

 
 Google アカウントのログインに成功すると、WebDirect で FileMaker DBが開きます。


oAuth による FileMaker ログイン直後の Main Menu 画面(WebDirect)
oAuth による WebDirect ログイン直後の FMEasy在庫 Main Menu 画面

懸案事項

 oAuth は事前設定さえ済ませてしまえば、あとはログインを許可するアカウントを FileMaker DBに登録するだけで使えるようになりますが、運用にあたっては以下のような問題が発生する可能性がありますので、ご留意ください。
  1. ログインに成功すると、FileMaker を終了しても、oAuth で管理される外部 Web サービスのセッションが残る
    これは他の Web サービスのセッション管理機能に依存しますが、Google の場合 FileMaker を終了させても、二回目以降に FileMaker DB にログインしようとすると、パスワードの入力を求めてこず、そのままログインできてしまいます。
  2. Web ブラウザにログインパスワードが保存されていると、第三者に勝手にログインされる恐れがある
    個人の専用パソコンからのアクセスなら、パスワード入力の手間が省けて便利ですが、複数のユーザで一つのパソコンを共有利用している場合は、勝手にログインされてしまう可能性があります。
 各自パスワード管理をしっかりやってね、で解決すればよいのですが、手軽さゆえ思わぬトラブルにつながりそうな機能なので、oAuth ログインを許可するアカウントのユーザ権限は入力・照会レベルにとどめるような工夫は最低限必要かと思います。


 oAuth の危険性を指摘する記事もネットで見つかりますので、日ごろから目を通しておくとよいですね。


 参考記事:第147回 便利と危険は裏返し 〜 知っておきたい、OAuthの仕組み 〜 (TDK Techno Magazine)




 土屋企画では FileMaker システムの受託開発およびコンサルティングを請けたまわっております。お問い合わせはこちらよりお願い致します。

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

(亀)