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

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をアプリケーションサーバとして使用すると、いろんなことが簡単にできる可能性が広がると思います。


以上


(土屋)



関連リンク

2013-01-16

FileMaker IWP (インスタントWeb公開) 上で JavaScript を使い、ページのリロードと印刷を行う方法

 FileMaker Pro/FileMaker Pro Advanced, FileMaker Server Advanced で インスタントWeb公開(Instant Web Publishing, 本記事では IWP で統一)を行うと、FileMaker Pro で開発したレイアウトをそのまま Web に公開してデータベースの更新や照会ができるようになります。

 現行で最新バージョンとなっている FileMaker 12 では、FileMaker Pro/FileMaker Pro Advanced の場合は、最大 5 ユーザまで Web での同時使用が可能となっており、これに対し、FileMaker Server Advanced の場合は最大 100 ユーザまで Web での同時使用が可能です。


 ただし、FileMaker Pro 本体に比べると、IWP には仕様上の制限があるため、開発時にそれらの制限を十分に考慮する必要があります。

 IWP でできないことは以下のとおりです。
  1. オブジェクトフィールドへのファイルのアップロード
  2. データのインポート/エクスポート
  3. FileMaker Pro のデータから PDF ファイルや Excel ファイルを作成
  4. FileMaker Pro のレポート閲覧
  5. レイアウト、レポート、スクリプト作成
  6. 警告音、メッセージポップアップ表示
  7. 印刷コマンド実行
 また、この他にもスクリプトトリガ、スクリプトステップ、条件付き書式などでも IWP に対応していない動作がありますので、FileMaker Pro 本体と IWP を併用する形でデータベースを運用する場合は、FileMaker Pro 側と Web 側での動作の違いに気を付けながら開発を進める必要があります。


 さて、今回は、上記に示した IWP の仕様制限のうち、1. オブジェクトフィールドへのファイルのアップロード、および 7. 印刷コマンド実行について対応方針を考えてみることにします。


【オブジェクトフィールドへのファイルのアップロード】

 オブジェクトフィールドそのものへファイルをアップロードする代わりに、php を使って Web サーバ上にファイルをアップロードし、そのファイルへのリンクを FX.php を使って FileMaker Pro データベースに書き込みます。

 FileMaker Pro 側の設定は、レイアウト上に以下のような Web ビューアを配置し、アップロード処理および FX.php 書込み操作を記述した php ファイルを指定します。



 php ファイルは Web サーバ上に配置してください。また、[Web ビューア内容とのインタラクションを許可] チェックボックスには必ずチェックを入れておきます。

 そのあと、IWP でデータベースを開くと、たとえば以下のようなページが表示されます。


 イメージとしては、ファイルアップロード後は、矢印が示すフィールド [FileURL] にそのファイルへのリンクを表示させるようにしたいわけですが、FX,php はバックグランドで操作されますので、ここは動的には変化しません。

 これを、JavaScript コマンドをページアップロード後に呼び出されるように組むことで、ページをリロードさせて反映させようというわけです。

 画面上に、「この部分が Parent」と表記しておりますが、Web ビューア(ピンク色)を自分自身とした場合、外のエリア(紫)が親 (parent) となりますので、JavaScript では parent に向けて処理をするようにします。



 parent.location.reload();


リロード後のイメージ



 FX.php を使った FileMaker Pro データベースへのデータ書込の話題は、以下の記事群をご覧ください。

【印刷コマンド実行】

 FileMaker Pro の印刷コマンドは、IWP では実行できません。
これでは、顧客一覧、見積書、請求書などの帳票を IWP で印刷したいときに不具合があります。

 この対策として、上記のファイルアップロード例と同じ要領で Web ビューアを配置し、印刷ボタンを配置したページを指定します。





 ファイルには、フォームの 印刷ボタンをクリックすると、JavaScript で以下のような関数を呼び出し、 parent ページを印刷するようにします。



function reportprint()
{
parent.focus();
parent.print();

}



 これにより、Web ブラウザの印刷ダイアログが表示されます。



 上図のように、印刷ボタンの部分もページとして印刷されてしまいますので、Web ビューアを配置する場所は 2 ページ目の先頭あたりにくるようにし、印刷時は 1 ページ目を選択するようにすると都合が良いでしょう。

以上

(亀澤)



【IWP関連記事】

【弊社のIWP関連製品・サービス】