人間の顔をしたSkypeボット（Microsoft Bot Framework V3およびSlack API上）

Skypeは、顧客との効率的なコミュニケーションのための優れたチャンネルです。 誰もがそれを持ち、不必要なジェスチャーや費用なしで迅速なライブ通信を提供します（たとえば、電話通信）。 ただし、顧客の数が数千人に達すると、Skypeの利点は欠点に変わり始めます。 この記事では、Skypeボットについて説明します。Skypeボットは、20世紀初頭に電話オペレーターの役割を本質的に果たします。クライアントを無料のマネージャーに接続し、問題が解決するまでこの接続を維持します。



Skyeng Schoolは、メッセンジャーとユーザーサポートオペレーターの間に便利なコミュニケーションチャネルを作成するという課題に常に直面しています。 現在、最も多くのアプリケーションを受け入れているメッセンジャーはSkypeです。 Skypeの連絡先の数が数千にのぼると、Skypeクライアントを介した直接の通信に問題が生じます。 まず、このような作業中のこのクライアントのパフォーマンスはほぼゼロに低下し、連絡先リストは非常に長くロードされます。 第二に、多くの場合、複数のオペレーターがユーザーと並列通信を行う必要があります。 複数のデバイスで1つのSkypeアカウントを使用することは可能ですが、すべてのダイアログからの着信メッセージはすべてのオペレーターに表示されるため、作業が妨げられます。 さらに、Skypeでのすべての通信はSkype自体に残り、コピーアンドペーストを処理する必要のある内部CRMまたはHelpDeskシステムにそれらを抽出します。



これらの問題により、サポートサービスへのメッセージのエントリポイントとして機能するチャットボットを作成することになりました 。 チャットボットのテーマは最近非常に人気があり、MicrosoftはSkype REST APIへのアクセスを提供しました。SkypeREST APIには、C＃およびNode.jsのサンプルを含むSDKが付属しています 。



完全なマルチチャネル通信では、メッセージを受信するだけでは十分ではなく、オペレーターがメッセージを読み取れる場所に配信する必要もあります。 私たちの学校は内部コミュニケーションでSlackを積極的に使用しており、このメッセンジャーはチャネルの概念を十分にサポートしているため、着信メッセージをそこに転送することにしました。



その結果、エントリポイントと出口ポイントを備えたモデルを作成し、その内部でデータフローを完全に制御できます。

建築

システムはサーバー上の複雑な計算を意味しません。 その主なタスクは、データの受信、保存、ルーティングです。 そのため、このようなタスクに適したNode.jsがメインプラットフォームとして選択されました。 彼らは、プロジェクトの開始時に利用可能な最新のLTSバージョンである6.3.0を使用しました。 node.greenによると、 6つはES 2015の95％をカバーしており、これは非常に素晴らしいことです。また、 nodesourceブログは 2018年4月まで機能を約束し、その後メンテナンスフェーズが開始されます。 良い。







データベースには特別な要件はないため、 PostgreSQLの形式で古典的な信頼できるリレーショナルを使用しました。



十分に高いフォールトトレランス、スケーラビリティ、および低いコンポーネント接続性を確保するために、システムモジュール間のデータ交換のためにRabbitMQの形式でアーキテクチャメッセージキューに含めることが決定されました。



その結果、次の作業スキームが得られました。







このシステムは、 3つの主要なサービス （Skypeサービス、Logicサービス、Slackサービス）と追加のマイクロサービスSlackメッセージングマイクロサービスで構成されています。 Slackサービスの主な目的は、エンドポイントがSkypeボットに対して機能し、メッセージをSkypeに送信することを保証することです。 ロジックサービスは、メッセージのルーティング、メッセージの保存、コマンドの処理、学校の内部サービスとの統合のためのAPIの提供を担当します。 SlackサービスにはSlack RTMへのサブスクリプションがあり、 Slackのサポートオペレーターからのコマンドを受け入れるエンドポイントを担当します。



Slack APIの制限を超える恐れなく、メッセージを自信を持ってSlackに送信するには、追加のSlackメッセージングマイクロサービスが必要でした。そのため、メッセージは、RabbitMQからタイマーで長時間ポーリングして送信し、Slackに送信します。

プレビューを信頼できますか？ Microsoft Bot Frameworkへの移行

ツールのプレビューバージョンの使用には、常に特定のリスクが伴います。これは、リリース時に重大な変更が発生する可能性があり、さらに悪いことに、このリリースがまったく行われないためです。 これはまさに、Skypeボットを開発するためのSDKにまつわる運命です。プレビューフォームに登場し、同じフォームで古くなった（非推奨のステータスを受け取りました）。 その後、Skype専用の新しいボットの作成が不可能になり、Microsoft Bot Frameworkへのリダイレクトと、近い将来に移行する必要性に関する警告が表示されました。











Microsoft Bot Frameworkは、1つのツールで多くの通信チャネルをカバーするためのMicrosoftの試みです。 現在サポートされているのは：Facebook Messenger、Kik、Slack、Telegram、Skype、さらには電子メール、Twilio（SMS）、Direct Lineなどのチャネルです。 これはすべて興味深いことですが、この段階ではSkypeにのみ興味がありました（もちろん、良いスタートでしたが、後の手間を省いて他のインスタントメッセンジャーのサポートを追加できます）。







待たずにすぐに移行しました。 Microsoft Bot Frameworkに新しいボットを登録するのは簡単で、Microsoftアカウントを持っているだけです。



アルゴリズムは次のとおりです。

• リンクをたどってください 。
• すべてのフィールドにアスタリスクを入力します。
• [MicrosoftアプリIDとパスワードの作成]をクリックします。
• 新しいページが開きます。このページで、アプリケーションの名前（TestBotAppなど）を入力する必要があります。
• さらにボタンパスワードを生成して続行します。
• 生成されたパスワードは再表示できないため、どこかに保存する必要がありますが、フレームワークとアプリIDを操作するために必要です。
• 次に、[完了してボットフレームワークに戻る]ボタンをクリックします。
• 登録ページで契約に同意して[登録]をクリックする必要があります。その後、Microsoft Bot Framework用の既製の登録済みボットがあります。

登録ページにはメッセージングエンドポイントフィールドがあり、登録には必要ありませんが、ボットのエントリポイントであり、ボットなしでは機能しません。 エンドポイントの主な要件は、機能するHTTPSリンクでなければなりません。



コードの移行に関しては、ボットができるのはメッセージの送受信だけなので、大きな変更を加える必要はありませんでした。 それでも、同じ機能のコードは大きくなりました。

bot.send( '8:skype.username', 'message from bot to user', true, // escape (error) => console.log(error) );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

になった

 bot.send( new builder.Message() .address({ channelId: "skype", user: { id: "29:some-long-hash-here", name: "User Display Name" }, bot: { id: "28:bot-uuid", name: "Bot Name" }, serviceUrl: "https://skype.botframework.com", useAuth: true }) .text('Message from bot to user'), (err) => console.log(err) );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、メッセージ受信の小さな変化：

 bot.on('personalMessage', (bot, data) => { console.log('Got message from user'); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ボットフレームワークにはダイアログなどの概念がありますが、メッセージを受信するだけでよいので、スラッシュで表される最も一般的なダイアログにサブスクライブしました。 すべての着信メッセージを受け入れます：

 bot.dialog("/", [ (session) => { console.log("Got message from bot", session.message); } ]);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記のボットスニペットでは、Skypeの場合、Bot SDKはBotServiceクラスのインスタンスであり、Bot FrameworkではすでにUniversalBotです。



また、Skype Bot SDKでユーザーIDを使って誰を扱っているかを大まかに理解できるようにしたい場合、Microsoft Bot Frameworkではすべてのユーザーが長いハッシュの形式で表示され、対話者が匿名になります。 アイデンティティを決定するタスクは、ユーザーとのライブの対話でのみ解決できます。



もう1つの興味深い点は、ボットから送信されたメッセージを編集することです。 一部のgithubユーザーが言うように、Skype Bot SDKにはそのような機会がありましたが、Microsoft Bot FrameworkにはSkype用ではありません（他のプラットフォーム、特にTelegramとSlackでは可能ですが）。



それにもかかわらず、Microsoft Bot Frameworkは、さまざまな通信チャネルのボット開発プラットフォームの統合に向けた良い一歩です。 Microsoftがこの製品の開発を継続し、不足している機能をSkypeボットに今すぐ追加することが望まれます。

Slackでメッセージに会います

マルチチャネルのメッセージ受信を整理するために、プライベートチャネルなどのSlackツールを使用しました。 Slack APIの用語では、これらはグループです。



最初は、メッセージをSlackに送信するすべての機能をカバーするカスタムボットを1つ作成するだけで十分であると期待していました。そこでプライベートチャネルを作成し、そこにオペレーターを追加して、プロキシ通信を提供し続けます。 ただし、Slackのボットはプライベートチャネルの作成を許可されていませんでした。



したがって、 Slack RTMに接続されたApiカスタムボットに加えて、通常のSlackユーザーに代わってプライベートチャネルを作成し、オペレーターを招待するSlackアプリケーションも作成しました。



Slack APIは非常に安定しており、十分に文書化されており、メソッド呼び出しを確認できるオンラインテスターも含まれているため、幸いなことに他に驚きはありませんでした。 それを使用するために、この非常に単純なnpmパッケージを使用しました 。これは、そのメソッドのほとんどが同じ名前のSlack APIメソッドを繰り返すため、便利です。

それほど単純ではありません！

ボットが機能するためには、Microsoftによって承認される必要があります。 単純な形式のように見えますが、多くの時間と労力がかかりました。 私たちが踏み込んだレーキについて説明しますが、これはあなたが他の人を踏まないという意味ではありません。 それの準備をしなさい。



したがって、最初の送信から2週間後、次のようになりました。







説明：ボットのコンテンツはロシア語です。 現時点では、Skypeボットは英語ユーザーのみをサポートしています。 ユーザーが英語でボットを読んで使用するための翻訳または代替オプションを提供してください（「ボットはロシア語ですが、ユーザーは英語で通信できる必要があります」）。 結局のところ、この問題を解決するには、英語の利用規約とプライバシーポリシーがあれば十分です。 OK、書き込み、 投稿 、新しいアプリケーションを送信しました。



今回はたわごとが速くなりました：









ボットは、クライアントとオペレーターを接続することのみを目的としています。 Microsoftによると、これでは十分ではありません。 ボットが独立して応答できるいくつかのコマンド（helpとlessons-count）を最小限の機能に留める必要がありました。



これらの要件を満たしている間に、新しいことが登場しました。ボットは、利用規約とプライバシーポリシーをコマンドで発行できる必要があります（サイト上にそれらを置くだけでは不十分です）。 さて、それもやった。 これでは十分ではないことが判明しました。各メッセージに条件が存在する必要があります。 いいね 一方、マイクロソフトのロンドンオフィスでは、大規模な改造が始まりました。そのため、承認が何度も何度も延期されました。



しかし、最終的に、待望のupruを得ました。







これらの不正行為はすべて、私たちから膨大な時間を要し、予期せぬ、時には説明できない遅延に備えてください。

おわりに

その結果、着信メッセージに対して高速で高品質の応答を提供し、「生きているかのように」クライアントと会話するSkypeボットを取得しました（オペレーターが制御していることを考えると、これは驚くことではありません）。 間違ったチャンネルへの回答や着信した連絡先を見逃したことは過去のものです。 「あなたの質問は私たちにとって非常に重要です」-空の言葉ではなく、今では単一のメッセージが失われることはなく、会話が私たちのせいで衰退することはありません。 同時に、通常のSkypeの問題は解決され、通信は構造化された形式になり、社内のユーザーサポートサービスに統合されました。 そして、すべての「魔法」は、異なるプラットフォーム間でメッセージをルーティングする単純なアーキテクチャにあります。



PS私たちのドアは様々な才能あるスペシャリストに開かれていることを思い出させてください！