在上一篇([02]建立第一個V4 Chatbot - EchoBot)看了如何建立出一個Hello World等級的Chatbot:EchoBot并且使用了Bot Emulator對他做了測試,看起來也沒什麽問題。
那麽下一個問題就來了,Bot Framework到底是怎麽組成的?整個信息的流是怎麽動起來?
這篇將來介紹Bot Framework裡面用到的一些關鍵字,以及整個是如何搭起來,未來不管是在看文件還是深入研究才不會搞得糊里糊塗。
Activity是什麽?
還記得這張圖嗎?
當一個信息傳過來到Bot的時候,這個信息稱爲一個Activity。
注意,這邊提的是信息而不是訊息,換句話説,傳過來的不一定都是有内容(例如文字、圖片和語音這種人發出來的訊息),而是可能是狀態類型例如某個人剛加入了聊天(有了這個通知bot可以發出 相關對應内容讓這個人更好和bot溝通)。
因此,Activity有幾個重要的部分:
- ActivityTypes
- 什麽類型的信息,V4支援的類型還蠻多,這邊不一個一個介紹,大部分看名稱應該多多少少知道是什麽:
- 實際的訊息
-
如果ActivityTypes屬於
message
,那麽傳過來有可能是文字、圖片或者語音,因此從Activity裡面取得這些訊息在做對應處理是Chatbot的很大一塊邏輯 - 其他和這個Activity有關的周邊信息
- 有很多metadata,例如這個信息是誰傳送過來,透過什麽Channel(不同Channel回復方式可能不同)等等。
有了Activity的概念之後來看這個:
這邊可以發現到:
- 總共出現了兩種Activity Types:conversational update以及message
- 信息透過POST方式傳遞,然後一個200的status code表示收到
這個就是信息在bot是怎麽傳遞。
處理一個信息的流程
上面看完了高的角度,接下來往下鑽,看看一個信息是怎麽被處理完成。
這邊將介紹:
- Turn以及turn context
- Middleware
- Bot
- Response Event Handler
- Adapter
Turn 以及 turn context的概念
Activity是代表一個信息,那麽Turn就代表處理這個信息的所有process。
簡單一點來説,從Activity進來,會經過好多關卡,到最後Bot回復一個信息回去,這個完整處理流程就是一個Turn。
這邊提到了關卡,換句話説會過好多層,那麽這些不同層是不是需要一個共通可以溝通的物件代表了整個處理Activity的情況?
這個就是所謂的turn context。Activity會被轉換成爲turn context方便不同關卡之間的處理以及溝通。
Middleware
Middleware和一般聽到的Middleware作用是一樣的,主要可以用來做一些Cross Cutting Concern。
因此如果有些通用類型的處理要做,就可以用Middleware來達成 - Middleware也是上面提到的過好多關卡的關卡部分。
Bot
Bot是最後一站,Bot決定對這個信息要做出什麽樣的反應。
因此,處理的邏輯都是寫在這邊。
Response Event Handler
當Bot處理完,要把信息發送回到Channel之前,除了會經過Middleware之外,在turn context有response event handler可以注冊。
有注冊就會在對應response發生的時候觸發。
Adapter
要把時間點拉前面一些,還記得之前提到信息是Activity,而爲了處理這個Activity有一個共通的物件建立出來,也就是turn context。
那麽,是誰把turn context建立起來并且開始啓動關卡呢?這就是Adapter。
把上面的概念畫成一個sequence diagram就會像下面這樣:
在這個圖裏面唯一沒有介紹到的就是Web Server Integration。在C#來説這個指的是Asp .NET的部分。結語
這篇介紹了整個V4版本的核心原件以及整個信息處理的流程。
瞭解這些關鍵字不止在看code的時候能夠更加瞭解,在看文件的時候也才不會糊里糊塗。
透過這篇,也會發現和V3有很大的不同,更別説還有一些概念例如Dialog還沒介紹到(和V3有不同的意思)
都是理論有點無聊,下一篇([04]瞭解EchoBot的程式碼結構)將拆解EchoBot,實際來看看整合怎麽和這篇對應。
參考資料
- 官方介紹這個部分:Understanding how bots work
- 傳送門