Q＆A MakerとMicrosoft Graphを使用してチャットボットを作成する

こんにちは、Habr！ 最近では、ブカレストとクルージュの開発者向けのハッカソンを実施しました。 Kluzhaグループの主なタスクは、Endavaをサポートし、Microsoft GraphとQ＆A Makerを使用して効果的なチャットプログラムを作成することでした。 本日は、このプロジェクトについて説明します。このプロジェクトは、任意のチャネルを介してロボットプログラムと対話するための認証管理、Q＆A Makerの統合、およびMicrosoft GraphとSharePointの組み合わせに影響します。 詳細はこちら！

はじめに

このプロジェクトは、開発者EndavaとMicrosoftの非公開ハッカソンで作成されました。 このハッカソンはクルージュとブカレスト（ルーマニア）の都市で開催されました。 参加者の主なタスクは、ITサポートに使用されるEndava Webアプリケーションを改善するAIコンポーネントのプロトタイプを作成することでした（たとえば、ユーザーが自然言語チャットロボットとメッセージを交換したり、機械学習技術を使用して通話管理を最適化したりできます） 。



このハッカソンは2018年1月30日から2月2日まで開催されました。このGitHubページでは、クルージュで3日間行われた作業の一部を紹介しています。 開発チームには以下が含まれます。

• Corina Ciocanea、開発者（Endava）
• Alexandru Marchis、開発者（Endava）
• チューダームレサン、開発者（Endava）
• Laurent Ellerbach、技術福音主義者、チームリーダー（マイクロソフト）

プロジェクトの説明

Kluzhaグループの主なタスクは、いくつかの機能をサポートする効果的なチャットプログラムを作成することでした。

• Endavaコール管理システムで直接リクエストを作成するのに便利です（ユーザーにとって）。
• Microsoft Graphを介してSharePointへのアクセスを要求するロボットプログラムの実験バージョンを作成し、SharePointの所有者に直接電子メールを送信するか、Service Nowという会社の専用アプリケーションでアプリケーションを作成する要求を準備します。
• Q＆Aメーカーを使用して、Endavaページで質問への回答を含むカスタム質問への回答を見つけます。
• すべての認証操作は、Endava Active Directoryとの統合を通じて実行する必要があります。
• ユーザーの大多数が以前は電子メールを送信して呼び出しを作成していたため、ソリューションは電子メールの処理をサポートする必要があります。

このドキュメントに含まれる情報：

• 電子メールを含む任意のチャネルを介してロボットプログラムと対話するための認証を管理する方法。
• Q＆A Makerをロボットプログラムと統合する方法（Q＆A Makerロボットプログラムの作成はここでは考慮されません）。
• Microsoft GraphをSharePointと組み合わせて使用​​し、電子メールを送信します。 ここに示すコードは、3日間で開発されたより複雑なソリューションの一部です。

ソリューションのアーキテクチャスキーム：

使用技術

このソリューションのコードは、次のテクノロジーを使用します。

• Q＆Aメーカー ;
• Microsoft Bot Framework ;
• Microsoft Graph
• Azure Active Directory
• LUIS.ai-文を分析する機能を備えた認知テキスト認識サービス。
• すべてのサービスはMicrosoft Azureでホストされ、ロボットプログラムはWebアプリケーションとして実装されました。
• すべてのコードはVisual Studio Enterprise環境のC＃で作成されました。 VSTSプラットフォームは、コードリポジトリとして使用されました。

認証

私たちのアイデアは、ロボットプログラムに特定のユーザー（SharePointサイトなど）に関する情報を含むコンテキストへのアクセスと電子メールを送信する機能を提供することでした。 そのため、ロボットプログラムは安全で、従業員のみがアクセスできる必要がありました。



これらの問題を解決するには、認証が必要でした。 その実装には多くの困難が伴いました。たとえば、ロボットプログラムは電子メールを処理できなければならず、したがって内部認証手順がなくてもユーザーを認証できなければなりません。 Endava Azure Active DirectoryはAADサービスバージョン1であるため、メインロボットプログラムのプラットフォームとしてAAD 1を使用しました。認証を実装する場合は、以下を考慮することをお勧めします。

• AuthBotの例のコードを使用する場合、このメカニズムを必ず保存（コピー）してください。 これはセキュリティ上の理由から重要です。 チャットロボットとブラウザは異なるコンテキストにあり、いくつかの攻撃ベクトルをブロックします。
• 特定のアプリケーションを許可するようにAADサービスを構成します。 クライアントIDとシークレットを受け取ります。これらはweb.configファイルの必要な部分に入力する必要があります。
• アプリケーション構成ファイルに正しい戻りURLが指定されていることを確認してください。 このようなアドレスをいくつか作成することができます（たとえば、デバッグ用および作業バージョン用）。それらはすべてリダイレクトURLと完全に一致する必要があるため、プロトコル（https / http）を含む完全なパスを指定する必要があります。
• 特定のロール（Sites.Read.All、Mail.ReadWrite、User.Read、People.Read、Directory.AccessAsUser.Allなど）のアプリケーションのAAD設定で正しい承認パラメーターが指定されていることを確認してください。

完成したプロジェクトの認証、セキュリティ、および承認は、次のように編成されています。







ご覧のとおり、メインコンテキストはAADの認証に依存しています。 次のコンポーネントは、AADに基づいて機能します。

• ここでは考慮しない内部Service Nowサービス。
• ロボットプログラムのコア。Webアプリケーションはその一部です。 ここでは、クラシックIDとクライアントキーが使用されます。
• ロボットプログラム自体とLUIS認知サービス。 ここでは、クラシックIDとクライアントキーも使用されます。
• ロボットプログラムとQ＆Aメーカーサービス。 ここでは、クラシックIDとクライアントキーも使用されます。

すべてのサービスにアクセスするためのキーとIDを構成する

AADを構成する

ここで、必要な環境をセットアップした後、web.configファイルに以下にリストされているパラメーターの正しい値を入力する必要があります。

• Tenantパラメーターは、AADのドメイン名と一致します。 これは、構成に応じて、第2レベルドメイン（yourdomain.com）または第3レベル（yourdomain.onmicrosoft.com）になります。
• アプリケーションのセットアップ時に取得するClientId（クライアントID）とClientSecret（シークレット）の設定。
• RedirectURL（リダイレクトURL）-ロボットプログラムが展開されるURL。 この例では、これはローカルノードです。 システムの作業バージョンでは、URLは異なります。 アプリケーションを構成するときに、考えられるすべてのケースに対して複数のURLを設定できることを思い出してください。

<!--  AAD Auth v1--> <add key="ActiveDirectory.Mode" value="v1" /> <add key="ActiveDirectory.ResourceId" value="https://graph.microsoft.com/" /> <add key="ActiveDirectory.EndpointUrl" value="https://login.microsoftonline.com" /> <add key="ActiveDirectory.Tenant" value="YOUR_DOMAIN.COM" /> <add key="ActiveDirectory.ClientId" value="client_ID" /> <add key="ActiveDirectory.ClientSecret" value="super_secret" /> <add key="ActiveDirectory.RedirectUrl" value="http://localhost:3979/api/OAuthCallback" />
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このセットアップは簡単な作業ではありません。 認証エラーの場合、システムは理由を調べる場所を理解するのに役立つメッセージを表示します。 これらのメッセージは非常に詳細であり、トラブルシューティングに非常に役立ちます。 一般に、このセットアップは非常に複雑になる可能性があります。 特定のアクセス権を取得するには、ドメイン管理者に連絡する必要がある場合があります。 このステップに十分な時間を割り当てることを強くお勧めします。 幸いなことに、このコンポーネントが機能したら、設定に戻る必要はありません。

ロボットプログラムのセットアップ

ロボットプログラムの作成および登録の段階で、ロボットプログラムの名前、ID、およびクライアントキーが生成されます。 これらの値は、web.configファイルの次の行に追加する必要があります。

  <add key="BotId" value="YourBotId" /> <add key="MicrosoftAppId" value="" /> <add key="MicrosoftAppPassword" value="" />
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Q＆A Makerセットアップ

Q＆Aメーカーを作成すると、IDとキーも受け取ります。 サービスに連絡して推奨事項を受け取るには、彼らが必要になります。 web.configファイルの次の行に適切なキーを入力します。

  <!--  QnaMaker --> <add key="QnaMaker.KbId" value="QAMaker_ID" /> <add key="QnaMaker.KbKey" value="QAMaker_Key" />
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

LUISを構成する

LUISは 、SharePointダイアログで、アクセスするSharePointリソースのURLまたは名前、およびアクセスの種類を取得するために使用されます。 このサービス（他のほとんどのサービスと同様）を作成して構成すると、IDとシークレットが取得されます。 メインダイアログクラスをLUIS属性でマークする必要があります。

  [LuisModel("Key-with-dash", "secret")] public class SpDialog : LuisDialog<object>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コード認証管理

コードには、さまざまな認証操作がわずかに異なる方法で実装されています。 主な認証手順は、AADサービスにアクセスすることです。この場合、ソリューションは、Microsoft Graphへの後続の呼び出しのためにトークンを受け取ります。

AADでの認証

このメカニズムは次のように機能します。







ほとんどのコードはAuthBotコンポーネントに関連しています。 すでに説明したように、特定の攻撃ベクトルをブロックするには、コードを変更せずに転送することが重要です。 トークンにはさまざまな情報にアクセスするために必要なすべての資格情報が含まれているため（この場合、ユーザーのアドレスから電子メールを送信するため）、トークンは非常に重要です。 セキュリティシステムを使用するときは、労力を節約しないでください。 保護には最大限の注意を払う必要があります。



AADを介した認証も電子メールに対して機能します。 注：認証は、ロボットプログラムが実稼働環境で実行されている場合に、電子メールでやり取りする場合にのみ検証できます。 電子メールはOffice 365アカウントから受信され、約___分ごとに処理されます。



ユーザーにとって、電子メールを介したシステムとのやり取りは、他のチャネルとほとんど変わりません。 ユーザーは電子メールを送信し、ロボットプログラムはシステムへの招待を送信します。それに応じて、ユーザーはコードを送信する必要があります。 基本のAuthBotコードは、対話をより便利にするように変更されました（特に、送信される電子メールの数を減らし、コード抽出を簡素化します）。



最初の文字に応答して、ロボットプログラムはユーザーにメッセージを送信し、認証のためにリンクをたどる要求を送信します。 その後、ユーザーはコードを送信する必要があります。







それを受信した後、ロボットプログラムは認証の成功に関するメッセージを送信します。 ユーザーが送信する他のすべてのメッセージは、このユーザーのコンテキストを考慮して、ロボットプログラムのサービスプロセスによって処理されます。 通信チャネル（チームまたはその他）に関係なく、ユーザーは同じ操作を実行できます。 ただし、電子メールチャネルは他のチャネルとは少し異なります。特に、ユーザーに送信される電子メールの量を制限し、いくつかの追加の前提条件を考慮する価値があります。 詳細については、以下をご覧ください。







AuthBotの詳細については、対応するGitHubページをご覧ください 。

ロボットプログラムと対話するための認証

認証の場合、ロボットプログラムと対話するとき、SDKのコンポーネントを使用してこのようなプログラムを開発します。 メインコントローラーがBotAuthentication属性でマークされている場合、前のセクション（構成に関する部分で）で説明したキーとシークレットを使用した認証メカニズムが使用されます。 これは完全に透過的であり、これら2つの要素をエラーなしでweb.configファイルにコピーすると、正常に機能します。 デバッグモードでもIDとシークレットが必要です。 エミュレータはこのメカニズムをサポートしており、ペアが機能しているかどうかを確認するのに最適です。

 namespace BotToQuerySharepoint { [BotAuthentication] public class MessagesController : ApiController { /// <summary> /// POST: api/Messages ///        /// </summary> [BotAuthentication] public async Task<HttpResponseMessage> Post([FromBody]Activity activity) { //  } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Q＆A Makerでの認証

キーはREST APIにアクセスするために使用されます。 作業はシンプルで明白な方法で構成されています。 コードスニペットは次のとおりです。

 public virtual async Task MessageReceivedAsync(IDialogContext context, IAwaitable<IMessageActivity> item) { var message = await item; { string kbId = ConfigurationManager.AppSettings["QnaMaker.KbId"]; string kbKey = ConfigurationManager.AppSettings["QnaMaker.KbKey"]; string qnaUrl = $"https://westus.api.cognitive.microsoft.com/qnamaker/v2.0/knowledgebases/{kbId}/generateAnswer"; HttpClient client = new HttpClient(); var json = new { question = strtosend, top = 3 }; var content = new StringContent(JsonConvert.SerializeObject(json), Encoding.UTF8, "application/json"); content.Headers.Add("Ocp-Apim-Subscription-Key", kbKey); HttpResponseMessage response = await client.PostAsync(qnaUrl, content); if (response.StatusCode == HttpStatusCode.OK) { //  ,   ,       } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

APIは非常に単純です。 ドキュメントはこちらから入手できます 。 各質問に対して3つ以下の回答を返すAPIの1つのみを使用します。

LUIS認証

前のセクションで説明したように、認証を有効にするために、単にクラス属性を指定しました。 このメカニズムは完全に透過的です。

メールチャンネル

既に述べたように、電子メールチャネル（SMSチャネルなど）には特定の機能があります。 どちらの場合も、送信されるメッセージの量を減らすよう努めることは合理的です。 これを行うために、認証プロセスをわずかに変更して、電子メールの数を減らし、レターからコードを抽出しました。



電子メールでメッセージを送信することにより、ユーザーは以前の通信やその他の不要な情報を削除することはほとんどありません。単に新しいテキストを追加するだけです。 その結果、レターにはユーザーの署名とその他の要素が含まれます。 したがって、このチャネルを介して対話する場合、それらを削除するには追加の作業が必要になります。 例として、以下はAuthBotのAzureAuthDialogコードのスニペットです。

 if (msg.Text == null) { if (msg.ChannelId != "email") { await context.PostAsync($",       ."); } context.Wait(this.MessageReceivedAsync); } else { //    ,         (,          Teams)      string cleanedText = msg.Text; Match firstmatchedValue = Regex.Match(msg.Text, @"\d+", RegexOptions.IgnorePatternWhitespace); if (firstmatchedValue.Length > 0) cleanedText = firstmatchedValue.Value; if (cleanedText.Length >= 6 && magicNumber.ToString() == cleanedText.Substring(0, 6)) { context.UserData.SetValue<string>(ContextConstants.MagicNumberValidated, "true"); context.Done($" {authResult.UserName}. You are now logged in. "); } else { context.UserData.RemoveValue(ContextConstants.AuthResultKey); context.UserData.SetValue<string>(ContextConstants.MagicNumberValidated, "false"); context.UserData.RemoveValue(ContextConstants.MagicNumberKey); await context.PostAsync($" ,     . ,      ."); context.Wait(this.MessageReceivedAsync); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ユーザーに送信される電子メールの数を減らすために、受信した認証コードを返送するだけでなく、Webページに表示してユーザーに手紙に返信するように依頼します。 OAuthCallbackControllerコードからわかるように、AuthBotの認証手順は通信チャネルによって異なります。

 await Conversation.ResumeAsync(resumptionCookie, message); if (message.ChannelId == "skypeforbusiness") resp.Content = new StringContent($"<html><body> !   , ,         :<br/> {magicNumber} </body></html>", System.Text.Encoding.UTF8, @"text/html"); else if (message.ChannelId == "email") resp.Content = new StringContent($"<html><body> !   , ,              :<br/> {magicNumber} </body></html>", System.Text.Encoding.UTF8, @"text/html"); else resp.Content = new StringContent($"<html><body> !   , ,         :<br/> <h1>{magicNumber}</h1>.</body></html>", System.Text.Encoding.UTF8, @"text/html");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各チャネルには一意の名前があります。 これにより、ロボットプログラムの動作をチャンネルのタイプに簡単に適合させることができます。



別の例は、メインロボットプログラムのQ＆Aダイアログ（kbDialog）コードに含まれています。

 string strtosend = message.Text; if (message.ChannelId == "email") { var str = strtosend.Split('\n'); int maxidx = str.Length; if (maxidx > 3) maxidx = 4; for (int i = 0; i < maxidx; i++) strtosend += str[i] + " "; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードの目的は、電子メールの最初の部分のみを抽出し、署名を削除することです。 可能性のある質問が最初の3行に含まれていると想定されます。 以下は、以前の手紙またはユーザーの署名です。 これは単なる仮定であり、常に満たされるわけではありませんが、3日間のハッカソン中に完全に機能しました。



別の例は、応答の戻りを制御するQ＆A Makerコードスニペットです。 通常、ソリューションは3つ以下のオプションをユーザーに提供し、ユーザーに最適なオプションを尋ねます。 しかし、ユーザーが質問を電子メールで送信する場合、ユーザーはカウンターリクエストではなく回答を受け取ることを期待しています。 これを行うことにしました。質問が電子メールで受信された場合、ソリューションは最初の回答を返すだけです。 また、すべての応答の詳細な内容をメールに含めるオプションも検討しました。 次のコードスニペットは、この処理の実行方法を示しています。

 if (qnaResponse.answers.Count == 0) { await context.PostAsync( "      . \n    -     QNA?"); context.Done(true); } else if ((qnaResponse.answers.Count == 1) || (message.ChannelId == "email")) { await context.PostAsync(qnaResponse.answers.First().answer); context.Done(true); } else { //   }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Microsoft GraphとSharePoint

Microsoft Graph-ユーザーデータの読み取り、変更、作成のための単一のREST API（例：カスタムカレンダー、電子メール、SharePointコンテンツ、OneDrive）。 このプロジェクトの一環として、SharePointおよび電子メールとやり取りするためのGraph APIコンポーネントに興味がありました。



タスクを簡素化するために、Microsoft.Graph Nugetパッケージを使用しました。 Nugetパッケージのコンポーネントは、すべての要求を処理し、オブジェクトを返します。 ただし、トークンを認証して取得する必要があります。 幸いなことに、認証メカニズムはすでに準備されています（そして上記で説明しました）。



例として、SharePointサブサイトの所有者の名前を返す関数のコードを以下に示します。

 public async Task<UserInfo> GetOwnerNameForSite(string token, string siteId) { var graphService = new GraphServiceClient( new DelegateAuthenticationProvider( (requestMessage) => { requestMessage.Headers.Authorization = new AuthenticationHeaderValue("bearer", token); return Task.FromResult(0); })); var s = await graphService.Sites[siteId] .Drives.Request() .GetAsync(); var user = await graphService.Users[s.First().CreatedBy.User.Id].Request().GetAsync(); return new UserInfo() { EmailAddress = user.Mail, Name = user.DisplayName }; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GraphServiceClientオブジェクトを作成するときは、コードに示されているようにトークンを渡すだけで十分です。その後、必要なGraph関数を呼び出すことができます。



返されたアイテムはすべて非常に簡単に分析できるため、それらの操作は簡単で論理的です。 この場合、SharePointの所有者にメールを送信するため、メールアドレスと名前を取得する必要があります。 その後、名前でユーザーに連絡し、手紙を送ることができます。



Microsoft Graphを使用したメール送信も非常に簡単です。

 public async Task SendEmail(string accessToken, string emailAddress, string body, string subject) { var message = new Message(); message.Body = new ItemBody() { Content = body, ContentType = BodyType.Text }; message.ToRecipients = new List<Recipient>() { new Recipient() {EmailAddress = new EmailAddress() {Address = emailAddress}} }; message.Subject = subject; var graphserviceClient = new GraphServiceClient( new DelegateAuthenticationProvider( (requestMessage) => { requestMessage.Headers.Authorization = new AuthenticationHeaderValue("bearer", accessToken); return Task.FromResult(0); })); await graphserviceClient.Me.SendMail(message, true).Request().PostAsync(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、単純なテキストメッセージを送信しますが、HTMLもサポートされています。 複数の受信者に手紙を送ることもできます。 既製のソリューションをリリースするのにたった3日間しかなかったため、できる限りシンプルなコードを作成することにしました。



ユーザーが自分の資格情報で認証された場合、メールはメールボックスから送信され、送信済みフォルダーで利用可能になります。



このサイトでMicrosoft Graphのすべての機能を試すことができます。 独自の資格情報を指定して認証し、任意の機能を操作して、エリアの追加または削除が結果にどのように影響するかを確認できます。

Q＆Aメーカーのヒント

Q＆A Makerは、質問と回答のペアを非常に迅速に準備し、質問に対する回答を得ることができる認知サービスを開始するための優れたツールです。 このツールは統合が非常に簡単で使いやすいです。 このサービスの作業はまだ進行中です。 利用可能なバージョンは、ガイダンスのみです。 これは次のようなものです。







リストに入力するいくつかの方法がサポートされています。 API（ドキュメントはこちらから入手可能）を使用するか、tsvファイルをインポートするか、URLを提供できます。



Endavaナレッジベースを使用するには、認証が必要でしたが、Q＆A Makerを使用する場合は必要ありません。 したがって、ベースをエクスポートする必要がありました。 データは、HTMLコードを含むさまざまな形式で保存されていたため、このコードをきれいにする必要がありました。



正規表現を使用してデータを消去しました。HTMLタグを削除し、タブと改行を追加しました。 コードスニペットは次のとおりです。

 //    (   —  ) result = System.Text.RegularExpressions.Regex.Replace(result, @"<( )*style([^>])*>", "<style>", System.Text.RegularExpressions.RegexOptions.IgnoreCase); result = System.Text.RegularExpressions.Regex.Replace(result, @"(<( )*(/)( )*style( )*>)", "</style>", System.Text.RegularExpressions.RegexOptions.IgnoreCase); result = System.Text.RegularExpressions.Regex.Replace(result, "(<style>).*(</style>)", string.Empty, System.Text.RegularExpressions.RegexOptions.IgnoreCase); //    <td>   result = System.Text.RegularExpressions.Regex.Replace(result, @"<( )*td([^>])*>", "\\t", //\t System.Text.RegularExpressions.RegexOptions.IgnoreCase);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

タブ文字が\ tではなく\\ tと書かれている理由を尋ねることができます。 答えは、\\ n文字の場合と同じです。 実際、Q＆A Makerは生のテキストデータの形式で応答を保存して返します。 使用されるtsvファイルには、キャリッジリターンまたは追加のタブ文字を含めることはできません。そうしないと、システムがそれを正しく処理できない場合があります。 すべてのチャネルのハンドラーは、文字\ tおよび\ nを正しく表示するため、応答をより適切にフォーマットできます。



重要な注意：Q＆A Makerは、Markdownマークアップを使用してデータを保存できますが、一部のチャネルではサポートされない可能性があることに注意してください スクリーンショットは、いくつかの改行\ nを示しています。



また、各回答にナレッジベースのメインページへのリンクを追加しました。 これらのページはプレーンテキストよりも見栄えがよく、メインコードから完全に削除した画像が含まれている場合があります。 ユーザーができるだけ快適になるように努めました。



適切な回答を選択すると、Q＆A Makerは質問と回答の両方のテキストを分析します。 したがって、回答も可能な限り詳細にする必要があります。

LUISのヒント

LUISの構成は非常に簡単です。 この例では、1つの意図と3つのエンティティのみが使用されます。



LUISは次のように機能します。

• ユーザーリクエスト：[開発]共有ポイントサイトにアクセスします[読み取り]。
• LUISはその意図（SharePointへのアクセス）を理解し、[読み取り]と[開発]の2つのエンティティを抽出します。

インテントを処理し、LUISダイアログクラスから特定の関数を呼び出すには、以下に示すように、インテントの名前を持つ属性で関数をマークするだけです。

 [LuisIntent("sp-access")] public virtual async Task ProcessSpAccessRequest(IDialogContext context, LuisResult luisResult) { var accessToken = await context.GetAccessToken( ConfigurationManager.AppSettings[ "ActiveDirectory.ResourceId"]); //,   — Graph API SpFormHandler formHandler = new SpFormHandler(); IFormDialog<SharepointModel> formDialog = formHandler.GetFormDialog(luisResult.Entities, accessToken); context.Call(formDialog, OnFormComplete); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

SharePointロボットプログラムとのやり取りははるかに線形であるため、LUISダイアログをフォームを介したダイアログに置き換えます。線形質問の場合は、作業がはるかに簡単になります。 SharePoint質問処理コードのほとんどは、SpFormHandlerフォームに関連しています。 これは、複数のダイアログを組み合わせるエレガントな方法です。 コードからわかるように、任意のオブジェクトをコンストラクターに渡すことができます。

 [Serializable] public class SpFormHandler { public IFormDialog<SharepointModel> GetFormDialog(IEnumerable<EntityRecommendation> entities, string token) { var spForm = new SharepointModel(); spForm.Token = token; foreach (EntityRecommendation entity in entities) { if (entity.Type == "sp-sitename" || entity.Type == "builtin.url") { spForm.SitenameOrUrl = entity.Entity; } if (entity.Type == "sp-accessright") { Enum.TryParse(entity.Entity, true, out AccessRights rights); spForm.AccessRights = rights; } } return new FormDialog<SharepointModel>(spForm, BuildForm, FormOptions.PromptInStart); } private IForm<SharepointModel> BuildForm() { // } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

LUISからのエンティティとトークンの両方が転送されます。 エンティティは、要求されたアクセスタイプと同様に、SharePointリソースのURLまたは名前を取得するために使用されます。 LUISには、URLなどの多くの組み込みエンティティが含まれています。 それらを使用することを強くお勧めします。それらはうまく機能し、時間の節約に役立ちます。



さまざまなダイアログの分岐、LUISダイアログ、フォームを使用したダイアログ、および解決するタスクを考慮した通常のダイアログの組み合わせは、完全に正当化された作業アプローチです。

結論と次のステップ

このプロジェクトのコードは3日間で書かれたコードの一部にすぎませんが、Azure Active Directoryを介した認証、電子メールを含むさまざまなチャネルを介したロボットプログラムとの相互作用、コグニティブサービスの使用などMicrosoft Graphを介したQ＆AメーカーとLUIS。



公開されたコードとドキュメントは、完全に機能するソリューションを形成します。 実際には、部分的なソリューションと完全なソリューションの両方を体験できます。 Microsoft Graphコンポーネントを使用するには、認証してトークンを取得する必要があります。 «», Azure Active Directory , . .



, .

著者について

, , - , , . , , . Microsoft, 20 . , , .