2017-06-26

FileMaker と WebDirect 16 で宅配便送状を印刷し、配送状況を追跡する

 FileMaker 16 では cURL、JSON、oAuth などの Web 関連機能が多数搭載されました。これらを使用すると、ネット時代に適応した多様なソリューション開発ができそうです。

 そこで本稿では、弊社在庫管理テンプレート『FMEasy在庫』を使い、出庫画面に宅配便の送状発行機能と、出荷後に荷物を追跡する機能を追加する方法を考えてみます。


 参考:FMEasy在庫 IWP/WD R1.5


注:
 本稿は『FMEasy在庫』のユーザでない方でも、宅配送状の設計やWebDirect 16 によるPDF出力の方法、cURL/JSONを使用した荷物追跡機能の実装に関しては参考にはなるかと思います。


 処理の流れはざっと下図のようになります。本稿では2.~6.について説明致します。


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

1. oAuth による認証

 上図の冒頭部分のoAuth による認証については、別稿にてご案内したいと思います。

2. 出庫登録をする

 出庫登録は『FMEasy在庫』テンプレートにあらかじめ搭載されている機能のため、ここでは説明を省略します。
 『FMEasy在庫』は基本機能は無償でご使用いただけますので、出庫機能をお試しになりたい方はこちらからダウンロードしてください。

3.送状を登録する

 出庫(売上)伝票の作成後に物品を発送するための宅配便送状を登録するためのインタフェースを用意します。

 まず送状データを管理するための送状テーブルを新設し、リレーションシップ画面で出庫テーブルと送状テーブルをリレートします。詳細は省略しますが、1件の出庫データについて複数の宅配便送状を登録するように設計すると、複数個口に対応できるようになります。
 既存の出庫レイアウトにタブオブジェクトを配置し、出庫タブに出庫明細関連フィールド、送状タブに送状関連フィールドを配置します(下図参照)。

1出庫伝票に対して複数の宅配便送状を登録できるように設計しましょう 

 ポータルの上段には宅配送状とその印刷に必要なフィールドが、下段には荷物追跡に必要なフィールドが配置してあります。送状テーブルの設計時に参考にしてください。
 下段の荷物追跡関連フィールドには、外部 Web サービス(AfterShip)に配送状況を問い合わせ、その結果を自動入力します。この追跡機能については、別稿にて詳細を説明します。

 『FMEasy 在庫』をご利用のお客様へ 


 『FMEasy 在庫』を FileMaker 16 の WebDirect で開くと、下図のようにボタンの欠けが発生することがあります。

『FMEasy 在庫』の出庫画面を WebDirect 16 で表示すると一部のボタンが欠ける

 これは FileMaker WebDirect の上位互換性によって生じる問題のため、お客様の方でFileMaker Pro 16 を使ってボタン幅を調整してください。
 

4.WebDirect から PDF 出力できるようにする

 宅配便の送状フォーマットに準じたレイアウトを用意してておき、“印刷”ボタンをクリックして送状を出力します。 複数の宅配便や代引等に対応するとき場合は、その分だけレイアウトを用意し、スクリプト実行時に適切なレイアウトを選択します。
 FileMaker 16 の WebDirect は PDF 出力対応になりましたので、ここでは送状の“印刷”ボタン実行時に送状を PDF 出力するようにスクリプトを組んでみます。

 FileMakerクライアント情報は Get ( アプリケーションバージョン ) 関数を使うことによって取得できます。
 クライアントが WebDirect の場合は、Web Publishing Engine を含む文字列が返ります。WebDirect からのアクセス時に「レコードを PDF として保存」ステップを実行するようにします。 下図で赤く囲んだ部分が WebDirect アクセス時の PDF 出力関連部となりますので、参考にしてみてください。

「送状印刷Btn」スクリプト(赤囲み部分が WebDirect 向け PDF 出力ステップ部分)

注:
少し調べてみたのですが、iOS(iPad/iPhone)に対応した水平プリンタは存在しないようです。

5.送状を水平プリンタで印刷する

 前述の「送状印刷Btn」スクリプトでは、FileMaker Pro クライアント使用時には印字データが直接プリンタへ送られますが、WebDirect 使用時には サーバ上で送状のPDFが作成され、そのPDFファイルを開いて印刷することになります。

WebDirect では PDF のダウンロードとPDFの処理方法をユーザが選択する必要があるので、少し面倒

6.送状番号のバーコードを読み取って登録する

 宅配便の送状を印字したら、バーコードリーダーや iPhone などのバーコードスキャン機能を使い、送状に記載されている送状番号のバーコードを「送状タブ」上の[送状No]フィールドに登録できます。バーコードを読み取るか、手入力により[送状No]に登録すると下図のようになります。

送状のバーコードをスキャナで読み取り、[送状No]フィールドに入力したところ


 次回は、出荷後の荷物の追跡を FileMaker で行う方法についてご紹介します。




 ※土屋企画では FileMaker によるシステムの受託開発およびコンサルティング業務を請けたまわっております。業務関連のご質問はこちらよりお寄せ願います。


(亀)

2017-06-14

FileMaker WebDirect 16 のロードバランス

 前回は FileMaker Server 16 の WebDirect (WebDirect 16)の構成をマスタサーバ 1 台構成にした場合と、ワーカマシン 5 台構成にした場合とで、スレッド数(接続数)や Ramp-up(全スレッドを生成するまでの時間)の条件を変更しながらパフォーマンス計測を行いました。 
 本稿では ワーカマシン 5 台構成で WebDirect 16 のロードバランスがどのように機能するのかを見てみます。
【ワーカマシン5台構成のイメージ】

サーバ 5 台構成時 のロードバランス

 複数のワーカマシンで構成される WebDirect 16 は Webクライアント(ブラウザ)からリクエストを受信すると、より負荷の低いマシンにそのリクエストを割り当てます(ロードバランス)。
 下図は異なる 5 台のクライアント PC のブラウザから WebDirect にログインしたところですが、より負荷の低いワーカマシンにリクエストが割り振られていることがわかります。
FileMaker Server 16 Admin Console のステータス画面
 上図のような低負荷の状態では WebDirect のロードバランスが適正に機能していることが確認できます。ちなみに、ワーカマシン 1 は Webサーバ機能の他に、データベースサーバ機能とロードバランスの機能も担うため、他のワーカマシンの負荷が相当程度高くなるまでの間、自身では HTTPリクエストを処理しないようです。
 次に、WebDirect の負荷を増減させるとどうなるのか、Apache JMeter を使ってテストしてみました(下図)。

【表1】
No ワーカ数 スレッド ループ Ramp
(秒)
 
リクエスト/秒 所要時間(秒) 失敗数 1Recの平均作成時間(秒) 備考
1 5 500 1 0.5 1000 46 128 0.092  1回計測
2 5 500 1 2 250 58.5 1.5 0.117  2回計測
3 5 500 1 5 100 60 0 0.120  1回計測
4 5 500 1 7 71.4 49 0 0.098  1回計測
5 5 500 1 30 16.7 48 0 0.096  5回計測
6 5 500 1 40 12.5 48 0 0.096  5回計測
7 5 500 1 60 8.3 60 0 0.120  1回計測
8 5 500 1 90 5.6 92 0 0.184  1回計測

 本テストは 500 スレッド(≒500ユーザ)から 、出庫伝票(出庫ヘッダレコード1と出庫明細レコード1)を作成する FileMaker スクリプトを実行し、最初のリクエスト発行から 500 件目の出庫伝票の作成が完了するまでの[所要時間(秒)]を計測しています。Ramp は 500 スレッドを生成する時間です。
 たとえば、テスト No.1 では 500 のスレッドを 0.5 秒の間に作成し、最後のレコードが作成し終わるまでの[所要時間(秒)]が 46 秒であったことを示しています。[失敗数]は本来 500 件の出庫伝票が作成されるべきところ作成に失敗した件数を示しており、No.1 では 128 件の失敗(伝票未作成)が発生しました。下図は No.1 実行時のワーカ割り振りの状態です。


Ramp が 0.5 では接続がワーカマシン 1 に極端に集中してしまう

 0.5 秒間に 500 スレッドが発生する高負荷状態ではワーカマシン 2 に割り振りが集中し、ロードバランスが適正に機能せず、128件のレコード作成処理が失敗しています。

 次にテスト No.4 ( Ramp:7秒)のロードバランスを見てみましょう(下図)。ワーカマシン 3、5 への割り振りが大分多いですが、ワーカ 2、4 にも 80 程度のスレッドが割り振られています。
 
500 同時接続で Ramp 7 秒 のときのサーバ割り当ての様子

 下図は Ramp を 60 秒にしたときの割り振り状態です。ワーカマシン 2~4 にはほぼ均等にスレッドが割り振られていて、ワーカマシン 1 (マスタ)は若干少なめに割り振られています。

500 同時接続で Ramp 60 秒 のときのサーバ割り当ての様子

  以上のように、WebDirect 16 は短い時間に極端にアクセスが集中すると、ロードバランスが適に機能しない可能性があります。アクセスの間隔が長くなるに従い、HTTP リクエストが各ワーカマシンに均等に割り振られるようになると思われます。

エラーが発生しない適正なリクエスト頻度

 下図は表1 をグラフ化したものです。Ramp が 2 秒迄だとエラーが発生しますが、Rampが 5 秒になると全 500 スレッドがエラー無く終了します。500 スレッド÷ 5 秒で 100 スレッド/秒、つまり1秒間に 100 のリクエストであればエラーが発生しません。
 ただ、所要時間は 60 秒なので、この結果を実運用に適用できると仮定すると、ユーザがリクエストを発行してから 60 秒程度、待たされることになります。Ramp が 60 秒、つまり 1 秒に 10 弱のリクエストの場合は、ユーザの待ち時間が数値上はほぼ無くなります。1 秒あたり 10~100 リクエスト程度の範囲に、安定運用可能なリクエスト頻度の目安があるのかもしれません。



マスタ1台構成 vs ワーカ5台構成

 最後に、下図は500スレッドの処理を完了するまでの時間を、1 サーバ構成と 5 ワーカマシン構成でパフォーマンスを比較した折れ線グラフです。折れ線の左の部分は、7 秒間に 500 のスレッドからのリクエストを処理する場合、1 サーバ構成の方が 5 ワーカ構成より有利であることを示しています。
 本テストは 7 秒~90 秒という短い時間内で終了してしまうテストなので、より長い時間、継続的に負荷がかかるようなケースには当てはまらないかもしれませんが、ワーカを増やせば実行速度も増す、と単純に想定することはできないことを示していると思います。



(亀)

2017-06-09

WebDirect 16 ワーカマシン構成による500+スレッド 同時接続テスト


  FileMaker Server 15 の WebDirect (WebDirect 15)では、最大同時接続数は 100、構成サーバは最大2台まででしたが、FileMaker Server 16 の WebDirect (WebDirect 16)では最大同時接続数が500、構成サーバは最大5台までとなりました。

 前稿では Apache JMeter を使用し、WebDirect 16 に対して25セッションでレコードを作成するテストを行いました。結果、旧版 WebDirect に比べパフォーマンスが向上し、エラー(レコードの作成失敗)が発生しないことを確認しました。 WebDirect 16 が実用段階に近づいていることを実感しました。

 今回は前回と同じく JMeter を使用し10~500+ のスレッドからレコードを作成するテストを実施しました。 

WebDirect 16 で 500 同時接続を実現するためのワーカマシン構成

 最初にインストールについて少しだけ触れます。WebDirect 16 では、1台のマスタマシンと 最大4 台迄のワーカマシンを構成できます。インストール自体は、下図のようにマスタマシンかワーカマシンを選択するだけなのでとてもシンプルです。 

マスタマシンかワーカマシンかをインストール時に選択すればよい

 ワーカマシン展開の詳細は、FileMaker 16 WebDirect ガイドの『展開オプション』の項をご覧ください(p20~30) 。以下の抜粋イメージが参考になると思います。


FileMaker® Server16インストールおよび構成ガイド『第 3 章 複数のマシンでの FileMaker Server の展開』(P.22)より

 

サーバ構成

 今回のテストでは、 Hyper-Vを 搭載する2台の物理マシンを用意し、1台に3つの仮想サーバ(ワーカマシン 1~3)、もう1台に2つの仮想サーバ(ワーカーマシン 4 と 5)を入れています。

  • マスタマシン(兼ワーカマシン1):
       CPU: 3.0Ghz
       コア数/メモリ: 4core 8GB RAM(FileMaker社推奨構成)
       Windows Server 2012 R2 (64bit)
  • ワーカマシン2:
       CPU: 3.0Ghz
       コア数/メモリ: 4core 8GB RAM
       Windows Server 2012 R2 (64bit)
  • ワーカマシン3:
       CPU: 3.0Ghz
       コア数/メモリ: 4core 8GB RAM)
       Windows Server 2012 R2(64bit)
  • ワーカマシン4:
       CPU: 2.93Ghz
       コア数/メモリ: 4core 8GB RAM
       Windows Server 2016 (64bit)
  • ワーカマシン5:
       CPU: 2.93Ghz
       コア数/メモリ: 4core 8GB RAM
       Windows Server 2016 (64bit)

WebDirect のロードバランス

 JMeter によるテストに入るまえに、異なる 5 台のクライアントマシンの Web ブラウザから WebDirect 16に同時アクセスし、WebDirect がどのようにロードバランスを行うのか ― どのようにマスタ機が接続をワーカマシンに割り振るのか ― を観察してみました。
 JMeter のような負荷テストツールではなく、実際のブラウザで WebDirect のリアルな動きを確認しておくことは、意味があると思われます。
 結果として、マスタマシン(兼ワーカマシン1)にクライアント接続が割り当てられることはなく、ワーカマシン ワーカマシン2 に 2 接続、ワーカ3、4、5 にそれぞれ 1 接続ずつ割り当てられました。
5台のクライアント PC から WebDirect にアクセスしたときのサーバ割り当て状況

 また、ひとつのWebクライアントが複数の 5つのブラウザタブを開いた状態で、WebDirect にアクセスした場合にも、ワーカマシン2 に  2 接続、ワーカマシン3、4、5 にそれぞれ 1 接続が割り当てられましたが、この時もワーカマシン1 に割り当てられることはありませんでした。
1台のクライアント PC の Web ブラウザで 5 つのタブから同時接続したときのサーバ割り当て状況
 このように、WebDirect は基本的に、接続先のワーカマシンの負荷状態を判断し、より負荷の低いワーカにルートします。
 ※ワーカマシン1(マスタ) はデータベースサーバおよび管理ツールが稼働しており、他のワーカマシンに比べると負荷が高いため、WebDirect 割当先になりにくいと考えられます。もちろん、マスタ1台の構成では、 このマシンがWebDirect の処理も併せて行います。

 

JMeterシナリオ

 JMeter を使用しセッションを10~500+作成、各セッションから FileMaker のスクリプトを実行して出庫伝票(ヘッダレコード1、明細レコード1)するシナリオを作成しました。
 

1 台構成でのテストと結果

 さて、JMeterによるテストを見ていきます。最初にマスタ1台だけの構成で上記のJMeterシナリオを実行してテストを行いました。結果は下表のとおりです。表中、Ramp(秒) はすべてのスレッドを送信し終わるまでの所要秒数を示しています。

 表の見方 を テストNo 4(スレッド=100)を例に説明します。No.4 は、0.5秒間に100のスレッドを作成し、開始から終了までに 6.4 秒かかっていることを示しています。失敗数は作成されなかったレコード数(エラー)で、No.4は 100 すべてのスレッドが成功し、100 件の出庫伝票が作成されました。  尚、各テストは特に記載が無ければ 5 回ずつ実施し、所要時間と失敗数はその平均値をとっています。
【表1】
No ワーカ数 スレッド ループ Ramp
(秒)
 
所要時間(秒) 失敗数 1Recの平均作成時間(秒) 備考
1 1 10 1 0.5 1 0 0.100 
2 1 20 1 0.5 1.2 0 0.060 
3 1 50 1 0.5 3.4 0 0.068 
4 1 100 1 0.5 6.4 0 0.064 
5 1 200 1 0.5 14 0 0.070  2回計測
6 1 300 1 0.5 23 0 0.077  1回計測
7 1 350 1 0.5 19 76 0.054  1回計測
8 1 400 1 0.5 17 142 0.043  1回計測
イタリック(斜体)部分は1回または2回のみテストを実施

  FileMaker社はマスタ1台構成下での最大接続数 を100 としているだけあり、スレッド数 10 ~ 100 は安定して動作しました。
 さらにスレッド数 100超のテストも行いました。 その結果が No.5以降ですが、100 を超過しても同時接続ライセンスがあれば接続を受け付けるしくみになっているようです。
 300 スレッドまでは接続、レコード作成ともに成功しましたが、350を超えるとサーバが高負荷状態となり、接続の失敗が目立つようになっていることがわかります。

マスタマシン 1 台 + ワーカマシン 4 台構成でのテスト

 つづいて FileMaker Server を 5 台構成のテスト展開してテストを実行しました。

【サーバ5台構成のイメージ】
本テストはプレビュー(ETS)版(詳細はTechNet)を使用して行いました

 テスト内容と結果は以下のとおりです。

【表2】
No ワーカ数 スレッド ループ Ramp
(秒)
 
所要時間(秒) 失敗数 1Recの平均作成時間(秒) 備考
50 5 10 1 0.5 4.6 0 0.460 
51 5 20 1 0.5 4.2 0 0.210 
52 5 50 1 0.5 6.2 0 0.124 
53 5 100 1 0.5 13.4 0 0.134 
54 5 100 1 10 11 0 0.110  1回計測
55 5 200 1 未実施
56 5 300 1
57 5 400 1
58 5 500 1 0.5 46 128 0.092  1回計測
59 5 500 1 2 58.5 1.5 0.117  2回計測
60 5 500 1 5 60 0 0.120  1回計測
61 5 500 1 7 49 0 0.098  1回計測
62 5 500 1 10 63 0 0.126  1回計測
63 5 500 1 30 48 0 0.096  1回計測
64 5 500 1 40 48 0 0.096  1回計測
65 5 500 1 7 54 0 0.108 
66 5 600 1 40 59 0 0.098  1回計測
67 5 1000 1 55 98 130 0.098  1回計測
イタリック(斜体)部分は1回または2回のみテストを実施

考察


 以下、今回行ったテストからの考察となります。

高い処理能力

 表1 のテストNo.6 は、1台構成(マスタのみ)環境下で、0.5 秒間に 300 スレッドからクエリを発行し、エラーを出すことなく、23 秒の間に 300 の出庫伝票の作成に成功しています。中規模程度の環境であれば、パフォーマンス的に WebDirect 16 は Webアプリケーション構築の選択肢になると思われます。

適切なワーカマシン数

 表1のテストNo.6 と表2 のテストNo.53 を見てください。他の条件は同じで、ワーカ数が 1 から 5 に増えているにもかかわらず、所要時間はマスタ 1 台の構成のほうが速くなっています。このテストに関しては、おそらくマスタがロードバランスに費やすオーバーヘッドが高いため、ロードバランスを行わない 1 台構成が有利になるものと思われます。

 本テストは短い時間に多くのスレッドから1回のみリクエストを発行するというもので、すべての運用環境に適用できるものではありませんが、単純にワーカマシンを増やせば実行速度が上がるわけではないという可能性を示しています。幸い、ワーカマシンの増設は簡単に行えるので、業務状況やユーザの意見を参考に、ワーカマシンを適時増設していくことも可能と思います。


 ワーカマシンの接続On/Offについて


 ワーカマシンの接続On/Offは、FileMaker Server 16 の Admin Console ページで簡単に行えます。

 下図は、ワーカマシン 2 および 3 の接続を停止したときの様子です。

WebDirect ワーカマシン 2 および 3 の接続を停止したときの様子

  ワーカマシン 2~5 は接続をOn/Offすることのほかに、ゴミ箱アイコンをクリックすることにより、マスタマシンとの接続設定を消去することもできます。
 これに対し、ワーカマシン 1 はマスタサーバ兼用のため、WebDirect ワーカマシンとしての接続停止はできますが、削除はできないようになっています。



短い時間内で大量のクエリが実行された場合のエラー

 上表で赤字の部分は出庫伝票の作成に失敗した件数を示しています。短い時間に多くのクエリが発行されると、エラーが発生しやすくなります。下図は高負荷状態の時に商品画面にアクセスしたのですが、フィールドに < File Missing > が表示されるエラーが発生しました。



 また、サーバが高負荷状態になると、Admin Console が以下のように無応答状態になることがあります。




 さらにアクセスが集中すると、Web サーバ上側でエラー 503 (Service Temporarily Unavailable) が発生し、接続を受け付けなくなることもあります。
 よって、WebDirect の運用を始める前に、最大接続ユーザ数の見積やピーク時の負荷を想定してのテストはやっておくに越したことはありませんね!

ロードバランス

 記事が長くなってまいりましたので、WebDirect 16 のロードバランスについては、別稿を設けたいと思います。



 アプリケーションを高速に開発できる FileMaker。 WebDirect 16 の登場によって Web上の500 ユーザがブラウザから同時接続できるようになりました。 WebDirect は Webアプリケーションの開発において、新たな選択肢を提供する段階に入ったように思います。



 土屋企画では WebDirect の受託開発及び導入支援コンサルティングを請けたまわっております。 WebDirect の導入を検討されているお客様は、こちらよりご相談いただければと思います。



(亀)