ITぶろぐるとるのITぶろぐ日常を楽しんで。「るとるのぶろぐ」のITネタばーじょんです。mod_rewrite設定編3.CSSとJavaScript編3.“Twilioコールフローフレームワーク”編の続きです。コールフローを作ります。Twilioからリクエストされることで、コールフローが起動します。お客様が050番号に電話する。URLが、サーバーアプリ(Runa-CCA)にリクエストされる。Runa-CCAでリクエストを処理する。URL」ですが、Runa-CCAでは新サービス・製品窓口のコールフロー(NewService)をサンプルとして用意していて、「http://ドメイン名/runa-cca/twilio/callflow/newservice/main」になります。mod_rewrite設定の通り、index.phpで処理されることになります。「“Twilioコールフローフレームワーク”編」に書いた通り、index.phpは、Slimのオブジェクトを作って、ルータ(\Runa_CCA\Route.php)に処理を渡す役割を負います。具体的にはindex.phpの中の、\Runa_CCA\Route::registration($app);によって、ルータに処理が渡されます。index.phpでsession_start()とかしているのはWebアプリケーション機能用でして、コールフローのみであれば不要になります。ルータ(\Runa_CCA\Route.php)のregistrationメソッドには以下のように書いてあります。URLに従って、コントローラ(\Runa_CCA\Controller\CallFlow\NewService.php)のstart(“main”)メソッドを呼びます。GETとPOSTの両方に対応するようにしているのはテスト用です。テスト終わったらPOSTで統一するべきだと思います。main以外は別途Twilioからリクエストされるものになります。'POST');コントローラ(\Runa_CCA\Controller\CallFlow\NewService.php)では、まず、Slimのインスタンスを取得し、Requestで送られてきたパラメータを全て取得します。$app->request->params();続いて、RequestがTwilioから来たものなのかどうかを検証します。検証処理については、別記事「Twilioにおける認証(TwilioからのRequestデータ検証)について」に記載の通りです。$params)){Trueが返ってきたら、Switch文で判定して、Modelクラスを呼びます。ここからがコールフローの本体です。コールフローでの処理が終わって、ModelクラスからTwiMLオブジェクト(\Services_Twilio_Twimlオブジェクト)が返ってきたら、それをTwiMLを作るVewクラスに渡します。break;実は、ここのエラー処理には問題ありなのです。Webアプリケーション機能とエラー処理を共有しておりまして、日本語でエラーページを返す仕様にしています。すると、Twilioホームページでログ確認するときに文字化けしてしまうんです。コールフロー用のエラーページを英語で作らないといけません。この点は別記事に書いておきました。TwiMLを作るTwiMLクラスですが、以下のようにTemplateを呼び出し、Twigでレンダリングさせます。%}でエスケープされます。TwiMLを出力させるので、オートエスケープをオンにしてしまうと、TwiMLのタグがすべてエスケープされてしまいます。%}として、エスケープしないようにしています。お客様から電話機で番号入力させて、それをTwilioで読み上げたりするような場合は、エスケープする必要があります。twilio-phpで自動でエスケープしてくれるのですが、\Services_Twilio_Twimlクラスの__callマジックメソッドのコメントを読むと、「経験ない開発者の中にはアンパサンドをエスケープしない人がいる」といった記載がありました。twilio-phpには頼らずエスケープ処理せい、ということなんでしょう。Runa-CCAでは、\Base\Conf内にエスケープするメソッドを用意しておりまして、TwiMLを作成するときにはそのメソッドを実行してエスケープするようにしています。次回はコールフローの中身を見ていく予定です。