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

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 のラズパイでの利用は、稿を改めてご紹介できればと思います。


(亀澤)

IoT/M2M関連リンク

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


IoT/M2M関連リンク

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 5/6等レガシーシステム関連記事

太古の FileMaker システムを延命させる! ― 後日談FileMaker(17/09/07投稿)
下記記事のレガシー延命スキームの実施と結果について。

太古の FileMaker システムを延命させる!(17/04/25投稿)
Remote Desktop Server/FileMaker Pro 5.5 搭載の Windows Server 2008 物理マシンを P2Vし、Hyper-Vに移行することにより、レガシーシステムの延命を図る。

FileMaker 5.5/6 をモバイルで使う(16/05/25投稿)
Android/iOS に Remote Desktop Client を載せて、FileMaker Go のようなことをしてみます。
 

今なお輝くFileMaker 5.5/6(16/05/23投稿)
レガシーFileMaker の意外な利点。

土屋企画では、FileMaker レガシーシステムの延命、拡張、仮想マシンへの移行に関するご相談を請け賜わっております。


(土屋)

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 システムの受託開発およびコンサルティングを請けたまわっております。お問い合わせはこちらよりお願い致します。

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

(亀)




2017-06-26

cURL と REST API を使用し、FileMaker アプリ内で配送状況を追跡

 前回は在庫管理テンプレート『FMEasy在庫』をカスタマイズし、宅配便の送状を印刷・登録するところまでをご説明しました。

 前回の記事: FileMaker と WebDirect 16 で宅配便送状を印刷し、配送状況を追跡する
 参考:FMEasy在庫 IWP/WD R1.5


AfterShip による配送状況の追跡
出庫画面から運送業者の送状を発行し、配送状況を追跡するまでの流れ


 本稿では、出荷後の配送状況の追跡機能を実装する方法(上図の7.と8.)について説明していきます。
 機能の実装に入るまえに、FileMaker から出荷物の配送状況を取得するしくみについて触れます。

世界402社と日本3社の配送業者の追跡データAPIを提供する AfterShip

  FileMaker 単体では宅配便の配送状況の情報を取得することはできません。このため、各宅配業者が提供する追跡サービスを使用することになります。

 これまでは、データ受信の窓口となる API サービスを利用するためには宅配業者別に手続きが必要になり、API 接続手順の把握とシステムへの追跡機能の実装までに大変な手間と時間がかかってしまったのですが、AfterShip という荷物追跡サービスは世界 402 社の配送業者の追跡データ API を提供しており、その中に日本のヤマト運輸、佐川急便、日本郵便の 3 社も含まれています。

 AfterShip が対応している日本の宅配便会社(Japan を選択)

 つまり、AfterShip の API を利用すれば、これら 3 社の配送状況の追跡をまとめて処理でき、FileMaker の送状発行機能と連携させることによって、送状の印刷から荷物追跡までがトータルに行えるようになります。

AfterShip の利用料金について


 2017年6月26日現在、AfterShip は 1月あたり 100 個までの出荷物の追跡が無料となっています(Basic プラン)。
 100 個を超える荷物を追跡するには、その個数に応じた料金が適用される Premium プラン、10万個を超える場合は個別対応の Enterprise プランという料金が適用されます。

 価格プランはこちらを参照してください。
 https://www.aftership.com/pricing

 たとえば、一月あたり 10,000 個なら $173/月、50,000 個なら $573/月となりますので、出荷量に応じた追跡計画を立てることができます。


7. AfterShip に配送状況を問い合わせる


 AfterShip の API サービスを利用するまえに、AfterShip へのユーザ登録が必要になります。

 AfterShip ユーザ登録・ログインページ
 https://secure.aftership.com/signup/

 google アカウントをお持ちの方は、google アカウントでログインするだけで自動的に AfterShip に登録されます。

 FileMaker から AfterShip API を利用できるようにするには、さらに API Key の取得と配送業者の登録が必要になります。

  1. AfterShip API Key を取得する

    AfterShip へのユーザ登録が終わったら、設定ページから API の順に進み、API Key を取得します。 
     通常は登録完了時に自動的にデフォルトの API Key が付与されますのでそれを使えばよいですが、必要に応じて Key を追加生成することもできます。

    AfterShip API key の取得

  2. 追跡対象の配送業者(couriers)を登録する

    出荷物の追跡を行いたい配送業者を登録します。設定ページから couriers の順に進み、inactive 入力ボックスに japan と入力すると、日本の配送業者が表示されますので、その中から必要な業者を選びます。

     以下の図は、ヤマト運輸の選択まで終わったところです。

    配送業者(couriers)の登録ページでヤマト運輸の登録が終わったところ


 それでは、いよいよ FileMaker からAfterShip を呼び出すための設定をします。
 AfterShip API は REST 形式になっており、配送状況の追跡を行うためには基本的に以下の情報が必要となります。
  • AfterShip API への URI(https://api.aftership.com/v4/
  • 配送会社識別コード(slug)
  • 送状番号(tracking_number)
 配送会社識別コードと送り状番号は FileMaker のユーザインタフェースから登録できるようにしておき、AfterShip API からの応答データを登録するためのフィールド群も用意します。

 下図の赤で囲んだ部分をご覧ください。ポータルの 2 段目が AfterShip から取得する追跡データを保存するためのフィールド群です。荷物(送状)の追跡を行う場合は、当然[送状No]も必要になります。


 AfterShip API の公式ドキュメントはこちらです。

 AfterShip API Documentation
 https://www.aftership.com/docs/api/4/overview

 それでは、このドキュメントに従って、FileMaker から AfterShip API に接続してみましょう。

 AfterShip への送状番号の登録


 AfterShip 経由で荷物の配送状況を追跡するには、先に送状番号を AfterShip に登録しておく必要があります。

 登録用の URI は https://api.aftership.com/v4/trackings/ になります。
 この URI に送状情報を POST メソッドで送信すれば、AfterShip に登録されます。

 php で記述した場合、たとえばこのようになります。

PHP

<?php

    //build header 
    $header = array( 

        'Content-Type: application/json',
        'aftership-api-key: cfa68bc1-5b9b-4ba2-b3c8-XXXXXXXXXX'

    ); 


    //build invoice data
    $data = Array(
        'tracking' => Array(
            'slug' => 'taqbin-jp',
                'tracking_number' => '44361185XXXX',
                'title' => 'YAMATO POST TEST'
        )
    );  

 
    //post data using curl
    $curl = curl_init();
    curl_setopt( $curl, CURLOPT_URL, 'https://api.aftership.com/v4/trackings' );
    curl_setopt( $curl, CURLOPT_CUSTOMREQUEST, 'POST' );
    curl_setopt( $curl, CURLOPT_HTTPHEADER, $header ); 
    curl_setopt( $curl, CURLOPT_POSTFIELDS, json_encode( $data ));
    curl_setopt( $curl, CURLOPT_SSL_VERIFYPEER, true );
    curl_setopt( $curl, CURLOPT_RETURNTRANSFER, true );
    $result = curl_exec( $curl );
    $json = json_decode( $result );
    curl_close( $curl ); 

?> 

 $header の中に json データ送信を宣言し、 aftership-api-key を指定します。
 $data の中に指定している slug がヤマト運輸を示す taqbin-jp、 tracking_number が送状番号、title が AfterShip の中で送状の識別を用意にする任意のタイトルになります。
 送信結果は最終的に $json 変数に格納されます。

 これを FileMaker の 「URL から挿入」ステップで記述すると、たとえばこのようになります。

FileMaker

変数を設定 [ $data; 値:
JSONSetElement ( "" ; 
        [ "tracking.tracking_number" ; "44361185XXXX" ; JSONString ];
        [ "tracking.slug" ; "taqbin-jp" ; JSONString ]; 
        [ "tracking.title" ; "YAMATO POST TEST" ; JSONString ] 
    )
 ]
URL から挿入 [ $json; "https://api.aftership.com/v4/trackings"; 
    cURL オプション: "-H \"Content-type: application/json\" " & 
        "-H \"aftership-api-key: cfa68bc1-5b9b-4ba2-b3c8-XXXXXXXXXXX\" " & 
        "-d " & $data ] 
    [ ダイアログなし; SSL 証明書の検証 ]


 php に比べると指定方法に多少コツがいりますが、かなりシンプルになりますね。

 $data の中に送状情報を組み立てておき、これを「URL から挿入」ステップの cURL オプションの -d オプションの中に指定することによって送信します。

 cURL オプション:
 "-H \"Content-type: application/json\" --- ヘッダオプション。json 形式のデータ送信を宣言
 "-H \"aftership-api-key: cfa68bc1-5b9b-4ba2-b3c8-XXXXXXXXXXX\" --- ヘッダオプション。aftership-api-key を指定
 "-d " & $data --- データオプション。$data に格納されているデータを送信

 送信結果は $json 変数に格納されますので、その中から必要項目を取り出せばよいことになります。

AfterShip API から戻される結果

 AfterShip API の戻り値は json 形式になります。前述の例では $json 変数に戻ってくるので、これを解析して利用します。
 データは一行で返りますので、これを FileMaker Pro 16 の JSONFormatElements 関数を通すと見やすいフォーマットに整形されますので、戻りデータを確認する際に有用です。

 JSONFormatElements( $json ) の結果はたとば以下のようになります。

JSON

{
 "data" : 
 {
  "tracking" : 
  {
   "active" : true,
   "android" : [],
   "checkpoints" : [],
   "created_at" : "2017-06-24T13:08:42+00:00",
   "custom_fields" : null,
   "customer_name" : null,
   "delivery_time" : 0,
   "destination_country_iso3" : null,
   "emails" : [],
   "expected_delivery" : null,
   "id" : "594e645ab6ee5fcf0b7XXXXX",
   "ios" : [],
   "last_updated_at" : "2017-06-24T13:08:42+00:00",
   "note" : null,
   "order_id" : null,
   "order_id_path" : null,
   "origin_country_iso3" : null,
   "shipment_delivery_date" : null,
   "shipment_package_count" : 0,
   "shipment_pickup_date" : null,
   "shipment_type" : null,
   "shipment_weight" : null,
   "shipment_weight_unit" : null,
   "signed_by" : null,
   "slug" : "taqbin-jp",
   "smses" : [],
   "source" : "api",
   "tag" : "Pending",
   "title" : "YAMATO POST TEST",
   "tracked_count" : 0,
   "tracking_account_number" : null,
   "tracking_destination_country" : null,
   "tracking_key" : null,
   "tracking_number" : "44361185XXXX",
   "tracking_postal_code" : null,
   "tracking_ship_date" : null,
   "unique_token" : "deprecated",
   "updated_at" : "2017-06-24T13:08:42+00:00"
  }
 },
 "meta" : 
 {
  "code" : 201
 }
}


 ここで、"meta" :{"code" : 201} が登録成功を示すシステムコードです。このコードが返れば AfterShip のブラウザ管理画面の追跡リスト上にこの送状データが表示されるようになります。
 また、このコードを拾って FileMaker テーブルのフィールド(下図の[ステータスコード])に登録したい場合は、以下のように関数を指定します。

 JSONGetElement ( $json ; "meta.code" )

 同じ要領でタイトルを下図の[aftershipタイトル]に登録する場合は、関数を以下のように指定します。

 JSONGetElement ( $json ; "tracking.title" )

 AfterShip への登録日時を下図の[ステータス]に登録するには、JSONGetElement ( $json ; "date.tracking.created_at" )と指定します。

AfterShip に送状情報を登録した直後の様子

 “登録”ボタンにより AfterShip に送状を登録した後に、ブラウザでAfterShipの送状管理画面を見ると、下図のようになっています。

AfterShip に登録された送状の一覧

8. 配送状況の問い合わせ結果を FileMaker に登録する

 AfterShip に配送状況を照会する


 AfterShip に荷物を登録後、配送状況を追跡するための URI は https://api.aftership.com/v4/trackings/配送業者コード(slug)/送状番号(tracking_number) になります。
 この URI に???送状情報を GET メソッドで送信すれば、AfterShip から配送状況が JSON 形式のデータで戻されます。

 AfterShip への配送状況の問い合わせを FileMaker の 「URL から挿入」ステップで記述すると、たとえばこのようになります。

FileMaker

URL から挿入 [ $json; "https://api.aftership.com/v4/trackings/" & 
    "taqbin-jp" & "/" & 
    "44361185XXXX"; 
cURL オプション: "-H \"Content-Type : application/json\" " & 
    "-H \"aftership-api-key: cfa68bc1-5b9b-4ba2-b3c8-XXXXXXXXXXX\" & "\" " ] 
[ ダイアログなし; SSL 証明書の検証 ]


 登録のときより照会の方が単純ですね。
 これによって $json 変数に配送状況の照会データが戻ります。
 照会に成功すると、 "meta" :{"code" : 200} が返ります。
 オプション解説、およびデータの読み出し方法の基本については、前述の登録方法の項をご覧ください。


 なお、最終の配送状況のみを戻したい場合は、 URI を https://api.aftership.com/v4/last_checkpoint/配送業者コード(slug)/送状番号(tracking_number)  にすればよいです。


 下図は各送状の“照会”ボタンを実行し、[ステータス](一般ユーザ向けに配送状況を表示)と[ステータスコード](システム管理者向けにシステムコードを表示)の更新が完了したときの画面です。

送状情報を AfterShip に問い合わせたときの様子

  上図では最終ステータスのみを記録するように作成していますが、機会があれば[追跡履歴]の取り出し方も説明できればと思います。


外部サービスを使うデメリットについて

 FileMaker 単体でできないことは外部サービスの力を借りることになりますが、導入時は魅力的に見えたサービスであっても、継続運用していくうちに様々な問題に直面することがあります。
そこで最後に外部サービスを利用する際の注意点をいくつか挙げておきます。
 
  1. バージョンアップに伴い、従来の呼び出し方法では動作しなくなる
    FileMaker と外部サービスとの連携が取れなくなる恐れがあります。
    外部サービスを導入する場合は、こまめなチューニングも考慮する必要があります。
  2. 無料サービスが有料化される
    そのサービスなしでは業務が回らない場合に、予期せぬコスト増大を招く恐れがあります。
  3. 良心的に見えた料金が値上がりする
    サービス提供側が料金を値上げするのはよくあることです。その場合、上記と同様にコスト増大が発生します。
  4. 社外秘のデータが外部に把握される
    サービスの内容にもよりますが、たとえばアンケート収集・解析サービスや、SNSサービス、翻訳サービスなど、社内用のデータを外部サービスと連携させて利用する必要がある場合、機密情報を外部サービスに流さないように注意を払うことはもちろんのこと、サービス提供会社の安全性やセキュリティ対策なども調査する必要があります。
  5. 終了する
    有料、無料にかかわらず、サービス提供側の事情でサービスが終了すると、そのサービスがシステムにとって重要なポジションを占める場合には、代替サービスの選定やシステム修正等の手間が増えることになります。


  FileMaker 16 の機能追加によって、外部 Web サービスとの親和性が向上しましたが、本格的にサービスを導入をするには、上記のような問題を視野に入れたうえでプロジェクトを設ける必要がありますので、発注側、受注側双方の理解が重要かと思います。


(亀)



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