在事件處理期間,連接器會利用通訊協定接聽器及配置的資料處理常式, 將來自
HTTP 服務用戶端的要求訊息轉換成協同作業可以操作的商業物件。
在事件處理中,通訊協定接聽器扮演重要的角色。
HTTP 要求可能透過 HTTP 或 HTTPS 傳輸進來。
接聽器會在傳輸通道上監督是否有這些要求抵達。
共有兩個通訊協定接聽器及對應的通道:
- HTTP 通訊協定接聽器
- HTTPS 通訊協定接聽器
各含一個執行緒來接聽傳輸。
收到來自用戶端的要求訊息時,接聽器會向通訊協定接聽器組織架構登錄此事件。
通訊協定接聽器組織架構負責管理通訊協定接聽器,排程需求在資源可用時執行。
您在設定連接器特有內容的值時,可以配置接聽器及通訊協定接聽器組織架構。
您可以配置的通訊協定接聽器組織架構內容如下:
- WorkerThreadCount
通訊協定接聽器組織架構可用的執行緒總數,即可以平行處理的要求數。
- RequestPoolSize 可以向通訊協定接聽器組織架構登錄的最大要求數。
如果收到的要求超過此最大要求數,就不再登錄新的要求。
連接器的這兩個特有內容可以控制記憶體配置,避免通訊協定接聽器在連接器中塞滿無限的事件。
配置演算法如下:連接器隨時可以接收的事件總數等於 WorkerThreadCount +
RequestPoolSize。 可以同時處理 WorkerThreadCount 個要求。
您可以在通訊協定接聽器組織架構內插入其他通訊協定接聽器。
如需進一步資訊,請參閱建立多重通訊協定接聽器及連結器特有的配置內容。
HTTP(S) 通訊協定接聽器包含一個執行緒,可以連續接聽來自用戶端的 HTTP(S)
要求。 此接聽器執行緒會連結在「主機」和「埠」連接器特有配置 (接聽器)
內容中指定的主機和埠。 另一個配置內容 -- RequestWaitTimeout --
定義接聽器在檢查連接器是否關閉之前等待要求的間隔時間。
圖 14 說明同步作業的 HTTP 通訊協定接聽器處理。
圖 14. HTTP 通訊協定接聽器:同步事件處理

圖 15 顯示非同步作業的 HTTP 通訊協定接聽器處理。
圖 15. HTTP 通訊協定接聽器:非同步事件處理

用戶端起始 HTTP 或 HTTPS 要求時會向 HTTP 或 HTTPS 接聽器公佈要求訊息。
用戶端應該使用 HTTP POST 方法來呼叫通訊協定接聽器 URL。
當 HTTP(S) 要求到達時,接聽器會向通訊協定接聽器組織架構登錄此要求,
由組織架構排程在資源可用時處理事件。
然後,接聽器再從要求中擷取通訊協定標頭及內容。
表 25 摘要說明接聽器判斷入埠訊息的 Charset、 MmeType、ContentType
及 Content-Type 標頭時所用的規則的優先順序。
表 25. HTTP(s) 通訊協定接聽器對於入埠訊息的處理規則
優先順序
| Charset
| MimeType
| ContentType
| Content-Type 標頭
|
1
| 進入的 HTTP 訊息 Content-Type 標頭值的 Charset 參數值
| 此接聽器的 URLsConfiguration 連接器值
| Content-Type 標頭值中進入的 HTTP 訊息類型/子類型值
| 進入的 HTTP 訊息 Content-Type 標頭
|
2
| 此接聽器的 URLsConfiguration 內容值
|
|
|
|
3
| 如果要求訊息的類型 ContentType 為 text 加上任何子類型
(例如,text/xml、text/plain 等),則預設為 ISO-8859-1。
否則不使用 charset。
| 預設為 ContentType
|
|
|
如表 25 所示:
- 通訊協定接聽器會根據下列規則來判斷入埠訊息的 Charset:
- 接聽器試圖從 HTTP 訊息 Content-Type 標頭值的 charset 參數中擷取 Charset。
- 如果從 Content-Type 標頭中無法取得 Charset
值,通訊協定接聽器會試圖讀取此接聽器的 URLsConfiguration 內容值。
- 如果上述步驟的方法無法取得 Charset 值, 且訊息類型 ContentType 為
text 加上任何子類型
(例如,text/xml、text/plain 等),接聽器會採用預設的
Charset 值 ISO-8859-1。 否則不使用 Charset 值。
- 接聽器會根據這些規則來判斷回應訊息的 MimeType:
- 如果進入的要求訊息所用的 URL 已配置 TransformationRule, 且要求
ContentType 也符合一個 TransformationRule 的 ContentType, 接聽器會採用此
TransformationRule 來擷取 MimeType,藉此將要求訊息轉換成「要求」商業物件。
接聽器會從所要求的 URL 的 URLsConfiguration 內容中,根據其中的 Content-Type 值
(例如 text/xml),找出完全相符的 TransformationRule。
- 如果找不到,接聽器再試圖找出適用於要求 URL 底下多個 Content-Type (例如
*/*) 的 TransformationRule。
- 如果上述所有步驟都無法判斷 MimeType, 就採用 ContentType 的值當作
MimeType,藉以呼叫資料處理常式,以及將要求訊息轉換成「要求」商業物件。
- 接聽器從進入的 HTTP 訊息 Content-Type 標頭中,擷取類型/子類型來判斷
Content-Type。
- 接聽器從進入的 HTTP 訊息 Content-Type 標頭中判斷 Content-Type 標頭。
如果非同步呼叫協同作業,接聽器會將「要求」商業物件傳遞至整合分配管理系統,
也會向用戶端回應 HTTP 狀態碼 202 Accepted。 訂定此將接聽器處理。
如果是同步呼叫,接聽器會同步呼叫協同作業。
協同作業會傳回一個「回應」商業物件。
表 26 針對接聽器判斷回應訊息的 Charset、MimeType、ContentType 及
Content-Type 標頭時所用的規則,彙總規則的優先順序。
表 26. HTTP(s) 通訊協定接聽器對於離埠同步回應訊息的處理規則
優先順序
| Charset
| MimeType
| ContentType
| Content-Type 標頭
|
1
| 通訊協定 ConfigMO Content-Type 標頭
| TLO 中的 MimeType 內容
| 通訊協定 ConfigMO Content-Type 標頭
| 通訊協定 ConfigMO Content-Type 標頭
|
2
| TLO 中的 Charset 內容值
| 要求訊息 MimeType,前提是要求與回應 ContentType 必須相符。
| 要求訊息 ContentType
| 使用 ContentType 和 Charset 來建構 Content-Type 標頭
|
3
| 要求訊息 Charset,前提是要求與回應 ContentType 必須相符。
| 使用 ContentType 值當作 MimeType
|
|
|
4
| 如果 ContentType 為 text/*,則預設為 ISO-8859-1。否則不使用
charset。
|
|
|
|
如表 26 所示,
- 接聽器會根據這些規則來判斷回應訊息的 Charset:
- 如果「回應」商業物件 Protocol Config MO 中已指定 Charset,則直接採用此值。
- 如果「回應」商業物件 Protocol Config MO 標頭中未指定 Charset 值,
接聽器會檢查 TLO 中是否指定 Charset。
- 如果 TLO 未指定 Charset,且回應與要求的 ContentType
相同,則回應會採用要求的 Charset。
- 如果上述步驟都無法判斷回應 Charset 值, 且訊息的類型部份 ContentType 為
text 加上任何子類型 (例如,
text/xml、text/plain 等),接聽器會採用預設的 Charset 值
ISO-8859-1。 否則不使用 Charset 值。
- 接聽器會根據這些規則來判斷回應訊息的 MimeType:
- TLO 的 MimeType 屬性
- 如果遺漏 TLO MimeType 屬性,且要求與回應的 ContentType 相符,
接聽器在回應訊息上會採用要求的 MimeType。
- 否則,接聽器會採用 ContentType 值作為 MimeType。
- 接聽器會根據這些規則來判斷回應訊息的 ContentType:
- 如果「回應」商業物件 Protocol Config MO 中已指定 Content-Type 標頭,
則採用 Content-Type 標頭的類型/子類型部份作為 ContentType。
- 如果「回應」商業物件 Protocol Config MO 中未指定 Content-Type 標頭,
接聽器會使用判斷的 ContentType 和 Charset 來建構 Content-Type 標頭
(如果已判斷回應訊息的 Charset)。
接聽器會處理 HTTP Protocol Config MO。 協同作業要負責確保 HTTP Protocol
Config MO 中傳遞的標頭值,在要求回應事件的環境定義中正確無誤。
接聽器會根據下列規則來填入標準標頭和自訂內容的資料:
- 接聽器調查 HTTP Protocol Config MO 的每一個項目,藉以略過特殊屬性 (例如
ObjectEventId)。
- 每一個非空白的標頭會放在外送訊息內,可能會發生額外的處理 (例如
Content-Type 標頭)。
- 請注意,透過上述方法,接聽器可能在訊息上設定非標準的標頭,但不會檢查訊息的邏輯或語法是否正確。
- 如果 HTTP Protocol Config MO UserDefinedProperties
屬性中有一或多個自訂內容, 則由接聽器新增至「實體標頭區段」內
(最後一個標頭區段)。 如需自訂內容的詳細資訊,請參閱事件處理程序的使用者定義內容。
- 註:
- 在 HTTP Protocol Config MO 中指定下列任何標頭,極可能導致不正確的 HTTP 訊息:
Connection、Trailer、Transfer-Encoding、Content-Encoding、
Content-Length、Content-MD5、Content-Range。
接著,接聽器會呼叫資料處理常式,將協同作業傳回的「回應」商業物件轉換成回應訊息。
接聽器將回應訊息傳回給用戶端,同時夾帶 200 OK HTTP 狀態碼。
如果協同作業傳回的是「錯誤」商業物件,則會轉換成錯誤訊息。 此錯誤訊息會搭配
500 Internal Server Error HTTP 錯誤碼傳遞至用戶端。
最後,接聽器就關閉連線,用來處理事件的執行緒又重新可以使用。
HTTP 通訊協定接聽器不支援下列功能:
- 快取:通訊協定接聽器不執行 HTTP 規格 (RFC2616) 定義的任何快取功能。
- Proxy:通訊協定接聽器不執行 HTTP 規格 (RFC2616) 定義的任何 Proxy 功能。
- 持續性連線:通訊協定接聽器不支援 HTTP 規格 (RFC2616) 定義的持續性連線。
相反地,通訊協定接聽器假設每一個 HTTP 連線的範圍都是單一用戶端要求,
且在完成服務要求時就關閉連線。
通訊協定接聽器不會試圖跨服務呼叫來重複使用連線。
- 重新導向:通訊協定接聽器不支援重新導向。
- 大型檔案傳送:通訊協定接聽器無法用於傳送大型檔案。
您可以考慮改以參照來傳遞大型檔案。
- 狀態管理:通訊協定接聽器不支援 RFC2965 說明的 HTTP 狀態管理機制。
- Cookie:通訊協定接聽器不支援 Cookie。
HTTPS 通訊協定接聽器處理同於 HTTP 通訊協定接聽器處理一節的說明,差別在於
HTTPS 是採用安全 Socket。 如需進一步資訊,請參閱SSL。
事件持續性視通訊協定而定:
- HTTP 通訊協定接聽器 沒有持續性,所以不保證遞送
- HTTPS 通訊協定接聽器 沒有持續性,所以不保證遞送
連接器可能以任何順序來傳遞事件。
事件觸發機制視通訊協定接聽器如何配置而定。
- HTTP 通訊協定接聽器 在 ServerSocket 上接聽 HTTP 連線要求
- HTTPS 通訊協定接聽器 在安全 ServerSocket 層上接聽 HTTPS
連線要求
- 註:
- 連接器不區分「建立」、「更新」、「擷取」或「刪除」。這些事件全部都遵循相同的方法。
每一個通訊協定接聽器都會偵測事件。
事件偵測機制完全取決於傳輸及如何配置每一個接聽器的連接器特有內容。
如需這些內容的詳細資訊,請參閱連結器特有的配置內容。
事件狀態由通訊協定接聽器來管理,取決於傳輸及如何配置接聽器。
- HTTP 通訊協定接聽器 HTTP 本質上是非持續性且同步的。
因此,不會維持事件狀態。
- HTTPS 通訊協定接聽器 HTTP 本質上是非持續性且同步的。
因此,不會維持事件狀態。
事件擷取由通訊協定接聽器來管理,取決於傳輸及如何配置接聽器。
- HTTP 通訊協定接聽器 從 Socket 擷取 HTTP 要求來擷取事件。
- HTTPS 通訊協定接聽器 從 Socket 擷取 HTTP 要求來擷取事件。
事件保存由通訊協定接聽器來管理,取決於傳輸及如何配置接聽器。
- HTTP 通訊協定接聽器
因為傳輸的非持續性及同步的本質,所以不進行保存。
- HTTPS 通訊協定接聽器
因為傳輸的非持續性及同步的本質,所以不進行保存。
事件回復由通訊協定接聽器來管理,取決於傳輸及如何配置接聽器。
- HTTP 通訊協定接聽器
因為傳輸的非持續性本質,所以不進行事件回復。
- HTTPS 通訊協定接聽器
因為傳輸的非持續性本質,所以不進行事件回復。
