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

2023-07-06

FileMaker Server をアップデートするとやっぱ WebDirect が使用不能になった

 みなさんは運用中のサーバソフトウェアをどのタイミングでアップグレードしていますか? 当社では運用中のサーバに関するアップグレードがリリースされた場合、リリースノートを読み、重要なバグフィクスやセキュリティパッチが含まれるかどうかを確認し、これらに該当しない場合は直ぐにはアップグレードを行いません。 例えば、FileMaker Server で機能的なアップグレード(新しい機能追加や既存機能の改善のみ)があった場合は、リリースから数ヶ月経過するかマイナーバージョンが上がるまではそのアップグレードは行いません。これは、新しいアップグレードが含むかも知れない新たなバグを回避するためです(人柱が現れるのを待つ、とも言う)。

 さて今回、当社で運用中の FileMaker Server 19のアップグレードを行ったのですが、悪い経験は繰り返す則(マーフィーの法則)に従い、WebDirect が使用不能になりました。 そこで本稿ではこの経緯と対応方法をまとめました。 


対象読者


FileMaker Server(FMS) 19.x 環境で WebDirect を使用していたが、FMS をアップグレードしたら WebDirect が動作しなくなった方
 

WebDirect が動作しなくなった経緯

先日、FileMaker Server 19.0.1 を 19.6.3 にアップグレードしたところ、今まで動作していた WebDirect ページが開けなくなりました。以下のような HTTP エラー502.3 が出ます。

FileMaker Server Admin コンソールも、プライマリマシンがいつの間にか無効化された状態となっています。このまま有効化してもすぐに無効に戻ってしまいます。

 

アップグレードした途端に WebDirect が動かなくなるなら Java との互換性を疑え、ということで Claris 公式サイトを検索したところ、FileMaker Server 19.2~19.6 は Java 11 が推奨されているという表記をみつけました。

macOS および Windows 上で Web 公開を使用する場合の、JAVA_HOME 環境変数の活用について [Claris 公式サイト]


もともと使用していた Java が OpenJDK 8.0_252 だったため、上記ページを参考に OpenJDK 11 に入れ替えたところ WebDirect が復活しました。

作業内容

以下では Windows Server を使用した復旧方法を記します。
作業につきましては自己責任でお願いいたします。

  1. Windows サービスより FileMaker Server を停止させます。
  2. OpenJDK をダウンロードします。
    https://adoptium.net/temurin/releases/?version=11
    当方の場合は、msi インストーラーを選択しました。
     
     
  3. OpenJDK 11 をインストールします。いくつかオプション指定がありますが、デフォルトのままでOKです。
  4. OpenJDK 11 のインストールが終わったら、環境変数を手動で変更します。
    Windows Server のコントロールパネルを開き、システムとセキュリティ→システム→システムの詳細設定の順に選択します。
    システムのプロパティより、“環境変数”ボタンをクリックします。

     
  5. 環境変数の一覧から、JAVA_HOME 環境変数を特定し、設定値を新しい OpenJDK のインストールパスに変更します。
    たとえば以下のようになります。

    (変更前)



    (変更後)


  6. FileMaker Server 20.1 以降は Java ガベージコレクション用の PATH 指定が必要になるとのことで、併せて設定を行います。
    既存の Path システム環境変数に、%JAVA_HOME%\bin を追加します。たとえば以下のようになります。



  7.  つぎに、古い Javaのインストールフォルダを削除します。Program Files\FileMaker\FileMaker Server\Web Publishing\java あたりを探してみてください。
  8. Windows サービスより、FileMaker Server を起動します。起動後、FileMaker Server Admin コンソールの「コネクタ」タブより、プライマリマシンを有効にします。
  9. 以下のように、プライマリマシンが実行中になれば作業は終了です。

その他の WebDirect 情報については、以下のリンクをご参照ください。

FileMaker Server 18.0.2 以降での Java の変更
FileMaker Server と Java - 概要
Claris FileMaker WebDirect ガイド


(亀)


追記:
WebDirect、予想以上に情報少ないですね。導入しているところ、あるんでしょうか...


2020-06-01

TPC FM-AConnect CTI ― Amazon Connect と FileMaker WebDirect 19 による CTI

TPC FM-AConnect CTI について

 
 本稿では、Amazon Connect と FileMaker WebDirect 19 を連携させた CTI(Computer Telephony Integration)プロトタイプ・TPC FM-AConnect CTI の仕組みと機能をご紹介します。

 Amazon Connect は、AWS上で構築するクラウドベースの PBX/コールセンターシステムです。レガシーPBXを使用したコールセンターシステムに比べ、初期費用に抑えてシステムを構築できます。
 これによりオフィス内のスタッフはもちろん、テレワーカー(在宅勤務者)でもCTIを利用できるようになります。

TPC FM-AConnect CTIの主要機能

  1. FileMaker WebDirect 19のアプリ(FM-AConnect WD)を使用した着信時顧客情報ポップアップ(着信した電話番号により顧客データベースを検索し、その顧客情報をオペレータのPC画面に表示する機能)

  2. FileMaker DB に登録された電話番号とオペレータIDに基づく、オペレータへの配信(着信番号別オペレータ割当、例えば顧客DBで顧客AとAを担当するオペレータXが紐付けて登録されている場合、Aの電話番号を着信するとXに転送する

  3. チャット ― テキストによるチャット

  4. 通話記録 ― 音声通話を記録・再生する機能

 WebDirect とは FileMaker で作成したアプリをそのままWeb公開する機能です。FileMaker のデスクトップアプリと高い互換性を有しており、そのほとんどの動作をWebブラウザ上で再現可能です。また、バックエンドとなるデータベースには FileMaker に限らず、ODBC経由で Oracle、MySQL、SQL Server、DB2*1、PostgreSQL*1 を使用することができ、他の開発ツールに比べ短い時間で CTI のフロントエンドを開発することが可能です*2

 Amazon Connect の電話端末となるソフトフォン・CCP もブラウザで動作する Webアプリであるため、WebDirect との親和性、JavaScript による相互の制御性は高いといえます。

注:
*1 DB2、PostgreSQL を使用するには、Actual社の ESSアダプタが必要。
*2 WebDirect については、当社の過去のBlog記事(一覧)をご覧ください。

仕組みと Amazon Connect の問い合わせフローについて


 以下が TPC FM-AConnect CTI のシステム構成図となります。
図でCCP (Contact Control Panel)とあるのが Amazon が提供するソフトフォンで、Windows/Mac の Firefox あるいは Chrome 上で動作します。残念ながら、スマホやタブレット、SIPフォンには対応していません。

 顧客からの電話が入ると、まず Amazon Connect が1つ目のCCPに電話を転送し、転送先の CCP はPCのスピーカーから呼び出し音を発生させます。
 

 上記の処理の流れは Amazon Connect の問い合わせフローによって制御されます。
問い合わせフローとは、問い合わせの一連の処理の流れをシナリオ化したものです。
TPC FM-AConnect CTI には、以下の 3 つの主要問い合わせフローによって構成されています。

メインフロー


 窓口となる Amazon Connect の問い合わせフローです。顧客からの着信が音声通話要求なのか、チャット要求なのかによって各サブフローを呼び出します。

 上記の流れを簡易フローチャート化すると、以下のようになります。

サブフロー:音声通話応答用問い合わせフロー

 メインフローにより、音声通話要求と判断された場合に実行される Amazon Connect の問い合わせフローです。通話着信があってからCCPでの通話が開始されるまでの問い合わせフローは次のようになります。
TPC Call Automatic Response フロー
上図は1画面に表示するため、エラー時のフロー転送とハングアップを増やしてます

 
 上図を簡易フローチャートにすると以下のようになります。 
 このとき FM-AConnect WD は着信した電話番号を取得し、その番号によりデータベースを検索し、顧客情報をポップアップ表示します。

 上図を補足解説します。

  1. ログ収集開始では、Amazon Kinesis Stream というデータストリームを有効にし、通話開始時のタイムスタンプを取得します。このタイムスタンプは、Amazon S3 に保存される通話記録ファイル(後述)名をデータベースに保存するために必要となります。なお、Transcribe(AWSの音声→テキスト変換モジュール)を利用する場合も、この Kinesis が必要となります。

  2. Amazon Connect のオペレーション時間設定を使用し、会社の営業時間を設定します。営業時間内であれば次に進み、時間外であれば顧客にその旨を告げる音声アナウンスを行い、通話を終了します。

  3. AWS の Lambda 関数に定義されている FileMaker Data API により、着信電話番号に該当する顧客担当者(担当エージェント)を検索し、通話要求を担当者の CCP に転送を試みます。以下は、転送時の分岐処理。

    • 顧客担当者検出 --- その担当者に通話要求を送信
    • 顧客担当者を検出したが不在 --- 通話可能な担当者に通話要求を送信
    • 顧客担当者未検出(DBに登録無) --- 通話可能な担当者に通話要求を送信
    • 顧客担当者不在 --- 未達メッセージを自動音声アナウンス → 通話終了

  4. AWS の Lambda 関数を使用し、受信した電話番号をJSON形式でWebクライアント(ここでは FM-AConnect WD)に渡します。FileMakerのファイルには「電話番号による顧客検索スクリプト」を用意し、電話番号は引数で渡せるようにしてあります。
    Webサーバ上に配置するHTMLページには 上記のCCP を埋め込んでおき、Lambda が生成したJSON形式の電話番号を取得し、Webビューアに設定してある FileMaker.PerformScript (電話番号で顧客検索スクリプト,  電話番号) を実行します。

    この FileMaker.PerformScript( ) は FileMaker 19 で導入された新機能で、Webビューア内の JavaScript から FileMaker のスクリプトを実行できます。これにより、CCPに着信があると、FileMaker WebDirect のアプリで顧客情報が検索されるようになります。

    CCP(右)に着信すると、WebDirect(左)は自動的に電話番号で顧客を検索・表示する

  5. 担当者の CCP まで通話要求が転送されると、CCP が呼び出し状態となり、✓ボタンをクリックすると通話が開始されます。
 以下の動画では、上記のフローに基づき実装したCTIの着信時顧客情報ポップアップ機能をご覧いただけます。

 

通話記録再生機能について

 通話記録は音声ファイルとして AWS S3 サーバに保存されます。通話記録ファイルは FileMaker WebDirect アプリケーションの「交信履歴」タブのリストから再生することができます。 
 

サブフロー:チャット応答用問い合わせフロー

  TPC FM-AConnect CTI にはチャット機能も用意されています。チャット機能のシステム構成図は以下のようになります。

 メインフローにより、チャット要求と判断された場合に実行される Amazon Connect の問い合わせフローです。チャット要求があってから CCPでのチャットが開始されるまでの問い合わせフローは次のようになります。

Amazon Connect TPC Chat Flow
上図は1画面に表示するため、エラー時のフロー転送とハングアップを増やしている

 上図を簡易フローチャートにすると以下のようになります。 
 
 上図を補足解説します。
 
  1. 貴社のWeb サイトにチャット開始用のページを用意し、顧客はこのページからチャットを開始します。


     顧客の上図の"Start Chat"をクリックするとチャット用の API Gateway にアクセスが行われ、Lambda 関数によりチャットセッションが開始し、Amazon Connect のチャット応答用問い合わせフローに入ります。

  2. Amazon Connect のオペレーション時間設定を使用し、営業時間をチェックします。時間内であれば次に進み、時間外であれば顧客にテキストでアナウンスを行い、チャットを終了します。

  3. 切断フローとは、エージェント側がチャットを終了したときの処理を定義したフローです。たとえば、チャットのお礼メッセージ、顧客への案内メッセージ、企業プロモーション情報などを送信したり、Amazon Connect の内部処理などを定義したりできます。

  4. 担当エージェントの CCP が呼び出し状態となりますので、✓をクリックするとチャットが開始されます。
  5. チャットが終了すると、上記の 3. の切断フローが実行されます。たとえば、以下のようなメッセージが顧客側に表示されます。

 
 Amazon Connect でシステムを構築するのは上記のようにそれなりの工数が発生しますが、ハードウエアの初期費用が不要で、運用コストも廉価です。また、システム構成もハードウェアを気にすることなく柔軟に変更することが可能です。
 
 コロナ等の感染症や台風・洪水などの自然災害が多発する昨今、オペレータの居場所に拘束されない Amazon Connect の導入は今後増えるものと予想されます。

以上

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



 

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 の導入を検討されているお客様は、こちらよりご相談いただければと思います。



(亀)