中介軟體
適用于： SDK v4
中介軟體只是一個介於介面卡和 Bot 邏輯之間的類別，會在初始化期間新增至您介面卡的中介軟體集合中。 SDK 可讓您撰寫自己的中介軟體，或新增他人所建立的中介軟體。 每個透過中介軟體進出 Bot 流程的活動。
配接器會透過 Bot 中介軟體管線處理並導向傳入活動至 Bot 的邏輯，然後再次返回。 如同每個進出 Bot 的活動流程，每個中介軟體都可檢視活動，或在 Bot 邏輯執行之前或之後採取行動。
在跳到中介軟體之前，請務必先瞭解 Bot 一般 ，以及如何 處理活動。
使用中介軟體
問題通常會出現：「何時應該實作動作作為中介軟體，而不是使用我的一般 Bot 邏輯？」中介軟體提供額外的機會，讓您在處理交談的每個 回合 前後，與使用者的交談流程互動。 中介軟體也可讓您儲存和擷取關於對話的資訊，並於需要時呼叫其他處理邏輯。 以下是一些常見的案例，可說明中介軟體實用之處。
查詢每個活動或據以採取行動
在很多情況下，我們會要求 Bot 對每個活動或特定類型的每個活動採取行動。 例如，您可能想要記錄 Bot 接收的每個訊息活動，或如果 Bot 尚未產生此回合的回應，請提供後援回應。 中介軟體是這類程式的絕佳位置，其能夠在 Bot 邏輯的其餘部分執行前後動作。
修改或增強回合內容
如果 Bot 具有的資訊多過於活動中提供的資訊，則特定交談的成果內容可能更豐富。 在此情況下，中介軟體可查看其至目前為止的對話狀態、查詢外部資料來源，並將資料附加至回合內容物件，然後再將執行作業傳遞至該 Bot 邏輯。
SDK 會定義可記錄傳入和傳出活動的記錄中介軟體，但您也可以定義自己的中介軟體。
Bot 中介軟體管道
針對每個活動，介面卡可依您新增中介軟體的順序進行呼叫。 針對該回合和 next 委派，介面卡會在內容物件中傳遞，然後中介軟體會呼叫委派，並將控制項傳遞至管道中的下個中介軟體。 中介軟體也有機會在 next 委派傳回之後，先執行其他工作，再完成方法。 您可以想成每個中介軟體物件都有第一次和最後一次的機會，能在管道中和接續於中介軟體物件之後的項目進行互動。
例如：
- 第一個中介軟體物件的回合處理常式會在呼叫 下一個之前執行程式碼。
- 第二個中間件物件的回合處理常式會在呼叫 下一個之前執行程式碼。
- Bot 的回合處理常式會執行並傳回。
- 第二個中間件物件的回合處理常式會在傳回之前執行任何剩餘的程式碼。
- 第二個中間件物件的回合處理常式會在呼叫 下一個之前執行程式碼。
- 第一個中介軟體物件的回合處理常式會在傳回之前執行任何剩餘的程式碼。
如果中介軟體未呼叫下一個委派，配接器不會呼叫任何後續中介軟體或 Bot 回合處理常式，以及管線短線路。
Bot 中介軟體管道完成後，該回合即結束，且回合內容將超出範圍。
中介軟體或 Bot 可產生回應和註冊回應事件處理常式，不過請注意，這些回應會在個別程式中處理。
中介軟體的順序
由於中介軟體新增的順序會影響其處理活動的順序，因此請務必先決定好新增順序。
注意
這表示您會獲得適用於大部分的 Bot 的模式；但請務必考量在您的情境中，中介軟體和使用情境下與其他使用者的互動方式。
負責處理每個 Bot 最低層級工作的中介軟體，應該先新增至您的中介軟體管線。 例如：記錄、例外狀況處理和翻譯。 視您的需求排序這些訊息，例如您要先轉譯傳入訊息、儲存訊息之前，還是應該先進行訊息儲存，這表示不會轉譯預存的訊息。
Bot 特定的中介軟體應該最後新增至您的中介軟體管線，您實作中介軟體，以對傳送至 Bot 的每個訊息執行一些處理。 如果您的中介軟體使用狀態資訊或其他 Bot 內容中設定的資訊，請將其新增至中介軟體管道中，用於修改狀態或內容的中介軟體之後。
最少運算路由
另一個有關中介軟體和回應處理常式的重要概念是「最少運算路由」 。 如果系統繼續透過後續的執行層處理該執行作業，則中介軟體 (或回應處理常式) 必須呼叫其 next 委派傳遞執行。 如果未在該中介軟體內呼叫下一個委派 (或回應處理常式) ，則不會執行相關聯的管線簡短線路和後續層。 這表示所有 Bot 邏輯，以及關線中後續的任何中介軟體都會略過。 中介軟體與回應處理常式縮短回合之間的細微差異。
當中間件縮短回合時，不會呼叫 Bot 回合處理常式，但管線中這個點之前執行的所有中介軟體程式碼仍會執行至完成。
對於事件處理常式，不呼叫 next 表示事件已取消，這與中介軟體略過邏輯非常不同。 藉由不處理其餘事件，介面卡就永遠無法傳送。
秘訣
如果您執行最少運算路由回應事件 (例如 SendActivities)，請確保其為您預期的行為。 否則可能會導致您難以修正錯誤。
回應事件處理常式
除了應用程式和中介軟體邏輯，回應處理常式 (有時也指事件處理常式，或活動事件處理常式) 亦可新增至內容物件。 目前的內容物件發生相關聯回應時，系統在執行實際回應之前會先呼叫處理常式。 如果您已經知道想要針對其餘目前回應中，該類型的每個活動要執行哪些動作 (無論是在實際事件之前或之後執行)，這些處理常式非常實用。
警告
請特別小心，不要在其本身的個別回應事件處理常式內，呼叫活動回應方法，例如：從傳送活動處理常式內呼叫傳送活動方法。 這樣可能會產生無限迴圈。
請記住，每個新活動都取得要在其中執行的新執行緒。 建立執行緒處理活動時，該活動的處理常式清單會複製到該執行緒。 系統不會針對該特定活動事件，執行該時間點後新增的任何處理常式。 在內容物件上註冊的處理常式會以類似配接器管理中介軟體管線的方式來處理。 也就是說，系統將依照處理常式新增的順序進行呼叫，然後再呼叫下一個委派，將控制項傳遞至下個註冊的事件處理常式。 如果處理常式未呼叫下一個委派，則不會呼叫任何後續事件處理常式、事件短線路，而且配接器不會將回應傳送至通道。
處理中介軟體中的狀態
儲存狀態的常見方法是在回合處理常式的結尾呼叫「儲存變更」方法。 以下是具有通話焦點的圖表。
這種方法的問題在於，從某些自訂中介軟體所做的狀態更新，在 Bot 的回合處理常式傳回之後發生的任何狀態更新都不會儲存到永久性儲存體。 解決方法是將 auto-save changes 中介軟體的執行個體新增至中介軟體堆疊的開頭，或至少在任何可能更新狀態的中介軟體之前，以將對「儲存變更」方法的呼叫移到完成自訂中介軟體之後。 執行如下所示。
將需要更新的狀態管理物件新增至「Bot 狀態集」 物件，然後在您建立自動儲存變更中介軟體時使用。