Receiver HTTP_AAE - Cons. JSON-REST WS - 204 No Content as error

[Former Member]

Hello everyone!

Using 7.31 Java-only PI, I create a JMS->HTTP scenario for consuming JSON-REST web service.

So far, the messages are getting successfully converted in a custom adapter module (XML -> JSON), and the WS is handling the POST calls successfully. However, as a POST method for a json/rest, the WS is returning a "204 - No Content" message (which is a successful response), but the HTTP adapter is failing with the following exception:

"MP: exception caught with cause com.sap.aii.adapter.http.api.HttpAdapterException: STATUS_CODE_NOT_OK-No Content"

How can I configure HTTP adapter to consider 2xx messages as successful? This should be the default IMO, since it is a success status: http://wiki.scn.sap.com/wiki/display/XI/Http+Codes

I've found only one similar thread, however without answers:

http://scn.sap.com/thread/3293349

Appreciate any pointers given!

Thanks in advance,

Lucas Santos

[markangelo_dihiansan · Accepted solution]

Hello Lucas,

I do not have PI 7.31 but it is safe to assume (based on your error) that the 7.31 HTTP Adapter still expects an HTTP Body to be returned as its response.

In section 10.2.5 204 No Content of this article http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html ,it says

The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.
If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view.
The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.

Here is an additional information http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html section 4.3 Message Body

The rules for when a message-body is allowed in a message differ for requests and responses.
The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers. A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests. A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.
For response messages, whether or not a message-body is included with a message is dependent on both the request method and the response status code (section 6.1.1). All responses to the HEAD request method MUST NOT include a message-body, even though the presence of entity- header fields might lead one to believe they do. All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message-body. All other responses do include a message-body, although it MAY be of zero length.

Hope this helps,

Mark

[Former Member · Accepted solution]

Hello Mark!

The HTTP response was correct in its structure, so we had to ask the webservices provider to return HTTP 200 from successful REST POST messages, since HTTP adapter couldn't handle the response code correctly.

Thanks for the help!

BR,