なぜチャットボット、またはBitrix24のストーリーが必要なのか

ファン用のボットを作成してチャットする場合を除き、Microsoft Bot Frameworkを使用できる理由と、自然界のプロジェクトでチャットボットを使用する実際のケースがあるかどうかがよく聞かれます。 だから、彼らは存在します。 パートナーの1つであるBitrix24に、ボットをプロジェクトに統合した経験と技術的な詳細を共有するように依頼しました。 システムの開発者であるSergey Pokoevに話を聞きます。SergeyPokoevは、そのアーキテクチャと、Skypeに接続するためのBot Frameworkの使用について説明します。

背景

会社と顧客とのコミュニケーションは長い間変化してきました。電子メールや電話に置き換わり、最初にソーシャルネットワーク、次にメッセンジャーが登場しました。 同意して、今でははるかに便利になりました。そして最も重要なことは、Facebook、VKontakte、What's App、またはTelegramでサポートの質問をより速く尋ねることです。



豊富なチャンネルは素晴らしい機会を提供するだけでなく、いくつかの問題も生み出します。

• 売上データの説明と分析は困難です。
• 人事ミスは顧客の不満につながります。

したがって、多くの企業は、データの集約を1か所で考えています。これは、制御と管理が簡単です。 彼らのために、Bitrix24 *サービスにはOpen Linesツールがあります。これについては以下で説明します。



ところで、 「チャットボットが必要なのはなぜですか」という多くの心配の質問にすぐに答えます。私たちの場合、使用は解決する必要のあるタスクに依存します。複雑-カスタマーサポートを自動化できます。



*ヘルプ： Bitrix24サービスは、会社の業務を整理するためのインターネットツールのセットです。 これには、タスクおよびプロジェクト管理、オムニチャネルCRM、会社の内部メッセンジャー、ワーキングソーシャルネットワーク、勤務時間管理、ドキュメント管理などの機能が含まれます。

仕組み：ユーザービュー

クライアントは、ソーシャルネットワークまたはインスタントメッセンジャーで会社の公式アカウントに書き込みます。 このメッセージは、すべてのチャネルに共通の処理キューに到着します。 それから、メッセージはBitrix24メッセンジャー内で応答する従業員間で配信されます。 理解できるように、これは自動化されたプロセスであり、レスポンダーにとって、クライアントが作成したチャネルに違いはありません。

仕組み：開発者からの外観

Microsoft Bot Frameworkとの統合

Microsoft Bot Frameworkは、クラウドでインテリジェントなチャットボットを作成できる環境であり、SkypeやTelegramからSlackやSMSまで、さまざまな通信チャネルを介して通信できます。 プロキシとしても使用できます。 これらのチャネルごとに個別に統合を実装する必要がないため、これは便利です。



Microsoft Bot Frameworkとの統合のために、既存のOpen Lines作業スキームがいくつかの改善とともに使用されました。



特別なコネクタサーバーを作成しました。 これは、ソーシャルネットワーク、インスタントメッセンジャー、オンラインチャット、サイト上のフォームなどの外部通信チャネルとBitrix24クライアント間のリンクです。 サーバーの主な利点：

• ソーシャルネットワークおよびインスタントメッセンジャーからBitrix24へのメッセージ配信を保証します。
• Bitrix24クラウドとボックス版の両方で動作します。
• ソーシャルネットワークまたはメッセンジャーの会社の公式アカウントをBitrix24にすばやく接続できます。

Bitrix24クライアントとコネクタサーバー間のデータ交換は、独自のプロトコルを使用して実行されます。 この場合、サーバーはルーターとして機能し、着信データと発信データの予備処理を行います。



サーバー環境の要件はBitrix24と若干異なります：PHP 5.4以降、MySql 5.5.3、InnoDB。



Bitrix24クライアントとコネクタサーバー間のデータ交換中のオーバーヘッドを最小限に抑えるために、次のことが決定されました。

• 外部チャネルおよびサーバーからメッセージに添付されたファイルを転送しないでください。 サーバーは、外部ソースからのファイルへのリンクのみをBitrix24に送信します。 そして、Bitrix24クライアントはそれらを自分でダウンロードします。
• Bitrix24からファイルを送信する場合は、リンクを送信するだけでダウンロードできます。 ファイル自体はBitrix24.Diskに保存されます。
• メッセージの送信後に頻繁に使用されるアクション（メッセージの受信、送信、配信ステータスの送信、メッセージの読み取りなど）の場合、応答を期待せずに接続を閉じます。

コネクタサーバーのメッセージキュー

サーバー上のメッセージ送信キューは、MySQLに基づいて実装されています。 現在、Redisのようなより洗練された柔軟性のあるツールは必要ありません。 データベースベースのキューは、追加のオーバーヘッドを回避し、維持しやすく、現在の負荷に簡単に耐えることができます。



ポータルがしばらく利用できない場合でも、キューはメッセージ配信を保証します。 着信メッセージが処理され、データベースに配置されます。 別のプロセスがデータベース内のメッセージを継続的に選択して送信します。 同時に、複数のメッセージからパケットを形成し、それらをポータルに送信します。



配信確認がサーバーに到着しない場合、この「Open Line」へのこのポータルへの次の送信は、ブロック期間の終了後にのみ行われます。 各試行の後に、ロックの期間は増加します。 最後の試行が失敗した場合、メッセージの送信は12時間ブロックされます。 合計で、ポータルへのメッセージ送信の最初の試行から24時間になります。 最後の試行の後、このOpen Lineのこのポータルのすべてのメッセージが削除され、ロックが解除されます。



サーバーが確認を受信すると、配信されたメッセージはキューから削除され、このオープン回線のブロックが解除されます。 つまり、新しいメッセージはすぐにポータルに送信されます。

コネクタサーバーのメカニズム

「ファクトリメソッド」パターンを適用して、各通信チャネルを担当するコードを整理しました。 各コネクタがサポートするメソッドの標準セットを定義しました。 さらに、各チャネルには独自のメソッドを設定できます。



チャネルを機能させるには、ポータルで初期構成を実行する必要があります。 ユーザーはそれを行い、ポータルは特別な方法を使用して接続を管理します。 さまざまなタイプのコネクタの設定は、メソッドのセットによって大きく異なります。 Microsoft Bot Frameworkは、単純な構成オプションを使用します。 リモートのsaveSettings



メソッドは、必要なパラメーターが渡されるポータルから呼び出されます。 これらはデータベースに保存され、将来のチャネルの作業で使用されます。



次に、ポータルはリモートtestConnect



コネクターtestConnect



呼び出します。このtestConnect



は、指定されたデータとの接続を確認し、接続されたポータルの可用性も確認します。



Webhookは、Bot Frameworkサイトでボットを作成するときに指定されます。 ユーザーが設定するときに必要なアドレスを指定します。



ポータル側の構成インターフェースは次のようになります。







初心者は、ステップバイステップのウィザードを使用して、新しいボットをすばやく登録できます。



接続に成功すると、3つのデータ構造でレコードを取得します。







サイトに関する情報を記録します 。 重要なパラメーターはポータルドメインです。 サーバーは特定の場合にそれにアクセスします。



回線/コネクタレコードを開きます 。 以下を明確に定義します。

• コネクタタイプ;
• クライアント上の開いている回線のID。
• サイトへのリンク。
• WebHookを介してアクセスするときに要求が参照するオープンラインを決定する特別なハッシュ。
• メッセージキューの情報：クライアントへのメッセージ送信の試行回数と送信をブロックする時間。

特定のOpen Lineの特定のコネクタの接続パラメータの記録 。 コネクタの種類によって、パラメータのセットは大きく異なる場合があります。

Microsoft Bot Frameworkを使用してサーバーで直接作業する

ボットフレームワークには、チャネルのセット全体が含まれています。 そのため、「リアルチャネル」と「仮想チャネル」の概念を導入しました。 Botframework



は、単一の連絡先を使用するため、実際のチャネルです。 Botframework.skype



は、Microsoft Bot Frameworkを介してSkypeボットとの作業を実装する仮想チャネルです。



コネクタが機能するには：



1.ボットの設定で、必要なWebHookを指定します。

2.「Bitrix24」のチャンネル設定で正しい設定を示します。

• ボットハンドル;
• アプリケーションID
• アプリケーションの秘密。

WebHookのおかげで、コネクタサーバーはこのボットが接続されているオープンラインを判別します。 バインディングが見つからなかった場合、エラーが返されます。



エラーがない場合、受信したデータを処理します。

• クライアントとサーバー間の交換の形式でデータの配列を形成します。
• テキストを解析し、すべてのエンティティを理解可能なBitrix24メッセンジャー形式に変換します。 チャンネルごとに、これらの変換は異なります。
• すべての着信絵文字をユニバーサル絵文字形式に変換します。 私たちは、すべてのチャンネルがサポートする最大限の笑顔をカバーしようとしました。

すべての変換後、メッセージはメッセージキューに追加されます。



Bitrix24から外部メッセンジャーにメッセージを送信すると、ある形式から別の形式への逆変換が実行されます。 メッセージは、POSTメソッド/v3/conversations/{conversationId}/activities



を使用して送信されます。 送信に必要なデータはすべてメッセージに付属しています。



この場合、バイナリデータは送信されません。 すべての添付ファイルはBitrix24.Diskに入れられ、リンクとして送信されます。 これにより、トラフィックが節約されます。 また、必要に応じて、いつでもファイルへのアクセスを閉じることができます。

オープンラインの仕組み

チャットは、ソーシャルネットワークまたはメッセンジャーのユーザーからのメッセージで始まります。 単一のエントリポイントが使用されます。 これは、Open Lineハッシュを含むGETパラメーターを持つ単一のURLです。 ハッシュを使用して、システムは着信メッセージの送信先を決定します。

接続の一意性

外部システム（グループ、ボット）の同じエッセンスを複数のポータルまたは同じポータル内の異なるオープンラインに接続しようとする場合があります。 そのようなケースが処理されない場合、異常な状況と障害が発生する可能性があります。 そのため、接続の一意性を確認するメカニズムを実装しました。



異なるチャネルの再接続の試行は、異なる方法で定義されます。 Microsoft Bot Frameworkは、システム内の特定のボット識別子の存在を確認します。 現在の接続が唯一のものではない場合（繰り返し）、通常どおり機能し続け、以前の接続のデータはサーバーから完全に削除されます。 同時に、リクエストがポータルに送信され、このOpen Lineコネクタに「緊急」のマークが付けられるため、管理者の注意が必要です。

Bitrix24のクライアント部分のメカニズム

コネクタのクライアントモジュールは次の目的で使用されます。

• 通信チャネルの接続設定。
• メッセージの受信、処理、およびBitrix24メッセンジャー形式への変換。 イベントのその後の生成。
• ユーザー処理：外部ユーザーに関連付けられているBitrix24のユーザーデータを登録または更新します。
• メッセージ付きのファイルをダウンロードします。

Open Linesモジュールは、メッセージのルーティング、メッセージキューの作成、オペレーターやその他の機能への誘導を担当します。

クライアントでのデータ交換の実装

Open Linesモジュールでは、 Output



クラスがサーバーへのメッセージの送信と追加処理を担当します。 query



メソッドは、リモートサーバーへの発信パケットを直接形成し、メッセージに署名します。



Output



クラスは、「マジック」メソッドを使用して、リモートサーバーメソッドをローカルであるかのように呼び出します。 これには長所と短所があります。



欠点 ：「マジック」メソッドの速度はわずかに遅くなります。 しかし、それらは外部システムでの作業に使用されるため、遅延はそれほど顕著ではありません。



利点 ：内部メソッドと同様に外部メソッドを使用できます。 つまり、開発者はローカルでリモートメソッドを呼び出します。 すべての作業は標準化されています。 クライアントにメソッドのリストを保持する必要はなく、このリストを同期する必要もありません。 メソッドをサーバーに追加するだけで十分であり、クライアントで使用できます。



外部サーバーの一部のメソッドにはローカルラッパーがあります。 リクエストをリモートサーバーに送信する前に、さまざまなタスクを実行します。 たとえば、（リモートサーバーの負荷を軽減するために）データをキャッシュし、前処理を行います。



すべての着信要求は、 Input



クラスによって処理されます。 着信パケットを解析し、署名（要求が実際にサーバーから送信されたものであること）を検証し、着信要求をルーティングするRouter



クラスにデータをリダイレクトします。



着信リクエストの種類：

• 接続テスト 。 このメソッドは、クライアントの可用性を確認するときにリモートサーバーによって呼び出されます。
• 受信メッセージ（すべてのタイプ） 。 詳細は以下をご覧ください。
• 配信ステータス 。 配信ステータスに加えて外部メッセージIDが付属しているため、外部データを管理できます。 たとえば、外部IDがわからないと、リモートサーバー上のメッセージを削除できません。
• ステータスを読み取ります 。
• コネクタを無効にします 。 このコネクタが別のポータルまたはオープンラインに接続されたときに呼び出されます。

Bitrix24クライアントによるメッセージの受信

input



クラスは、ポータルから着信メッセージ（メッセージ配列）を受け取り、処理を開始します。 メッセージ配信通知がサーバーに送信されます。 彼はそれらをキューから削除し、メッセージのさらなる送信のロックを解除します。







受信したメッセージはさらに処理されます。 ショートネーム絵文字は、Bitrix24メッセンジャーでサポートされている特別なicon



タグに変換されicon



。 これにより、利用可能なすべての絵文字がサポートされます。



すべての添付ファイルが処理されます。 それらはダウンロードされ、内部システムに登録されます。 また、ファイルを記述する配列では、ファイルへのリンクが内部IDに置き換えられます。



ソーシャルネットワークまたはメッセンジャーの外部ユーザー用に作成された内部ユーザーのポータル上の存在を確認します。 そうでない場合は、作成されます。 ユーザーが存在する場合、ユーザーデータからのmd5ハッシュがチェックされます。 受信したデータと比較され、ハッシュが異なる場合、ユーザーデータが更新されます。 次に、受信した配列で、Bitrix24ポータル内のユーザーIDに置き換えられます。



このような変換されたデータ配列は、生成されたOnReceivedMessage



イベントに配置されます。 Open Linesモジュールによって「キャッチ」されます。

発信リクエスト「Bitrix24」

発信要求は実際には処理されません。 それらはリモートコネクタサーバーにルーティングされます。 Bot Frameworkの場合、追加のハンドラーがクライアントで作成されます。



このコネクタは、送信メッセージで送信者に関する情報を送信する必要があるという点で他のすべてのコネクタと異なります。 接続されたときに送信されません。 しかし、入力で取得できます。 そのため、各チャットと各ダイアログに関するサポート情報を保存するために、個別のテーブルが作成されています。



このコネクタの着信メッセージについては、必要な情報を選択して保存するfurtherMessageProcessing



メッセージfurtherMessageProcessing



メソッドがfurtherMessageProcessing



ます。 また、Botframeworkチャネルにメッセージを送信するとき、sendMessageProcessingメソッドは必要なデータを混合します。

結論の代わりに

現在、ほとんどのBitrix24ユーザーは、Bot Frameworkチャネルを接続して、Skypeを介して視聴者と連携しています。 記事の公開時点で、接続されているボットの数は9000です。