req.get(‘content-type’)

正常的 batch 操作，response 的 content-type 不應該返回 html 類型：

正確的 batch response，Content-Type 值應該是 multipart/mixed; boundary=batchresponse_后面跟一個 guid

success handler 即下圖的 fnSuccess, 被包裹在 wraHandler 里。

content-type 不同的 response，對應有不同的 handler 來處理。

httpClient.request 如果執行出錯，會進入到 catch 分支，錯誤消息：

invalid MIME part type

使用分號將 multipart/mixed 和 boundary 的具體值分隔開。

每種類型都有對應的 handler，由對應的 handler 調用 read 方法執行 response 的解析操作。

解析 batch 操作的響應：

在出錯情況下，從 Chrome 開發者工具 network 標簽頁里下載 batch 響應到本地，和不出錯的場景比較，格式上沒有任何差異：

問題出在 batch response 的 header 里的 Content-Type 字段。

chrome 里看到的 content-type 不是這個啊：

body 是 null，所以進不去 7884 行的 dispatchHandler 函數：

multipart/mixed MIME 消息由不同數據類型的混合組成。 每個 body part 都由一個 boundary 劃定。 boundary 參數是一個文本字符串，用于將消息正文的一部分與另一部分區分開來。 所有邊界都以兩個連字符 hyphens (–) 開頭。 最后的邊界也以兩個連字符 (–) 結束。 邊界可以由除空格、控制字符或特殊字符之外的任何 ASCII 字符組成。

如果我們通過 batch 請求向服務器發送一個 word 文檔，則 HTTP body payload 的例子如下：

Content-type: multipart/mixed;
boundary="Boundary_any ascii character except some of the following special characters:

( )< > @ , ; : \ / [ ] ? = "
"
–Boundary_any ASCII character, except some special characters below:
content-Type: text/plain;----
charset=iso-8859-1
Content-transfer-encoding: 7BIT
–Boundary_ASCII characters
Content-type: application/msword;
name=“message.doc”
Content-Transfer-Encoding: base64

在 multipart 消息正文的情況下，一個或多個不同的數據集組合在一個正文中，值為 multipart 的 Content-Type 字段必須出現在 HTTP request entity 的頭部字段中。正文部分在語法上類似于 RFC 822 消息，只是含義不同。

更多Jerry的原創文章，盡在：“汪子熙”:

總結

以上是生活随笔為你收集整理的SAP UI5 框架是如何执行 batch 请求的单步调试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。