How does the SAP UI5 framework perform batch request single step debugging

“This is the 40th day of my participation in the First Challenge 2022. For details: First Challenge 2022”

req.get(‘content-type’)

Normal Batch operation, the content-type of response should not return the HTML type:

Correct batch response,Content-TypeValue should bemultipart/mixed; Boundary =batchresponse_ followed by a GUID

The SUCCESS Handler, fnSuccess as shown below, is wrapped in a wraHandler.

Different content-type responses should be handled by different handlers.

Httpclient. request: catch branch:

invalid MIME part type

Use a semicolon to separate the specific value of multipart/mixed from boundary.

Each type has a corresponding handler, which is specified by the correspondinghandlercallreadMethod performs the parse of response.

Parse the response to the Batch operation:

In the case of an error, download the batch response locally from the Chrome Developer Tools Network TAB, and the format is no different than in the no-error scenario:

The problem is the Content-Type field in the header of the Batch response.

The content-Type that you see in Chrome is not this:

Body is null, so you can’t get in7884thedispatchHandlerFunction:

Multipart/Mixed MIME messages are composed of a mixture of different data types. Each body part is delimited by a boundary. The boundary parameter is a text string used to distinguish one part of the message body from another. All borders start with two hyphens 登 记 (–). The final boundary also ends with two hyphens (–). A boundary can consist of any ASCII character except Spaces, control characters, or special characters.

If we send a Word document to the server via a batch request, the HTTP body payload example is as follows:

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

In the case of a multipart message body, where one or more different data sets are combined in one body, the Content-Type field with the value multipart must appear in the header field of the HTTP Request Entity. The body part is syntactically similar to RFC 822 messages, but with different meanings.

For more of Jerry’s original articles, see “Wang Zixi “: