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での通話が開始されるまでの問い合わせフローは次のようになります。

上図は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でのチャットが開始されるまでの問い合わせフローは次のようになります。

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

　上図を簡易フローチャートにすると以下のようになります。　

 

　上図を補足解説します。

 

1. 貴社のWeb サイトにチャット開始用のページを用意し、顧客はこのページからチャットを開始します。
   
   
   
   
   　顧客の上図の"Start Chat"をクリックするとチャット用の API Gateway にアクセスが行われ、Lambda 関数によりチャットセッションが開始し、Amazon Connect のチャット応答用問い合わせフローに入ります。
   
   
2. Amazon Connect のオペレーション時間設定を使用し、営業時間をチェックします。時間内であれば次に進み、時間外であれば顧客にテキストでアナウンスを行い、チャットを終了します。
   
   
3. 切断フローとは、エージェント側がチャットを終了したときの処理を定義したフローです。たとえば、チャットのお礼メッセージ、顧客への案内メッセージ、企業プロモーション情報などを送信したり、Amazon Connect の内部処理などを定義したりできます。
   
   
4. 担当エージェントの CCP が呼び出し状態となりますので、✓をクリックするとチャットが開始されます。
   
   
5. チャットが終了すると、上記の 3. の切断フローが実行されます。たとえば、以下のようなメッセージが顧客側に表示されます。
   
   
   

 

　Amazon Connect でシステムを構築するのは上記のようにそれなりの工数が発生しますが、ハードウエアの初期費用が不要で、運用コストも廉価です。また、システム構成もハードウェアを気にすることなく柔軟に変更することが可能です。

 

　コロナ等の感染症や台風・洪水などの自然災害が多発する昨今、オペレータの居場所に拘束されない Amazon Connect の導入は今後増えるものと予想されます。

以上

関連URL

• WebDirect 16 ワーカマシン構成による500+スレッド 同時接続テスト (2017/06/14 投稿）
• WebDirect は 16 で実用段階に近づくか？　― JMeter による WebDirect 14/15/16 比較(2017/05/24 投稿）
• WebDirect関連リンク集
  

FileMaker データベースをSQLスクリプトステップを使用して更新する

　FileMaker は大分以前のバージョンからExecuteSQL関数により、SQLのCRUD（Create、Read、Upudate、Delete）の内、 Read、つまりSELECT 句のみは実行できるようになっています。

　開発者、特に他言語の開発者の中には「なぜ Read はできるのに、Create、Update、Deleteはいつまで経ってもできないのか？」とお腹立ちの向きも多いと思います。　小生もその一人です。

　実は（というほどのことではありませんが）、FileMaker ODBC を使用すると、 「SQLを実行する」スクリプトステップを使用してFMのテーブルを Create(Insert)、Update、Delete することができます。本稿では触れませんが、CRATE/ALTER TABLE といった DDL ― Data Definition Language も一部サポートされていて、テーブルの作成・変更も限定的に実行できます。

　ただ、開発者にとって非常にありがたいこの Create、Update、Delete を活用しているという話は寡聞にして知りません。これは、昔の FileMaker のODBC機能がお粗末で、新しい ODBC を踏み込んで使ってみようと思う人が少ないのが一因かもしれません。小生もその一人です。

　以前、医療レセプト開発のコンサルティング業務を請け賜わったことがあるのですが、数百万行のテーブルがあり、1つのレイアウト上に多数のテーブルからデータを引っ張るといった複雑なシステムで、FileMaker のテーブルオカランスのみではすべての要求情報を1つのレイアウトに表示することはできませんでした。元々はJavaの技術者だったご担当者はいくつもの ExecuteSQL 関数を複数のテーブルに対して実行、結果を変数に格納し、Loopに新レコード作成と値貼り付けを挟み込みむ、といった大変な開発をされていました。この時、上記のような スクリプトステップによるバッチ処理ではなく、INSERT ~ SELECT 等の利用を薦めたのですが、当方においても本手法の採用実績やテストが十分とは言えず、強くは推せませんでした。

　Insert や Update を利用すれば一発でできるところを、ウインドウを開いて、レイアウトを切り替えて、ループして書き込んで、ウインドウを閉じるといった FileMaker 特有の残念な処理を黙々と組み込んでおられたわけです。

SQLを実行するステップによりFileMaker DBを更新するテスト

　ということで今回、FileMaker ODBC、FileMaker Server 18、 FileMaker Pro 18  の「SQLを実行する」スクリプトステップを使用して、いくつかのテストをしてみました。その結果が下表です。

表の0:Script batch は FileMaker の通常のスクリプトステップを複数使用した場合

1:Client SQL は  FileMaker の「SQLを実行する」をクライアントからサーバに対して実行

2:Server SQL は クライアントから「サーバ上のスクリプトを実行」ステップを使用し、サーバ上で「SQLを実行する」ステップを実行

「1:Client SQL」と「2:Server SQL 」では、今回のような単純なSQLクエリにおいては速度の違いはほぼありませんでしたが、サーバサイドでSQLを行う場合、サーバだけに ODBC を設定しておけば、クライアント上にODBCをインストール・設定する必要が無いのはメリットです。 

1列目は実行したテスト内容で、以下で解説します。

	0:Script batch	1:Client SQL	2:Server SQL
1. Update 1 field of 10K records	7.2sec	3.0sec	2.8sec
2. Update 5 fields of 10K records	33.0sec	3.2sec	2.9sec
3. Simple import of 10K records	11.3sec	6.2sec	6.1sec

※各テストはそれぞれ5回ずつ実行し、所要時間を平均値を載せています。

1万件のレコードの1フィールドを更新

上表の「1.Update 1 field of 10K records」では、1万レコードの1フィールドを更新しています。SQLで記述すると以下になります。

update product set "note1" = 'client sql'

これをFileMaker のスクリプトでやる場合、product テーブルが設定してあるレイアウトを開き、すべてのレコードを選択して、 note1フィールドを選択後に、「client sql」で全置換するというように、複数のステップが必要になります。全置換を使用しない場合、フィールド値設定ステップを Loop させることになりますが、これは置換ステップよりも時間を要します。

　結果的にはSQLを使用した方が2倍以上高速でした。

1万件のレコードの5つのフィールドを更新

　「2.Update 5 fields of 10k records」では1万レコードの5つのフィールドを更新しています。SQLで記述すると以下になります。

update product set note1 = 'sql 10',  note2 = 'sql 20',  note3 = 'sql 30',  note4 = 'sql 40',  note5 = 'sql 50'

「0:Script batch」 では、置換ステップを5回実行しています。結果はSQLを使用した方が5倍高速でした。

1万件のレコードを別テーブルにインポート

　「3.Simple import of 10K records」では1万件のレコードを別テーブルにインポートしています。SQLで記述すると以下になります。

insert into invoice (prodId, prodName, price, unit, note) select ID, name, salesPrice, unit, note1 from product

「0:Script batch」のコアとなるステップは「レコードをインポートする」だけですが、このような単純な処理であっても、SQLの方が2倍弱高速でした。

過去のテスト

　小社では以前、いくつかの FileMaker 用 Web API を使用し、CRUDのテストを行っており（下記リンク参照）、その際も Create、Update、Delete については ODBC（PDO）が良い（＝高速である）結果を得ています。

参考：FileMaker API別にCRUDのテストをしてみた（2016/12/01）
　今回、ODBCとSQLを実行スクリプトステップを使用しても、3年前と同様に良い結果が得られました。

SELECT ～ FOR UPDATE について

　SELECT ～ FOR UPDATE は直接データベースを更新する構文ではありませんが、更新の前処理として重要な意味があるので、ここで触れておきたいと思います。
　FileMaker®16 SQL リファレンスガイドによると、FileMaker ODBC/SQL は「FOR UPDATE 句 」をサポートしており、select ～  where ～ for update を実行すれば、where で指定された「各レコードは取得時にロックされ」る筈ですが、「SQLを実行する」ステップでは以下のようなSQLを実行しても、他ユーザは where 句で指定されたレコードを更新できてしまいます（つまりロックされない）。

select * from product where ID =1 for update [of note1, note2]

　もともと「SQLを実行する」ステップで select を実行しても、文字列などの結果が返りません。サーバのログを見ても、実行直後に接続が切れています。ということで「SQLを実行する」ステップは  select ～ for update （レコードロック） をサポートしていないようです。

　ただ、他ユーザがあるレコードを編集している際に、 当該レコードが対象となる select ～ for update 実行すると「[FileMaker][FileMaker] (301): Record is locked by another user.」が返ります。　つまり、FOR UPDATE句により、ユーザは WHERE句 で指定するレコードセット中に編集中のモノがあるかどうかを事前に知ることだけはできます。

参考：https://wiki.myfmbutler.com/index.php?title=DoSQL_3#more_optional_parameters

　ちなみに、ExecuteSQL関数 はこの FOR UPDATE をサポートしていません。

更新時の他ユーザ競合エラー

　複数レコードのフィールド値を更新する場合、他ユーザが更新対象のレコードを編集しているとエラーとなります。ただし、フィールド内容を置換スクリプトステップ と SQL の UPDATE ではその内容が異なります。

　フィールド内容を置換ステップでは、置換対象のレコードを他のユーザが編集していると、そのレコードを除くロックされていない全レコードが置換され、FileMaker標準エラーの201（フィールドを変更できません）が返ります。置換ステップの欠点はエラーが起こったレコードが特定できないことで、これは場合によっては致命的です。このため、エラーを放置できない場合は置換ステップに替えて、処理に時間がかかりますが、Loop により各レコードを逐一更新し、エラーを起こしたレコードの主キーを記録して、ユーザに通知するか、エラーを解消するための処理を別途用意することになります。

　これに対し、FileMaker SQL の UPDATE は、1レコードでもロックが発生していると WHERE句で指定されたすべてのレコードが更新されません。あたかもエラーが発生して ROLLBACKされたようにみえます。このときFileMakerは1408（拡張エラー (ODBC)、Get(最終外部エラー詳細)関数は「[FileMaker][FileMaker] (301): Record is locked by another user.」を返します。

　FOR UPDATE句によりレコードセットをロックできれば、更新時の他ユーザ競合によるエラーの懸念も減少すると思うのですが、前述のような状況なのが残念です。

　FileMaker の開発案件もマルチユーザ対応が要件であることが多いと思います。マルチユーザ対応であれば、競合発生時のエラー処理は必須です。この辺の地味な処理の重要性を発注サイドにも認識して頂き、工数を見込んで頂くと共に、検収時のチェックリストにいれましょう。

SQL実行ステップにより更新を行うメリットと課題

SQLによる更新を行うメリットをまとめると以下のようになります。

1. 高速化
2. スクリプトの簡略化、可読性向上
3. 他言語からの移行組技術者は使い慣れたSQLにより開発ができる
4. アクティブレイアウトとは無関係にコマンドを実行できる

　今回は単純な処理のみでテストを行っていますが、多数行に及ぶ複雑な更新・バッチ処理を行う場合、SQLを使用する速度的メリットはさらに大きいと思います。

　FileMaker は過度にレイアウト依存したシステムであるため、上記4のメリットも大きいと思います。スクリプトはレイアウトからフィールドが消去されるとエラーを起こす可能性がありますが、SQLであればその心配はありません。

スクリプトで複数レコード、複数テーブルに及ぶ処理を実装すると、いちいちテーブルが割り当ててあるレイアウトに移動し、LOOPでグルグル回しながらレコードを作成したり、更新したりするのはコーディング的にも残念ですし、画面がチラチラ無駄に切り替わるのはユーザから見ても美しくありません。

課題

　FileMaker社はWebサイトでアクセス方法別の許容ユーザ数を公開しており、ODBC/JDBC接続の最大許容値（理論値）は無制限、検証値は50（ユーザ）となっています。
今後は100～500ユーザ位を想定し、負荷が高い処理でも確実に実行されるか、テストを行いたいと思います。

以上


NuckyT