多くのビジネスプロセスで、何らかの方法で、1つの電話番号に電話をかけてから別の番号に接続するなどの問題があることは驚くことではありません。 ほとんどの場合、そのようなサービスはコールバックまたはコールバックと呼ばれ、時にはコールオーダーと呼ばれます。 多くはオンラインストアのサイトで彼に会いましたが、ほとんどの場合、これは自動化されたコールバックではなく、メールでマネージャーに届くか、CRMに表示される通常のアプリケーションです。その後、マネージャーはクライアントの番号をダイヤルして彼に話します。 一部の大企業では、自動化されたコールバックを実装し、さらにコンタクトセンターのキューと統合しています。 この投稿では、VoxImplantプラットフォームを使用して、数分でコールバックスクリプトを文字通り作成する方法と、通話データを保存/受信するための既存のバックエンドとこのエコノミーを統合し、ポップコーンの在庫を増やして猫を歓迎する方法を見ていきます。
最初に、コールバックサービスを実装するときにスキームがどのように、どのように、どのように相互作用するかを簡単に説明できるように、スキームをより大きなサイズで複製します。
少し面倒に見えますが、実際にはすべてが非常にシンプルで便利です。 VoxImplant開発者（
サイトに登録する必要がある開発者アカウントを取得するには、完全に無料です）はHTTP APIを介してVoxImplantクラウドにリクエストを送信します。その後、スクリプトサーバーはJSで記述されたスクリプトを開始しますビジネスロジック。 スクリプトを実行するためのHTTPリクエストを行う前に、明らかに、それを記述し、ルールを介してアプリケーションにアタッチする必要があります。このルールのIDは、どのスクリプトを実行する必要があるかが明確になるようにHTTPリクエストで指定する必要があります だから、順番に：
- VoxImplantアプリケーションを作成します。
- スクリプトを作成します。
- ルールを使用して、スクリプトをアプリケーションにバインドします。
- スクリプトを実行するHTTPリクエストを作成します。
スクリプトを実行するためにHTTPリクエストを行った後、すべてが正しく行われた場合、レスポンスはmedia_session_access_urlになります。これにより、スクリプトの実行後、その作業のリモート制御を継続できます。 たとえば、特定の瞬間にスクリプトを終了する場合は、スクリプトに次のように記述できます。
VoxEngine.addEventListener(AppEvents.HttpRequest, handleHttpRequest); function handleHttpRequest(e) { VoxEngine.terminate(); }
この場合、media_session_access_urlをリクエストすると、スクリプトが停止します。 電話番号へのコールバックの実装に戻ります。 コントロールパネルの[
アプリケーション]セクションでアプリケーションを作成し、それをcornyコールバックと呼び（最終的にはフルネームはcallback.account_name.voximplant.comになります）、[
シナリオ]セクションで次の形式の新しいスクリプトを作成します。
var call1, call2, data; const callerId = "+1234567890";
つまり、このスクリプトは、特殊な要求パラメーター
StartScenarios script_custom_dataをストリングnumber1：number2の形式で渡す番号を呼び出します。 まず、番号1をダイヤルし、TTSを使用してメッセージを再生し、次に番号2をダイヤルして、2つのコールを相互に接続します。 このシナリオでは、何らかの方法でケースを解決しません。たとえば、番号1に到達しなかった場合、スクリプトを完了するだけです。 ちょっとした魔法なら、何かがうまくいかなかったことを外の世界に知らせることができます。
call1.addEventListener(CallEvents.Failed, function(e) { VoxEngine.terminate(); });
に
call1.addEventListener(CallEvents.Failed, handleCall1Failed);
そして、handleCall1Failedを説明します：
function handleCall1Failed(e) {
これは、GET要求を使用した最も簡単な例です。
HttpRequestOptionsクラスを使用して、スクリプトの側からHTTP要求を構成および管理できます。
同様に、Dateを使用して、スクリプト内の個々の呼び出しまたはセッションの継続時間を測定し、何らかの理由でこの情報を取得するために呼び出し履歴に移動すると、この情報がサービス/アプリケーションのロジックと一致しない場合、データを外部に送信できます。 おそらく既に理解しているように、開発者が特定の問題を自分で解決するためのメカニズムを選択できるように、非常に柔軟なシステムを作成しようとしました。
スクリプトの準備ができたら、たとえばCallbackHabrなどの名前でスクリプトを保存し、アプリケーションセクションに移動して、スクリプトをルールにフックし、最終的にそのIDを取得する必要があります。
ルールIDを取得するには、少しプレイする必要があります（将来、コントロールパネルのこの欠点を排除しようとします）-ルールを作成した後、アプリケーション（ルールの順序ではなく、アプリケーション）を保存する必要があります。つまり、（全般）タブに移動して、（保存）をクリックします 次に、編集のためにアプリケーションを再び開き、ルールIDが表示される[ルール]タブを開きます（HTTP APIからも取得できます）。
これですべてです。StartScenariosにHTTPリクエストを送信できるようになりました。これにはいくつかのパラメーターが必要になります。プロファイルセクションでapi_keyを見つけることができます。 リクエストは次のようになります。
https:
成功の結果として、精神の何かが戻ってきます：
{ "result" : 1, "media_session_access_url" : "http:\/\/1.2.3.4:12092\/request?id=93e41c6e20811b9b.1380201554.0@1.2.3.4&token=36bc7ce95edc679e32d83bb6f3ad985f" }
このmedia_session_access_urlを通じて、必要に応じてセッションとの通信を継続できます。 スクリプトをデバッグするために、ログは常に利用可能です。ログは、
呼び出しセクション（右上隅の矢印）にあり
ます 。また、
ここから入手できるUberdebagerもあり
ます 。 便宜上、GitHubのこの投稿からスクリプトをアップロードしたので、すぐに実験できます。
GitHubコールバックスクリプト