👨🏽‍🚀 ✌️ ✂️ PHPでの10分でわかるすべてプロトコルのボット、またはMicrosoft Bot FrameworkとAzure Functionsが私たちの生活を楽にする方法 🎵 🐻 🧗🏽

インターフェイスの自然なパターンの開発が、IT業界全体の発展に素晴らしい推進力を与えたことを否定することは絶対に不可能です。そして、音声インターフェースだけでなく、ジェスチャーの普及、モバイルプラットフォームのパラダイムの大きな変化、そしてもちろん、UIとUXの分野での重要な仕事についても重要です。業界は、増え続ける人々に対してますます友好的になるよう努めていますが、通常の、そしてある程度までの日常的な開発は、広大さを受け入れる無限の試みに変わります。以前は、主に言語とフレームワークの抽象化のレベルに関心がありましたが、今でははるかにグローバルな問題に直面しています。複雑なインターフェースと機能的なインターフェースのバランスを見つける方法マイクロサービスを使用して新しいプロジェクトを開始する必要がありますか？これらの質問に答えることはできませんが、新しい技術と開発アプローチの開発と適用をすでに非常に容易にし、コストを削減しているツールについては説明できます。

はじめに

チャットボットの歴史は長く、あまり成功していませんが、タッチインターフェイスやニューラルネットワークのように、それらについて言うことができます-すべてに時間があります。歴史の最後のラウンドでは、ボットはアジアのメッセンジャーとソーシャルネットワークに人気があります。アジアで始めて、彼らは西洋の社会サービスを征服しに行きました。次に、APIを急いで作成している人々は、さまざまな機会とプラットフォームでの潜在的な収益額で競争し始めました。これは、ボットを開発するという同じタスクに直面したが、コンテンツおよびサービスプロバイダーからの通常の開発者の生活を悪夢に変えました。

何らかの方法でクライアントに到達する可能性のあるインスタントメッセンジャーの数をカウントできます。また、従来のSMS、電子メール、およびWebチャットもあります。誰もが独自のAPIまたはSDKを提供するため、これらすべてには特別なアプローチが必要です。そして、同じものの多数の異なる実装を開発およびサポートしないように、多かれ少なかれ一貫性のあるコードですべてを管理するのは素晴らしいことです。ビジネスでは、小規模な販売チャネルの質の高いカバレッジではなく、より多くのチャネルの定量的なカバレッジが必要です。一部のチャネルが他のチャネルよりも多くのお金をもたらす場合でも。または、一部のチャネルが他のチャネルよりも多くの機能を提供する場合。

それでは、同じものの異なる実装間で作業を無限にラッシュすることなく、できるだけ多くのチャネルをどのようにカバーしますか？利用可能なソリューションの1つは、フレームワークを使用することです。もちろん、これはすべての問題を解決するわけではありませんが、少なくとも精神的なバランスを維持し、理想的には顧客または雇用者のお金を維持します。

Microsoft Bot Framework

Microsoft Bot Frameworkは、1年前にMicrosoft Build 2016で初めて導入されました。ただし、まだプレビュー段階にあるため、現在の形式の大規模プロジェクトでさまざまな種類の特定の問題を引き起こす可能性があります。少なくとも、現時点では本番環境で使用することは絶対にお勧めできません。

このフレームワークのすべての機能と利点については説明しません。ドキュメントや他の記事から簡単に見つけることができます。この資料の一部として、Microsoft Bot Frameworkのボットの実用的な実装について少し詳しく説明します。

ボットは基本的に難しいように思えるかもしれませんし、馴染みのないフレームワークではさらにそうです。しかしそうではありません。ヘッダーで述べたように、Microsoft Bot Frameworkを使用した最も単純なボットの実装には10分しかかかりません。この記事のコードを記述してデバッグするには多くの時間がかかり、Azure Functionsで実行する適切なテンプレートを見つけるのに2倍かかりました。

なぜPHPなのか？

さまざまな理由から、この資料にPHPを選択しました。まず、私の仕事の主な焦点はWeb開発であり、少なくともロシアではPHPがこの分野で最も人気のある言語であるためです。例にPythonコードを含めることを考えていましたが、すでに肥大化した資料を複雑にしないことにしました。これが興味深い場合は、別の記事に記載できます。第二に、Microsoftは、PHPまたはPythonでボットフレームワークを使用することも可能であると主張していますが、実際にはそれらを慎重に無視し、ドキュメントや例を提供せず、SDKもありません。それはREST APIとそのドキュメントだけです。開発者の良心に関する認識。開発者は、それがどれほど素晴らしく、単純であっても、自分の言語で十分に文書化されていない技術を無視する可能性があります。他の言語の例は、特に「async / await」などの外部構造でオーバーロードされている場合は、必ずしも読みやすいとは限りません。

Azure Functionsを選ぶ理由

Azure Functionsを選んだ理由は、読者がこの例のコードを試して練習する最も簡単で安価な方法だからです。実際、この資料から本格的なボットを起動するために必要なことは、[ Azureにデプロイ ]ボタンをクリックして、アプリケーションのパラメーターをいくつか入力することだけです。 Azureは、必要なリソースを作成および構成し、GitHubからサンプルコードをダウンロードし、アプリケーション全体の料金を支払う必要がないように課金を設定します。実際には、ボットが処理するメッセージに対して、ボットへの直接の呼び出しに対してのみ支払うことになります。

また、サーバーレスアーキテクチャを使用したマイクロサービスのトピックに興味があり、Azure Functionsに精通していない場合は、それらを知るための素晴らしい機会になります。ただし、マイクロサービスとその中のAzure Functionsの役割は、別の記事の別のトピックです。

実装

これとは別に、この例は意図せずに最も単純で、直線的で、読みやすく、視覚的に書かれていることに注意してください。もちろん、作業コードとして使用することはできません。現在、SDK for PHPがないため、この例をクラスと個別の関数で複雑にすることは完全に冗長であり、読みやすさと認識を複雑にします。

準備する

したがって、最初に行う必要があるのは、ボット自体を作成することです： https : //dev.botframework.com/bots/new ボット名（名前）、説明（説明）、およびURLの名前付けのエイリアス（ボットハンドル）を作成します。名前や説明とは異なり、ボットの作成後にエイリアスを変更することはできません。現時点では「メッセージングエンドポイント」フィールドを空白のままにします。アプリケーションの起動後に入力します。

[MicrosoftアプリIDとパスワードの管理]ボタンをクリックして、アプリケーションの識別子とパスワードを作成します。 IDとパスワードは、チャットにメッセージを送信するときにアプリケーションをボットとして認証するために必要なので、保存します。 [操作を完了してボットフレームワークに戻る]ボタンをクリックします。

この準備部分はほぼ終了です。確認し、すべての契約の同意を確認して、「登録」をクリックします。すべてが正しければ、すぐに「ボットが作成されました」というメッセージが表示されます。名目上、ボットの準備は完了です。彼に伝えることを教えることは残っています。

コード

まず、ボット認証用のアプリケーションIDとパスワードを設定します。あなたはそれらを最後のステップで手に入れました。同時に、ボットの回答を承認するトークンについて問い合わせるURLを設定します。

$client_id = getenv('MicrosoftAppId'); $client_secret = getenv('MicrosoftAppPassword'); $authRequestUrl = 'https://login.microsoftonline.com/common/oauth2/v2.0/token';

この例では、環境変数からパラメーターを取得しますが、コードで直接設定できます。

 $client_id = '26XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'; $client_secret = 'CJPXXXXXXXXXXXXXXXXXXXXXXXXXXXX'; $authRequestUrl = 'https://login.microsoftonline.com/common/oauth2/v2.0/token';

次に、ユーザーからのメッセージでPOSTリクエストの本文を読み取り、JSON形式から$ deserializedRequestActivity配列にデシリアライズします。

 $request = file_get_contents(getenv('req')); $deserializedRequestActivity = json_decode($request, true);

この例では、Azure Functionsバインダーで事前構成されているreq環境変数から要求本文を取得します。 Azure Functionsを使用していない場合は、 php：//入力ストリームからリクエスト本文を取得できます。

 $request = file_get_contents('php://input'); $deserializedRequestActivity = json_decode($request, true);

$ deserializedRequestActivityにidフィールドが含まれる場合、着信リクエストが正しいと見なし、処理を開始します。まず、メッセージへの応答を許可するトークンを取得する必要があります。トークンは、Microsoft oAuthサービスへのPOST要求を通じて取得できます。リクエストのストリームコンテキストを使用するのは、その実装の見栄えがよく、 CURLを使用できるためです。

 $authRequestOptions = array( 'http' => array( 'header' => "Content-type: application/x-www-form-urlencoded\r\n", 'method' => 'POST', 'content' => http_build_query( array( 'grant_type' => 'client_credentials', 'client_id' => $client_id, //ID  'client_secret' => $client_secret, //  'scope' => 'https://graph.microsoft.com/.default' ) ) ) );

上記で構成されたストリームコンテキストを作成し、そこからoAuthサービスへのリクエストを実行します。

 $authRequestContext = stream_context_create($authRequestOptions); $authResult = file_get_contents($authRequestUrl, false, $authRequestContext);

要求に対する応答を読み取り、 $ authData配列に逆シリアル化します。

 $authData = json_decode($authResult, true);

$ authDataにaccess_tokenフィールドが含まれている場合、認証が成功したと見なし、処理を続行します。受信したメッセージのタイプを判別し、着信メッセージのタイプがメッセージである場合に備えて、メッセージへの応答のテキストを準備します。この例では、他のすべてのタイプのメッセージを処理するわけではありません。したがって、他のすべてのタイプに対して、それらに慣れていないことを単に伝えます。

 switch ((string)$deserializedRequestActivity['type']) { case 'message': $message = 'New message is received: ' . (string)$deserializedRequestActivity['text']; break; default: $message = 'Unknown type'; break; }

応答する内容がわかったので、応答データを使用して$ deserializedResponseActivityの配列を作成し、後でMicrosoft Bot Frameworkに転送します。

 $deserializedResponseActivity = array( //    'type' => 'message', //    'text' => $message, //,   -    'textFormat' => 'plain', //   'locale' => 'ru-RU', //  ID ,      (   id  POST-  ) 'replyToId' => (string)$deserializedRequestActivity['id'], // id     (   recipient->id  recipient->name  POST-  ,   id  name,     ) 'from' => array( 'id' => (string)$deserializedRequestActivity['recipient']['id'], 'name' => (string)$deserializedRequestActivity['recipient']['name'] ), // id    ,   ,      (   from->id  from->name  POST-  ) 'recipient' => array( 'id' => (string)$deserializedRequestActivity['from']['id'], 'name' => (string)$deserializedRequestActivity['from']['name'] ), // id ,     (   conversation->id  POST-  ) 'conversation' => array( 'id' => (string)$deserializedRequestActivity['conversation']['id'] ) );

回答を作成したので、それを送信する準備をしています。そのためにURLを作成し、そこで転送します。実際、URLは着信POST要求のパラメーターから組み立てられ、次のようになります。

https:// {activity.serviceUrl} /v3/conversations/ {activity.conversation.id} /activities/ {activity.id}

アクティビティは、メッセージを含む着信POST要求で、先ほど$ deserializedRequestActivity配列に逆シリアル化されています。

{activity.serviceUrl}をrtrimに渡して、最後の最後のスラッシュを除外します。これは、そうである場合とそうでない場合があるためです。また、 {activity.id}にはurlencodeを渡す必要があります。これには、URLを中断してリクエストを妨害する特殊文字が含まれているためです。

 $responseActivityRequestUrl = rtrim($deserializedRequestActivity['serviceUrl'], '/') . '/v3/conversations/' . $deserializedResponseActivity['conversation']['id'] . '/activities/' . urlencode($deserializedResponseActivity['replyToId']);

URLの準備ができました。これで、Microsoft Bot Connector APIへのPOST要求を準備し、受信メッセージへの応答を送信します。まず、ストリームコンテキストを構成します。リクエストのストリームコンテキストを使用するのは、その実装の見栄えがよく、 CURLを使用できるためです。

 $responseActivityRequestOptions = array( 'http' => array( //   POST-    ,   (token_type)    (access_token) 'header' => 'Authorization: ' . $authData['token_type'] . ' ' . $authData['access_token'] . "\r\nContent-type: application/json\r\n", 'method' => 'POST', //      JSON-     $deserializedResponseActivity 'content' => json_encode($deserializedResponseActivity) ) );

そしてすぐに作成し、ストリームコンテキストからMicrosoft Bot Connector APIへの構成された要求を実行します。

 $responseActivityRequestContext = stream_context_create($responseActivityRequestOptions); $responseActivityResult = file_get_contents($responseActivityRequestUrl, false, $responseActivityRequestContext);

チャットのユーザーは応答を読み取り、次のメッセージの受信と処理に関するログをSTDOUTストリームに書き込みます。

 fwrite(STDOUT, 'New message is received: "' . (string)$deserializedRequestActivity['text'] . '"');

打ち上げ

上記のコードはGitHubにあり、ここからコピーしたり、もう一度書いたりする必要はありません。独自の環境にコードをデプロイするか、Azure Functionsの既製のテンプレートを使用できます。独自の環境にコードをデプロイする場合は、ここをクリックしてAzure Functionsの部分をスキップしてください。

コードをAzureに自動的に展開するには、すぐ上の[Azureに展開]ボタンをクリックします。展開ウィザードは、「Microsoft App Id」と「Microsoft App Password」のみを要求します。準備段階で受け取ったものを入力してください。テンプレートで指定された名前はすでに使用されているため、「App Name」フィールドの値を必ず変更してください。そのままにしておくと、デプロイは失敗します。そこにいくつかの乱数を追加するだけです。さらに、必要に応じて、既存のリソースグループを選択するか、新しいリソースグループを作成できます。それ以外の場合、パラメーターはそのままにしておくのが最適です。規約を読んで同意してから、「購入」をクリックしてください。

最後に、デプロイされたアプリケーションへのリンクを取得し、ボットの準備段階で作成された「メッセージングエンドポイント」フィールドに貼り付ける必要があります。

アプリケーションがデプロイされるまで待ち、デプロイしたリソースグループに移動します。

新しくデプロイされたアプリケーションの名前でApplication Servicesインスタンス内に移動します。

「メッセージ」関数の名前の下の左側で、「開発」メニューに移動し、右側に開くウィンドウの「関数URLの取得」リンクをクリックします。ポップアップには、次の形式のリンクがあります。

https:// {__} .azurewebsites.net/api/messages?code= JqXXXXXXXXXXXXXXX...

codeパラメーターは、偶発的および悪意のある操作からアプリケーションを保護します。このキーを知らなければ、アプリケーションを強制的に動作させることはできません。つまり、リクエストでアプリケーションをオーバーロードして、Azureへの借金に追い込むことはできません。したがって、このパラメーターを誰にも見せないようにしてください。

リンクをコピーして、フレームワークポータルのボットのリストに戻り、そこからボットの編集に移動し、「メッセージングエンドポイント」フィールドにボットの編集（または、Azure Functionsを使用しなかった場合の例のmessages / run.phpスクリプトに似たもの）を貼り付けます。

検証とデバッグ

急いでボット管理ページを離れないでください。右側には、新しい電子ペットに何かを書き込もうとするWebチャットウィンドウがあります。

Azure Functionsテンプレートからコードをデプロイした場合、最初のメッセージへの回答に多少の遅れが生じても心配する必要はありません。これは、Application Servicesインスタンスの動作モードによるものです。たとえば、ホスティングコストを削減するために、テンプレートにはいわゆる「消費計画」が含まれており、サービスは必要に応じてリソースを消費します。簡単に言えば、実際に必要な場合にのみ開始およびスケーリングされます。さらに簡単に言えば、サービスはWebフックを引っ張る権限を持つ誰かが待機するまで待機できます。実行プロセス中に使用可能なリソースが十分にない場合、自動的にスケーリングされます。したがって、計算時間を節約できますが、これがあなたが支払う唯一のリソースではないことに注意してください。コールを処理した後、しばらくすると、サービスは再び「スリープ」状態になります。

既にいくつかのメッセージをボットに送信しており、ボットから応答を受信していない場合は、まずアプリケーションサービスインスタンスにアクセスします。サービスコールログ（STDOUTストリームからのデータを含む）とコードテストツールがあります。

デフォルトでは、コードは継続的デプロイメントモードでGitHubのサンプルリポジトリにリンクされます。したがって、コンソールでは、読み取り専用コードの可用性に関する警告が表示されます。コードを変更するには、継続的デプロイメントを完全に無効にするか、リポジトリを複製してサービスをリンクする必要があります。コンソールメニューから「アプリケーション機能パラメーター」の左側に移動し、「継続的インテグレーションの設定」ボタンをクリックする場合は、その両方を行うことができます。

チャンネル接続

デフォルトでは、SkypeとWebチャットはボットに接続されます。さらに、TelegramやSlackなどのインスタントメッセンジャーと、電子メールまたはSMSチャネルの両方が接続されています。また、独自のチャットアプリケーションまたはインスタントメッセンジャーを使用できるREST APIダイレクトラインインターフェイスもあります。すべての追加チャネルの設定には詳細な指示が伴いますが、原則として問題を引き起こすことはないため、これらの手順の詳細に進む理由はここにはありません。

この例のボットの「アドレスと外観」：

Telegram @Azure_Func_PHP_Bot
ウェブチャット

おわりに

マイクロソフトが非常に長い間自然なインターフェイスに取り組んできたのは秘密ではありませんが、現時点では、それ以上ではないにしても、同僚よりも確かに成功しています。私の意見では、このフレームワークはこれの素晴らしい例です。比較的最小限の労力で、最も広いチャネルカバーの1つを提供します。さらに、その機能は、すべてのインスタントメッセンジャーおよびダイレクトチャットルームに共通の機能の使用に限定されません。 Microsoft Bot Frameworkを使用すると、特定のメッセンジャーに固有の機能を使用したり、グループチャットで固有のロジックを使用したりできます。もちろん、彼は唯一のものではありません。誰かがこれについて異なる意見を持っているかもしれません。

この記事の目的：適切なツールを備えたWeb開発者が、追加のコストと労力をかけずに最初のボットを作成する方法を説明することです。そして、これで少なくとも試してみるのに十分であることを願っています。

しかし、これは間違いなく、ボットを顧客に任せるには十分ではありません。自然なインターフェースについて話すときは、ユーザーとの対話の形式だけでなく、ユーザーがこの対話をどのように感じるかということも意味します。これは同じUXです。実践が示すように、ユーザーは実際にはドライコマンドのみを認識し、単一の質問に答えることができないボットと通信することを好みません。マイクロソフトには、この問題に対する非常にエレガントなMicrosoft Cognitive Servicesソリューションがあります。

Microsoft Cognitive ServicesとNatural Speechは、この記事のトピックを継続できる非常に大きく重要な部分です。しかし、最初に、Web開発のコンテキストでこれがあなたにとってどれほど興味深いか聞きたいのですが？これから一連の記事を作成する価値はありますか？将来的にどの言語を見たいですか？

PHPでの10分でわかるすべてプロトコルのボット、またはMicrosoft Bot FrameworkとAzure Functionsが私たちの生活を楽にする方法