2017年12月30日 星期六

使用C#開發LineBot(17) – 使用新版Line Login v2.1

Line在去年以OAuth規格推出了Line Login機制,試圖與各家大廠一起角逐身分驗證與單一登入SSO(Single-Sign-On)的一席之地,相關的概念與使用方式我們在06年底曾經介紹過

而關於SSO與OAuth相關的技術與概念,我們也曾經在這邊有過分享。

今年(2017)底,Line又更新了Line Login相關的API,來到了v2以及v2.1,在這一版更新當中,Line Login可以跟Line bot做連結和整合,以便於讓你得知用戶更多的訊息並與用戶互動。除了功能比較多之外,還有一個你不得不升級的原因,因為舊版v1的API,依照公告,將於2018年三月底停用:

https://developers.line.me/en/news/2017/12/05/

因此我們的LineBotSDK也更著做了升級,我們後續將分幾篇貼文來介紹新版的Line Login API,這篇我們先來看基本SSO的部分,首先,由於申請畫面跟舊版有些許不同,我們也一併整理一下。

申請新版Line Login服務時,請先從 https://developers.line.me/en/ 的官方管理站台登入,登入後請點選主畫面的『Start Using Line Login』:

接著出現底下畫面,請依序輸入相關資料,其實本質上跟我們介紹v1時候的做法差不多,由於我們待會要做的是Web Site的SSO,下圖畫面請務必勾選Use Web:

輸入完成後按下 Confirm,最後會出現底下畫面,基本上一個服務就建立完成了。但相關資訊我們還要接著輸入,因此,待會請點選底下畫面中我們新建立好的這個Line Login服務圖示 :

進入後你會看到底下畫面:

其中大部分的資訊都是我們剛才自己輸入的,少部分是系統產生的,其中就包含了上圖畫面中標示A、B的部分,如果你熟悉OAuth flow就應該不陌生,上圖中的ID與secret就是我們要做SSO時的client_id與client_secret,不過新版Line Login底下多了一個Bot linked…的部分(標示C)我們後面再來談。

請留意畫面左上方有一個App Settings:

點選後會出現底下畫面:

我們待會按下上圖右方的筆,來修改這個callback URL。在此之前,我們當然得先產生出一個Callback URL才行。

如果你熟悉SSO與OAuth相關的技術與概念(不熟悉的話請先看這邊),你就會知道要與Line Login做整合,你的網站必須至少有兩個頁面,一個頁面是導入Line Login用戶登入的引導頁,另一個頁面則是Line Login將用戶導回我們網站時,接收Line伺服器所傳回的code的Callback頁面,上圖中所需要輸入的callback URL指的就是該頁面的位置。

因此,我們待會要透過Visual Studio以asp.net建立一個web site,其中包含兩個頁面index.html與callback.aspx,我們先透過VS建立一個空的網站,並且在網站中加上index.html以及callback.aspx這兩個頁面。

建立好之後,我們在index.html頁面中,撰寫如下的程式碼,這段程式碼的目的就是將用戶引導至Line Login的登入驗證畫面:

請留意6-12行,是組出引導入Line Login登入畫面的URL,其中與v1版本相比,比較不同的除了endpoint(7行)之外,最主要的是scope的支援範圍變廣了,寫法也不同,變成『openid profile』,這符合OAuth2的最新標準規範。

而其中第10行的localhost:58155我們之所以知道port no,當然是因為我們已經用VS透過IIS Express運行後的結果,這個callback.aspx頁面待會就是在用戶輸入完帳密,要被Line伺服器導回我們的網站時的code接收頁面,用來接收將會傳回來的code。

別忘了,我們也要同時把這個頁面的網址填入剛才在申請Line Login時的AppSettings項目下的Callback URL:

這樣Line伺服器才知道用戶輸入帳密驗證身分成功之後,要導回哪個頁面。

我們在該頁面中,也需要撰寫程式碼來接收將會從網址列傳回來的code參數。為了達成此目的,請將專案引入(或升級)至LineBotSDK 0.6.4-beta3 以上版本:

然後可以接著在callback.aspx頁面的Page_Load方法中,撰寫底下程式碼:

請留意我們用到的isRock.LineLoginV21.Utility.GetTokenFromCode()方法,必須在升級到LineBotSDK 0.6.4-beta3版本以上才有。

在上面的程式碼當中,我們首先在第4行抓取Line伺服器在callback回來時應當回帶入的URL QueryString參數code,如果該參數不存在,則顯示錯誤(7,8行)。

抓取到之後,我們可以透過GetTokenFromCode()方法取得token,注意第14,15,16三行分別要傳入你剛才在申請Line Login時候取得的Channel ID, Channel Secret,以及你自己設定的callback url,如果一切正確,運行後會得到一個回傳的token物件。

該物件中會有一個access_token屬性,透過該屬性,你可以輕鬆的以GetUserProfile()方法取得用戶身分資訊(第21行),我們在第22行將其顯示出來。

網站撰寫好之後,我們可以試著運行看看,首先運行index.html,按下底下的Button:

它會觸發我們在index.html頁面中所撰寫的javascript,將網頁引導至Line Login的登入頁面:

如果用戶不曾登入過,會出現上面這樣的頁面,讓用戶輸入他自己的Line帳號密碼,請留意該頁面並非我們做的網頁,而是Line自己做的登入頁,因此用戶的帳密我們無法得知,也能確保資訊安全。

倘若用戶曾經登入過,新版API會出現底下畫面,讓用戶選擇是否要切換身分:

用戶可以選擇上圖標示A的登入鈕,以該帳號直接登入(無須再次輸入帳密),或是點選上圖標示B的位置,以其他帳號登入。

用戶登入之後,將會看到底下這個畫面,圖中標示A、B的位置,顯示的是您剛才申請的Line Login服務的名稱、與說明:

而上圖標示C的部分很重要,這是舊版沒有的,也就是存取範圍(scope)的部分,由於先前我們指定的scopt為『profile openid』,因此會帶出上面標示C所顯示的這兩項『個人資料、用戶識別碼』,倘若用戶同意我們的網站可以存取該資訊,按下『同意』鈕之後,網站就會被Line伺服器導回我們撰寫好的callback.aspx頁面,並且跟著頁面傳來一個非常重要的code:

請留意導回的網址,你會發現網址列有傳給我們的code與state,跟Line Notify一樣,state是我們原先在index.html頁面中自行傳入的參數,它會被原封不動的回傳回來,便於我們做身分或交易識別用,而我們的主角是Line傳給我們的網址列參數code。

請參考我們剛才看到的callback.aspx中的程式碼,透過這個code,我們搭配client_id, client_secret與callback url作為參數,就可以用GetTokenFromCode()這個method取得我們想要的access_token(下圖標示A的位置):

取得access_token後,我們要抓取用戶身分也很容易了,可以參考上圖標示B的位置,我們傳入access_token,即可用GetUserProfile()方法來取得用戶的個人資料囉。

至此,我們的網站想要透過Line Login的方式,來進行SSO(Single-Sign-On,單一登入)也就不是什麼問題了。

後面我們再繼續談Line Login的相關功能與應用。

------------------
相關課程:http://www.studyhost.tw/NewCourses/LineBot
電子書:http://studyhost.blogspot.tw/2017/12/line-bot.html
LineBotSDK:https://www.nuget.org/packages/LineBotSDK
如果需要即時取得更多相關訊息,可按這裡加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

2017年12月28日 星期四

真正的需求訪談,是談價值、而非只談功能。

前幾天聊到價值(Value),給我點時間,讓我細說從頭。

這幾年做案子下來,發現大多數的SA/PM/PO在需求訪談時跟客戶談功能很在行,談價值卻很吃力。你可能覺得疑惑,需求訪談不就是談需求嗎? 為何會扯到價值?

回答這問題前,先幫我想想,一個軟體的需求是為了什麼? 沒錯,需求是為了實現價值,功能則是需求的具體表現。

舉例來說,一個電子商務網站可以有各式各樣的功能,但核心價值要嘛是銷售、要嘛是服務,OK,這個你一定懂。

但大多數的SA或技術人員,受過了多年的技術訓練,談功能很拿手,各種工具、圖表、道具順手捻來毫不手軟,客戶看的眼花撩亂但也很開心,因為看到這麼多功能(工項)被列出來,腦袋裡自然而然幻想著,當這些功能實現,需求『自然』就滿足了,而需求被滿足,價值『自然』就實現了。

但真的是這樣嗎? 做那麼多年的軟體之後,你肯定知道,不是的。擁有一堆功能跟這個 軟體/網站 能不能滿足客戶需求乃至於實現某種價值,根本可以是兩回事。

然而很多客戶(和廠商)死不信邪,以為價值沒實現是因為功能不夠多(天殺的!!!這是我碰過最可怕的思維...)

然後試圖用無止盡的增加功能來滿足可能根本不存在的想像出的需求,然後在心裡期望價值能發生。(天佑PM/天佑SA/天佑客戶...)

每當我們要求跟客戶談需求時,試圖把焦點拉回價值(而不是一直停留在談功能上),一開始客戶都很不習慣,因為這仿佛很抽象,廠商自己也擔心,因為哪有一個網站可以保證上線後就財源滾滾而來? 就好比你賣一個ERP軟體要保障客戶使用後利潤增加一成,這...似乎有點難?

對,但就是因為這很難,所以久而久之,我們把價值放一邊,銷售時就拼命暗示客戶你有某種需求等著被滿足,而要滿足這些需求,則要做出這些功能,只要你買了這些功能,一切就搞定了。

然後,最初期待實現的價值呢? 恩...沒實現嗎? 不要緊,下一套軟體我們再來談...


------------------
相關課程:http://www.studyhost.tw/NewCourses/ALM
電子書:http://studyhost.blogspot.tw/2014/10/blog-post_1.html

如果需要即時取得更多相關訊息,可按這裡加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

2017年12月27日 星期三

MVP(最小可行性產品)的重點不是雛形、不是迭代、不是探索需求、而是實現價值!!!

最近網路上有幾篇文章,這篇文章中談到的MVP(最小可行性產品)那個圖,我在上課時也常用,也常被問到一樣的問題,而我的回答也總是很簡單...

在下圖中第一和第二個路線的例子裡,我們從來都不是說要做『一台汽車(太具體了)』,而是說要做一個運輸或交通工具(相對抽象),因為一開始你根本不會知道具體需求是甚麼,下圖中的『汽車』只是運輸器具的一種呈現方式,但根本不是一開始的目標...

(如果你做過產品,就會知道,開始時需求根本不可能是具體的,更不用說有什麼『清楚的規格』這種事情了,再清楚的規格,其實都是你自己的想像,只要碰到市場都會幻滅)

(講到這裡你應該知道我認為下圖是對是錯了,但重點在於,這些根本不是重點!!!)

這幾篇文章討論到最小可行性產品這個議題時,都少了一個我們做軟體專案時非常重要的概念,就是:『MVP的每個迭代(或交付)都必須要對用戶產生出價值(Value)』。

因此我在談MVP時的重點,從來都不是雛形(prototype)、也不是邊做邊改去符合(或探索)用戶需求,甚至不是其實我認為也很重要的快速反饋,而是『時刻產生價值』。

沒有帶來價值的產出,不管是滑板、腳踏車還是機車、汽車,對我(客戶)來說,都叫做『浪費』。

當客戶的預算有限、需求常常變、一切彷彿都捉摸不定時,你很有可能永遠都不知道客戶(或市場)到底最終要的是戰車還是超跑,但,不管你產出的是什麼,只要能在當下立即為客戶帶來『價值』,那就是好東西,否則不管你做出什麼曠世巨作或太空梭,只要沒能帶給客戶價值,我們都稱之為『浪費』。

敏捷專案管理中所追求的,是每一個迭代、每一次交付都要能為客戶帶來『價值(Value)』。這很不容易,但這才是我在乎的重點...

後記:關於價值,為何我們那麼看重? 後續我又做了一些補充,請參考這裡

------------------
相關課程:http://www.studyhost.tw/NewCourses/ALM
電子書:http://studyhost.blogspot.tw/2014/10/blog-post_1.html
如果需要即時取得更多相關訊息,可按這裡加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

2017年12月26日 星期二

[電子書] Line Bot 對談機器人 & 人工智慧辨識 開發實戰

我猜,這應該是第一本跟Line bot (Line Messanging API)開發有關的電子書了吧。

[購買位置]

>>>>>>>電子書特色

1.全彩
2.具有超連結(在章節、圖片、引用網址)
3.圖片可放大檢視
4.方便檢索、方便筆記或塗鴉、不傷本體
5.購買後終身免費持續更新

>>>>>>>序言

2017年,今年一整年可以說是開發人員的AI元年,從2016開始,各種人工智能、bot的開發工具與套件紛紛出籠,各大廠商像是深怕自己被人遺忘一般,把手上各種放在實驗室中已久的人工智慧服務、套件、APIs端上檯面。

而IM則趁勢搭上這股風潮,台灣常用的Line、FaceBook Messanger、中國大陸的WeChat、標榜著自由開放的Telegram…都紛紛推出bot開發工具與框架,讓這個市場突然之間熱鬧了起來。

早在2013年初,在坊間這些AI工具和服務尚未出現之前,筆者就有幸因為專案的關係,接觸到了自然語言對談機制與bot開發相關領域,也因此,對最近這一陣子市場上出現的各種服務與應用相對熟悉、同時也非常感興趣。

身為微軟MVP,剛好也比較有機會接觸到早期釋出的一些資源,例如Cognitive Services,其中包含了人臉辨識、語意分析、圖像辨識、語音辨識…等多項功能。

因為工作上的需要,綜合這些技術,搭配上台灣相當普及的Line通訊軟體,2017年我們建構出了許多Linebot相關應用。同時間也應邀舉辦了多次的教育訓練課程,介紹如何開發Linebot對談機器人,並且與企業各種應用整合在一起。

許多應用本身就非常有趣,用戶的反饋也讓我們感到相當興奮。而這些第一手經驗,我們希望能盡快的整理出來,更多的分享給對這個領域有興趣的技術人員。

因此,你看到了這本電子書。

我們期望,透過這小小的經驗分享,讓對於自然語言對談實作與應用有興趣的朋友,可以快速的入門上手,並且用最短的時間作出一隻可以分享給你的親朋好友的Linebot,不只是為了趕上時代的潮流,也是滿足了身為開發人員從小對智能助理的期待與幻想。

>>>>>>>本書相關議題:

  • Line bot 文字、貼圖、圖片、Template Message…等訊息發送與回覆
  • Line bot WebHook設計
  • Line Login SSO(Single-Sign-On)整合
  • Line Notify 免費訊息發送
  • Cognitive Servies圖像、人臉、文字識別、LUIS語意分析、QnA Maker整合
  • Chat bot連續對話的設計

>>>>>>>閱讀須知

  • 此版本為搶鮮預覽版,後續會持續更新,但也可能調高價格!(越早買越便宜)
  • 更新後,先前購買的讀者依舊可以免費持續下載最新版本,最近更新日期2017/12/28, 約150頁 )

>>>>>>>預定章節:

[購買位置]

2017年12月23日 星期六

使用C#開發LineBot(16) – 讓 WebHook 開發更輕鬆

從我們釋出第一版的LineBotSDK開始,套件的建立最主要的精神就只有一個,讓我們家的.NET開發人員,能夠用更簡單、輕鬆、便利的方式來開發Linebot。

在這個最主要的目標之下,我們再盡可能地兼顧開發自由度、以及開發的架構、可維護性、與持續更新和相容性…等議題。

也因此,在最近撰寫了數不清的line bot和蒐集了一些用戶實際的反饋之外,我覺得可以將整個LineBot WebHook的開發繼續簡化,讓有興趣進入這個領域的初階開發人員,能夠更輕鬆沒有負擔的踏入開發。

因此,我們從0.6.4-beta1這個版本開始,加入了LineWebHookControllerBase這個類別,讓開發人員可以在幾行的程式碼內完成一個Line bot WebHook的設計。

像是底下這樣:

你會發現,我們把原本的APIController換成了LineWebHookControllerBase(第10行),這會讓開發人員可以少寫很多程式碼,例如抓取http post data後Parins並轉換JSON成strong type物件的工作(白話:取得用戶傳給Line bot的message),就由我們的LineWebHookControllerBase這個類別代勞了,你只需要透過20行的this.ReceivedMessage即可抓取到需要的物件。

同樣的,如果要push或reply,也可以透過像是this.PushMessage或this.ReplyMessage這樣的Method來完成(像是第22行)。

你大概也已經發現,ChannelAccessToken的部分我們可以在第18行透過this.ChannelAccessToken這個屬性設定一次即可。甚至你所幸乾脆不撰寫在程式碼裡面也行,LineWebHookControllerBase會自動抓取Web.COnfig / AppSettings 中 ChannelAccessToken這個Key的Value(如果有的話),如此一來,開發人員就更無須特別撰寫相關的code了。

整體來說,應該降低了不少開發難度。

如果你從來沒有寫過任何Line Bot WebHook,可以從底下介紹開始。

首先,請先開啟VS2017/2015,接著建立一個空的aps.net web專案:

.net版本建議 4.5.2以上,底下畫面記得務必選擇Empty與WebAPI:

建立好專案之後,請先在專案上加入Nuget,請務必選用LineBotSDK 0.6.4 beta 1以上版本:

完成後,你就可以在Controller資料夾中,按下滑鼠右鍵,新增一個WebAPI Controller:

在底下畫面中請選擇Web API 2 Controller – Empty:

命名時請務必保留Controller字尾:

完成後,請把VS自動幫我們產生的ApiController換掉,改成 isRock.LineBot.LineWebHookControllerBase:

並且在其中加上底下這樣的程式碼,他包含了抓取用戶傳來的訊息以及做基本的Echo惠應,一個能回應用戶的最基本的Line bot WebHook就完成囉:


完成後,你只需將該WebAPI 網站發布到網際網路上可連結的位置,並取得其URL(endpoint,例如本例應該是 https://你的domain/api/SimpleWebHook )後設定在bot的後台,即可讓bot生效囉:

更完整的範例程式碼在:
https://github.com/isdaviddong/SimpleLineWebHook

------------------
相關課程:http://www.studyhost.tw/NewCourses/LineBot
電子書:http://studyhost.blogspot.tw/2017/12/line-bot.html
LineBotSDK:https://www.nuget.org/packages/LineBotSDK

如果需要即時取得更多相關訊息,可按這裡加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

2017年12月17日 星期日

使用C#開發LineBot(15) – 當Linebot與我們同在一起, 談群組(聊天室)處理

2017年下旬,Line更新了相關的API,終於讓Linebot可以抓取到群組中的用戶的資訊,這一點看似不起眼,但其實沒有這個功能的話,相當程度的限制了Linebot在群組中的可能性。

也因此,隨著Line開發相關API,我們的LineBotSDK當然也跟著支援了,請將專案中的LineBotSDK更新到v0.6.1-beta即可享有此功能:

更新後你會發現有幾個跟群組聊天有關係的API,分別是

  • LeaveRoom
  • LeaveGroup
  • GetRoomMemberProfile
  • GetGroupMemberProfile

在開始之前,你需要知道一些基本概念:

  1. Line裡面的群組聊天有兩種,分別是room與group
  2. 你隨意地邀請幾個人加入聊天,那一種叫做room
  3. 你透過選單所建立的群組,叫做group
  4. 一個群組裡面只能加入一隻bot
  5. 你的bot無法知道是誰把自己加進來的
  6. 但你的bot可以知道群組中當前說話的人是誰(意味著,可以取得他的個人資料,包含頭像、顯示名稱…等),即便你的bot沒有跟發話者成為好友。
  7. 你的bot只能被某人加入群組,無法主動加入群組,但可以主動離開群組。

好了,有了這些基本概念之後,我們可以開始來玩玩看,請先大致瀏覽一下底下這段code,這是WebHook的片段程式碼(完整程式碼位於github https://github.com/isdaviddong/LinebotInTheGroup)  :


接著我們看運行的結果,當我們在兩人對話的狀況下,可以透過邀請好友的方式,把一隻bot加入對談:

注意上面testlinebot2018這支bot,請觀察他回復的訊息,你會發現,他是知道自己是被加入room還是group中的(這資訊很重要,可以透過source.type取得)。

同時,當你對照上面的code也可以知道,當bot被加入群組(room/group)時,WebHook會收到一個join的event(位於第12行)。

接著,你可以試試看在群組中說話:

你會發現,當bot收到你的訊息時,WebHook會收到一個message event(第18行),其中可以取得說話者的userId(36行),透過UserId你可以取得該人的個人資訊(35行, GetRoomMemberProfile),最後回應給群組中所有人(一樣透過Reply即可, 45行)。

如果要讓bot離開群組,只需要針對呼叫LeaveRoom/LeaveGroup即可(25,27行),例如:

當你對bot說bye,你會發現bot在說完bye-bye之後,就離開聊天室了,對應到上面的程式碼就是第19-27行,呼叫LeaveRoom或是LeaveGroup API即可,請留意,一但bot主動離開,bot是無法自己重新加回群組或聊天室的,必須『被加入』才行。

其實用起來並不難,但有這幾個功能之後,你的bot可以做的事情就非常多了,改天我們再來談談一些具體的應用實例。

------------------
相關課程:http://www.studyhost.tw/NewCourses/LineBot
電子書:http://studyhost.blogspot.tw/2017/12/line-bot.html
LineBotSDK:https://www.nuget.org/packages/LineBotSDK

如果需要即時取得更多相關訊息,可按這裡加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

2017年12月11日 星期一

MS Teams - 透過Incoming WebHook將通知傳入Channel

如果你開始使用MS Teams,Incoming WebHook是個不用可惜的簡單機制。

需求是這樣,我們常常在工作上想要在某些事件發生時(例如失火,系統崩潰、訂單爆量…)發生的時候,可以透過手機推播訊息的方式告知大家,而MS Teams中的Channel,本身就有手機App可以接收推送訊息,如果企業有使用免費的MS Teams(只要你有Office 365),那沒什麼道理不安裝這個App(因為平時跟同事的溝通、群組討論…都在用才對)…

因此,當事件發生時,把訊息送到Channel中是再合理不過的了。

怎麼實現呢?簡單到不行,首先,請先建立一個連接器(看你要在哪一個channel收到通知,就在哪一個channel裡面建):

在出現的連接器清單中,找到『Incoming WebHook(傳入WebHook,嘖嘖…翻譯的真好)』:

點選設定後,在接下來出現的畫面中,逐一填入:

最後按下建立,完成後會出現底下這一組URL:

請務必複製該URL,未來你只需要對該URL送出Post訊息,即可把訊息發到該channel,有訂閱該channel的用戶,自然可以在手機App上收到該通知。

例如,當你對WebHook URL送出底下訊息:

用戶會收到:

手機上也會收到通知:


很簡單吧… :)

2017年11月30日 星期四

關於bot framework (7) - 快速建立並測試MS Teams bot

MS最近推Teams推得很兇,但不知道有多少台灣企業開始使用MS Teams?

如果你也開始用,應該會知道裡面有一個T-Bot,也就是MS teams的bot,它可以擔任一些基礎的引導工作,但也僅此而已。不過,類似Slack一樣,你可以自己開發一個chat bot,掛在MS Teams裡面,做一些日常的查詢功能,例如查詢分機、檢索資料位置、一般員工 Q & A、教育訓練索引、或是更進一步的與ERP整合,來查詢訂單、庫存…等。

而且開發方式極其簡單,只需要透過MS bot framework就可以了,也就是說,IT人員可以透過bot framework,幾乎不用寫什麼code就完成一個可以運行在MS Teams裡面的T-Bot。

你可以先從透過azure建立一個bot開始:

在azure站台中,你可以透過搜尋 bot service找到(上圖),點選後,請選下圖中的建立:

接著填妥底下的資料,最後按下建立:

完成後,portal會自動跳到底下這樣的設定畫面,請依照您的需要選擇,如果您熟悉C#,您可以不勾選任何項目,以預設的值進行配置:

選擇Next之後,會出現底下畫面:

由於bot framework會需要您建立一個Microsoft App,因此azure portal會透過上圖的畫面引導你建立一個App,最終我們需要得到App Name, AppID與Password這三組資訊,請點選上圖中的Create…,接著,會自動跳出底下這樣的畫面:

系統已經自動為您產生同樣名稱的App,以及所需要的App ID,你只需點選上圖中的藍色按鈕『Generate…』,在接下來出現的畫面中,牢記你的Password(因為只會出現一次):

記好password之後,按下『Finish…』鈕回到原本的畫面,這時,你要填入剛才記得的密碼即可:

所有的設定完成之後,就會看到底下這個畫面,這表示你的bot已經被自動建立完成,到目前為止我們還沒寫任何一行程式碼:

當你點選上圖物中的這個『→test』鈕,azure portal會出現一個web的測試UI,讓你可以直接跟chat bot對話,當然,目前這個chat bot只會echo,但已經很不錯了。

如果你希望調整chat bot的功能,讓它多做一些事情,你可以點選上圖中的Download zip file下載source code,以VS2017開啟修改,你會發現其實就是一個很標準的bot framework框架所建立的Web API:

你可以修改程式碼後,將該Web Site Deploy到剛才建立的這個bot所關聯的Azure Web App站台即可。

好,上面是透過Azure建立chat bot的過程,回到我們的T-bot。

你可能不知道,這樣建立好的chat bot其實已經可以支援MS Teams了,只需要點選channels,選擇底下的Teams圖示:

按下 Done 就可以啦:

就只需要這樣,這個透過bot framework所建立的Chat bot已經支援MS Teams了,如果你想要測試,只需要進入到MS Teams的一對一聊天畫面,在『搜尋區塊』放大鏡的右邊,點選該圖示,然後在『收件人』欄位上,填入剛才建立好的這個chat bot的App ID,即可找到該chat bot:

這樣就可以在Teams中與他對談囉:

果然是我們這個只會echo的chat bot沒錯…

完全不用寫任何一行Code,MS Teams bot就搞定啦。

咦? 不記得剛才的App ID? 不要緊,在azure portal中bot的Settings頁面中,可以找到當時你建立的App ID:

一切都很輕鬆容易吧…

--------------------

相關課程: http://www.studyhost.tw/NewCourses

如果需要即時取得更多相關訊息,可按這裡加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

Related Posts Plugin for WordPress, Blogger...

熱門文章