• 發行項

2016 年 11 月

第 31 卷，第 11 期

本文章是由機器翻譯。

Bot Framework - 使用 Microsoft Bot Framework 解決商務問題

由 Srikantan Sankaran

現今人們一切線上或電話，購買、 銷售、 銀行、 研究 — 要保持競爭力，企業經常需要發展他們的應用程式使用其服務的客戶提供的最佳體驗。這牽涉到隨時提供方便的各種自助式功能，並從任何地方存取資料，通常是來自共享的通道、 使用語音和訊息。這是一項挑戰，由於有各式各樣的應用程式必須考量，因為大部分的這些應用程式並非設計來處理今日所面臨的案例。要處理這些需求可能會需要牽涉到大量資源的多個平行開發專案。Microsoft Bot 架構，不過，可以有效簡化。

Microsoft Bot 架構提供一種平台來建置應用程式的組織 — bot —，取用者可以與互動，輕鬆地 conversationally，透過語音或文字，只要方便。而不需要任何額外的開發作業，這些 bot 可以順暢地存取來自多個等社交管道、 Skype、 Slack、 Facebook Messenger 等等。它們可以讓使用者存取其所有資料彙總不同特定業務 (LOB) 應用程式中，使用 Azure 邏輯應用程式或 Microsoft 流程等技術。這些技術現在隨附的所有重要的商業應用程式在市場上的連接器。Azure 搜尋服務提供功能強大的 Lucene 引擎，可以用來搜尋資料結構化和非結構化彈性的方式。客戶可以透過自然語言交談 bot 與互動和 Azure 語言了解智慧型服務 (LUIS) 可以解譯這些回應下游應用程式的交談。

在這篇文章和下一步，我將討論的案例說明組織現今面臨的挑戰，如何藉由運用 Microsoft Bot 架構建立方案。當您實作涵蓋在此案例的解決方案，您會發現下列參考很有用︰

  • 使用 Azure 搜尋服務的 Azure Blob 儲存體中的文件編製索引 (bit.ly/2d4yr8s)
  • 啟用和停用變更追蹤 (SQL Server) (bit.ly/2d226wt)

建立方案

Form 這份文件背景的商務案例牽涉到保險公司提供不同類型的保險原則涵蓋車輛、 首頁、 出差以及取用者的健全狀況。取用者可以自行註冊以使用使用者的 Microsoft 認證的 Web 應用程式，並送出他們的保險原則要求。商務程序工作流程會負責在 Dynamics CRM Online 中，設定檔資訊擷取，，然後將儲存在 Office 365 SharePoint 的保單應用程式註冊的使用者。在組織內的內部工作流程處理程序一段時間，最後導致其核准，並產生原則文件儲存在 Office 365 中變更原則要求的狀態。這些步驟已超出本文，而是著重在系統中，會擷取資訊時，開始進行中的下游的整合案例和與取用者共用的後續更新和狀態的範圍。[圖 1 說明此案例的解決方案的架構。

方案的架構
[圖 1 解決方案架構

Dynamics CRM Online，建立或更新 Office 365 中的原則要求或上傳原則文件中的 Office 365 觸發程序事件使用 Microsoft 流程實作的商務程序流程中取用者建立連絡人的設定檔。這些程序，透過結構化的資料同步處理至 Azure SQL 資料庫資料表和非結構化的資料，例如原則文件，會複寫至 Azure Blob 儲存體。Azure 搜尋服務會定期尋資料，並保持最新的查詢。Bot 應用程式會部署成透過 Microsoft Bot 架構連接器服務發行的 Azure Web 應用程式。連接器服務，透過 bot 應用程式會連線至 Skype 通道，來擷取要求的狀態及其保單，取用者存取下載的發行的原則文件、 排程站台檢查造訪，依此類推。取用者登入他們向保險原則套用時的 Microsoft 帳戶。他們可以使用 Skype 用戶端或語音命令的其中一個訊息與程式互動。Bot 應用程式整合與 LUIS 服務，可在 Microsoft 認知服務，來解譯的取用者對話，並在 Azure 搜尋服務上執行查詢的數個服務的其中一個。

與此內容中，以下是為了建立此方案有什麼︰

  1. 作者商務程序會傳送同步處理，並合併來自不同 LOB 應用程式使用 Microsoft 流程。
  2. 設定 Azure 搜尋服務索引合併的資料，讓它可以從 bot 查詢。
  3. 設定 LUIS 服務，並建立並定型的模型解譯從 bot 使用者交談。
  4. 建立 bot 應用程式使用 Microsoft Bot 架構，並使用從 Skype。

我將說明這篇文章中的前兩個步驟和其餘的兩個下一次。

保單要求同步處理流程

在此範例中，原則要求會儲存在 Office 365 中的自訂清單。插入或更新在核准程序，叫用 Azure SQL Database 中的預存程序的原則要求時，會觸發繫結至這份清單 Microsoft 流程程序。插入和更新案例，被撰寫不同的 Microsoft 流程處理序。

[圖 2 說明 Microsoft 流程設計工具如何讓您選取在建立或更新項目或檔案時，Office 365 中的 SharePoint 清單上的觸發程序事件。

Microsoft 流程觸發程序事件
[圖 2 的 Microsoft 流程觸發程序事件

[圖 3 顯示原則要求插入這份清單時，會觸發流程。Microsoft 流程設計工具讀取預存程序的中繼資料，並根據其輸入參數的表單會自動顯示。將游標放在表單的輸入欄位上會啟動在右側顯示卡 [圖 3, ，顯示屬性從先前的活動，您可以選擇從對應至預存程序的輸入參數。

保單要求同步處理流程
[圖 3 保單要求同步處理流程

我要建立用於同步處理更新，以確保原則核准要求的狀態會定期更新 Office 365 從目標 Azure SQL 資料庫的其他流程。

請注意，每個連接器，在此案例中使用的連接，必須先設定和使用者帳戶具有足夠的權限從 Office 365 SharePoint 網站中的自訂清單讀取資料。同樣地，Azure SQL Database 連接器需要使用者認證來驗證資料庫。

我可以測試我所撰寫的自訂清單中插入一筆記錄的流程。資料應該複寫到 Azure SQL 資料庫。

原則文件同步處理流程

保單要求一經核准 （在完成後端程序，已超出本文的討論範圍），會產生原則文件，並上傳至 Office 365 SharePoint 的文件庫。Microsoft 流程然後將該原則文件複寫至 Azure Blob 儲存體。Azure 儲存體中插入新的文件，並取代原始文件，如果更新 Office 365 中，被撰寫不同的 Microsoft 流程處理序。文件包含某些索引鍵，像是一種載具，正在 insured，例如註冊數目。在本文中，稍後我將使用 Azure 搜尋服務來執行全文檢索搜尋，根據特定關鍵字的文件內。[圖 4 顯示實作，以同步處理 Office 365 中的第一次上傳的文件的 Microsoft 流程。

原則文件同步處理流程
[圖 4 原則文件同步處理流程

我可以將任何文件上傳至 SharePoint 文件庫來測試流程。文件應該複寫到在流程中設定 Azure 儲存體容器。

客戶設定檔資料同步處理

當客戶一開始會向保險的提供者時，Dynamics CRM Online 中建立連絡人。Microsoft 流程則會觸發挑選連絡人，並將它插入到 Azure SQL Database 使用 Dynamics CRM Online 連接器。[圖 5 示範如何實作此程序。

連絡人的資料流程
[圖 5 連絡資料流程

請注意，您必須使用有權連線到組織和安全性角色，可讓資料的存取權的使用者認證，首先，設定 Dynamics CRM Online 的連線。此外，您應該啟用 Dynamics CRM Online 「 插入事件 」 的位置擷取，在此情況下，這是 [連絡人] 資料表中的資料表上的變更追蹤。

 Microsoft 流程可讓您檢視程序執行，要求和回應屬於每個活動的相關資訊的結果。

[圖 6 顯示連絡人資料同步處理程序的結果。選取左側的活動會卡片開啟輸入和輸出內容的詳細資料，右側所示。

資料流程執行
[圖 6 資料流程執行

若要測試此流程，我可以從 CRM Online 入口網站中建立連絡人。連絡人的資料應該複寫到 Azure SQL Database。

稍後，我將使用連絡人的資料來識別使用者登入 Skype bot 和擷取使用者的保單應用程式要求的核准狀態。我也會使用排程站台檢查，請瀏覽從 bot 的連絡資訊。

準備搜尋的資料來源

已實作合併所有不同 LOB 應用程式，從資料的程序，但是我需要先完成某些步驟才能我使用 Azure 搜尋服務中的資料。

啟用 Azure SQL 資料庫中的變更追蹤︰ Azure 搜尋服務會使用 Azure SQL Database 的內建索引子來編目資料，建立索引。在每次建置使 Azure 搜尋服務不會執行重新產生索引的資料庫和資料表啟用變更追蹤的需求︰

ALTER DATABASE PolicyInfoDB SET CHANGE_TRACKING = ON
(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);
ALTER TABLE CrmCustomerData ENABLE CHANGE_TRACKING
WITH (TRACK_COLUMNS_UPDATED = OFF);
ALTER TABLE PolicyRequests ENABLE CHANGE_TRACKING
WITH (TRACK_COLUMNS_UPDATED = OFF);

您也可以追蹤刪除的資料庫資料表中的記錄和 Azure 儲存體中的文件編製索引的程序，透過組態期間。

設定 Azure 搜尋服務編製索引的 PolicyRequests 和 CrmCustomerData 資料表︰ 使用 Azure 入口網站為您的搜尋，建立實體，然後選取 [匯入資料，從 Azure SQL Database。精靈會引導您完成程序的連接至資料庫，建立搜尋] 中的資料來源讀取中繼資料的資料進行取樣，並選取所需的屬性，若要使用，並以索引為結束重新整理排程。您可以設定個別索引的每個資料表。[圖 7 顯示資料庫的搜尋索引組態頁面。

設定 Azure 搜尋索引的資料庫資料表
[圖 7 設定 Azure 搜尋索引的資料庫資料表

Azure 搜尋服務組態] 頁面偵測編製索引的資料庫資料表啟用變更追蹤。我已經設定編製索引的頻率為每小時。其他選項包括一次，每日和自訂。

一旦設定索引，Azure 搜尋服務會立即觸發資料來源上的索引作業。您可以檢查每個索引檢視的索引已填入的記錄數目的狀態。

Azure 搜尋服務設定] 刀鋒視窗提供搜尋檔案總管，可讓您輕鬆地設定搜尋參數、 檢視結果，並確認組態。

設定 Azure 搜尋索引的原則文件︰ 設定搜尋和編製索引的 Azure 儲存體 blob 的 Azure 搜尋服務，就像剛才所描述的資料庫設定雖然我應該註明，這項功能處於預覽中這一次。

稍後在本文中我要使用 Azure 搜尋服務來查詢，根據該原則文件產生的日期和關鍵字，像是車輛註冊數字的文件，均會儲存文件內。Azure 搜尋服務支援 Apache Lucene 查詢語言，提供進階查詢功能。

請注意，blob 儲存體屬性，metadata_storage_last_modified，這是日期時間欄位。在 Azure 搜尋服務，該索引子會符合它，其對應的資料型別是 Edm.DateTimeOffset，這不是可搜尋。我想要能夠擷取簽發的年為基礎的原則文件，因為這必須是可查詢的欄位。

若要解決此問題，我無法變更索引中的資料類型為 Edm.String，這是可搜尋。不過，因為索引子會使用此欄位做為旗標來判斷自從上次編製索引作業以及是否應該索引一次是否已變更的檔案，我會風險中斷的資料型別變更該功能。

相反地，我可以將補充欄位加入要儲存使用 Edm.String 資料類型的相同值的索引。不過，這表示我無法使用 Azure 入口網站 UX 設定索引，因為它並不允許自訂將欄位從 Azure 儲存體對應至索引的邏輯。

若要解決這個問題，我將使用 Postman 用戶端 (getpostman.com/apps)，免費可下載的工具，來叫用 Azure 搜尋服務 REST Api，並完成下列工作︰

  • 建立資料來源︰ 這可以從 Azure 入口網站或使用 Postman 用戶端從 REST API 完成。
  • 設定索引︰ 因為我在索引中手動定義欄位，我可以提供比預設搜尋設定項目更加易懂易記的名稱。"Filepath"欄位將會設定為在索引中的索引鍵欄位。請注意，如上次修改日期，根據 Edm.DateTimeOffset，Edm.String 另一個有兩個預留位置欄位︰
{
  "name" : "policydocuments-index",
    "fields": [
      { "name": "filepath", "type": "Edm.String", "key": true,
        "searchable": true },
      { "name": "content", "type": "Edm.String", "searchable": true },
      { "name": "filesize", "type": "Edm.String", "searchable": true },
      { "name": "author", "type": "Edm.String", "searchable": true },
      { "name": "filename", "type": "Edm.String", "searchable": true },
      { "name": "lastmoddate", "type": "Edm.String", "searchable": true },
      { "name": "contenttype", "type": "Edm.String", "searchable": true },
      { "name": "modifieddate", "type": "Edm.DateTimeOffset",
        "searchable": false }
      ]
}
  • 建立索引子，並將欄位對應︰  此步驟中建立索引子、 定義索引排程和 Azure 儲存體中的欄位對應中的上一個步驟中所定義的索引︰
{
  "name" : "policydocuments-indexer",
  "dataSourceName" : "policiesrepodatasource",
  "targetIndexName" : "policydocuments-index",
  "schedule" : { "interval" : "PT2H" },
    "fieldMappings" : [
           { "sourceFieldName" : "metadata_storage_name",
             "targetFieldName" : "filename" },
     { "sourceFieldName" : "metadata_storage_size",
       "targetFieldName" : "filesize" },
     { "sourceFieldName" : "metadata_author", "targetFieldName" : "author" },
     { "sourceFieldNambe" : "metadata_storage_last_modified",
       "targetFieldName" :
       "modifieddate" },
     { "sourceFieldName" : "metadata_storage_last_modified",
       "targetFieldName" :
       "lastmoddate" },
     { "sourceFieldName" : "metadata_content_type",
       "targetFieldName" : "contenttype" },
     { "sourceFieldName" : "metadata_storage_path",
       "targetFieldName" : "filepath" }
  ],
  "parameters" : { "base64EncodeKeys": true }
}

現在我可以在入口網站使用 Azure 搜尋服務總管] 中，確認確實已經建立索引的文件，並如預期般對應屬性值。

實作此案例中的軟體必要條件

除了所需的 Azure 訂閱來實作所述的案例，您還需要下列開發工具和其他軟體︰

  • SQL Management Studio for SQL Server 2014 或更新版本來建立並連接到 Azure SQL Database。
  • Dynamics CRM Online 訂閱，可以連線到組織的連絡人會建立，並擁有必要的安全性角色來讀取 [連絡人] 資料表的使用者帳戶。此函式及其"上建立 「 觸發程序的資料表上，就應該啟用變更追蹤。
  • 存取 Office 365 SharePoint 網站和使用者帳戶具有該網站的 「 參與 」 權限。
  • 工作帳戶登入，並撰寫的資料同步處理使用 Microsoft 流程的商務程序。開始使用它在 flow.microsoft.com。
  • 若要使用 LUIS 服務，使用工作帳戶 （或 Microsoft 帳戶） 在註冊 luis.ai。在這篇文章的第 2 部分，我將使用此服務模型在本文中所述的交談。

注意: Microsoft 流程是在撰寫本文時，預覽並無法在此時處理的例外狀況、 實作重試邏輯或處理程式碼後置處理流程。顯示在此案例中的所有處理程序可以使用 Azure 邏輯應用程式，另外，這除了提供 Microsoft 流程的所有功能支援其他功能，例如例外狀況處理、 管理流程，以及其他使用程式碼編輯器來撰寫。

執行案例

執行此案例中端對端需要 Web 應用程式，可讓取用者註冊使用使用者的 Microsoft 認證和送出的保險原則要求。此應用程式接著會建立連絡人在 Dynamics CRM Online，會產生連絡人識別碼和使用 Office 365 中的清單中建立的保險原則要求中的這個值。不過，因為這類應用程式超出本文的範圍，您必須以手動方式和個別執行這些步驟。

登入 Dynamics CRM Online 入口網站，並建立連絡人。因為這些會需要稍後使用 bot 時，請確定您的客戶，擷取類似行動電話號碼與 Microsoft 帳戶的詳細資料。Microsoft 流程繫結至 [連絡人] 資料表會被觸發，叫用 Azure SQL Database 中的預存程序，然後 CrmCustomerdata 資料表中插入客戶記錄。記下 [下一步資料表中儲存的客戶 id 值。

在 Office 365 SharePoint 自訂清單中，手動建立的保險原則要求。請確定的客戶要求中擷取此客戶 Dynamics CRM Online 中產生的 ID。[圖 8 顯示中，擷取要求的 SharePoint 清單。儲存記錄時，或在之後的核准程序期間更新時，將會觸發繫結至這份清單的 Microsoft 流程程序。請確定原則要求會複寫到 Azure SQL database PolicyRequests 資料表。

在清單中的 Office 365 的保險原則要求
[圖 8 保險原則要求在 Office 365 清單

接下來，建立 PDF 文件範例，並確定它們包含要在文件搜尋期間使用車輛註冊或識別數字。將這些文件上傳至 SharePoint 文件庫繫結至文件同步處理的 Microsoft 流程程序。請確認這些文件會複寫到在流程中設定的 Azure 儲存體帳戶。

手動執行索引子，以確保資料同步處理的上一個步驟中的索引，並可供搜尋。啟動 Azure 搜尋總管和查詢的每個資料表和您已上傳，並確定它們在搜尋結果中傳回的原則文件中的記錄。

自然語言 Utterances Bot 應用程式中

Skype 或其他通道上的 bot 使用者可以輸入在自然語言樣式，然後解譯 bot，要求識別使用者的意圖和實體，並查詢 Azure 搜尋服務，並擷取結果。目前的狀況，應該涵蓋所有可能的方式及其使用者無法與它互動和提問狀態的保單請求，或從過去幾年其核准的原則文件或查詢原則文件下載 bot。以下是一些 utterances bot 應該能夠解譯的範例︰

  • 我的保險原則要求的狀態為何？
  • 我的原則要求 # VehPol0101 核准嗎？
  • 有我的保單要求 # VehPol0101 的更新嗎？
  • 顯示原則文件。
  • 取得原則文件。
  • 取得我去年的原則文件的車輛 # KA 02A 8534。
  • 顯示工具的原則文件 # KA 02A 8534 2014年中發出。
  • 可以排程站台檢查，請瀏覽星期二下週的車輛 # KA 02A 8534 嗎？

我將在下一篇文章中建置電腦控制機甲自然語言支援與應用程式。若要這樣做，我要建立將會註冊這些自然語言 utterances LUIS 模型中、 訓練以識別使用者意圖，並判斷支援的參數或要查詢 Azure 搜尋服務的實體。

成品可供下載

用來實作此案例中的下列成品可供下載，從 GitHub 儲存機制在 bit.ly/2cOfANh:

  • Azure SQL 資料庫資料表建立指令碼 CrmCustomer 與 PolicyRequests 資料表。
  • 使用上述的資料庫資料表中的預存程序。
  • 儲存原則的要求，Office 365 清單的結構描述，而上傳的原則文件的文件庫的螢幕擷取畫面。

我將上傳下一步的文件，以相同的位置相關的其他成品。

總結

組織立即處理各種需要一起運作來解決其商務問題的應用程式。這通常是一項挑戰，因為資訊分散於企業中，因此很難合併，讓取用者顯示。Microsoft 流程，可將資訊從合併整個企業和 Azure 搜尋服務提供彈性和豐富的查詢引擎來存取資料。沒有單一的服務介面，來呈現所有資訊，縮短時間，以建置並部署用戶端應用程式整合。 

在這篇文章系列的第 2 部分，我將使用從消費者應用程式，例如 bot Skype 的 Azure 搜尋服務所公開的資訊。若要這樣做，我要建立 LUIS 解譯 bot 使用者訊息，並將其轉換為結構化要求中，Azure 搜尋服務的模型。

Srikantan Sankaran 是印度居住在 Bangaluru DX 小組的技術推廣者。 他會使用許多 Isv 在印度，並且可幫助他們設計和部署他們在 Microsoft Azure 上的解決方案。與他連絡 sansri@microsoft.com。

感謝下列 Microsoft 技術專家來檢閱這份文件︰ Sandeep Alur 和 Paul Bouwer
Sandeep Alur 是導致推廣 DX 印度的並且根據 Bangalore 中。

Paul Bouwer 技術推廣與開發小組的資深 SDE，而且以布里斯本。