Hi,

We are consuming a REST API from Salesforce and made a HTTP PATCH call from the Integration Server to Salesforce.
However, we observed that Salesforce received a GET request instead of PATCH. On increasing the logging level within IS, we observed that Salesforce initially sent back a HTTP 301 status code and following redirection, the method got changed to GET while making the call to the new URL.

I read on one of the knowledge center articles that this has been handled in IS version 10.0 and up but we are using 10.3 and facing this issue. Does anybody have a solution or workaround for this?

Thanks

try:

1. use https instead
2. use the “Location” header response of 301 as your target url

If the service being used here is pub.client:http, IS automatically follows. No way to handle that yourself. Indeed, appears no way to prevent pub.client:http from following redirects, which is something of a bummer in some cases.

Might this be due to SFDC using the P-R-G technique? P is usually POST but could also be PATCH. It is typically for UIs to avoid users hitting the back button and submitting the same data again but can be useful for APIs too – PATCH is processed, Redirect returned to reference URL affected by the patch, GET to get the latest data which was just changed by the patch.

To confirm that is the behavior, should see the PATCH and a GET in Salesforce log.

Thought this might be something to consider as an alternative explanation.

Thanks for the reply reamon. We already checked it with Salesforce but this is not the case. The record has not been updated and they cannot see any PATCH requests come through.

Moreover, the same call works perfectly fine through Postman which means it is handling the redirect gracefully.

Looks like the Integration Server does not handle all redirect related HTTP response codes contrary to what is mentioned in the knowledge center on empower.

Hi Vaibhav,

If you’re sure that IS is not handling it as per what it’s expected to do, I’ll suggest you to come out with a sample package and save the pipeline to demonstrate your observation. If the R&D from SAG is able to reproduce and confirm the same behavior after you’ve submitting an official case to them with the package, I’m sure they’ll be able to provide you some sort on fix on it.

Hi Mike,

Thank you for the suggestion. The reason I posted the query here is to check if someone already has faced this issue and has a workaround for it. We do not have enough time to go through the SI procedure so was looking for a quick response if anyone had it.

Below is what we captured in the server logs which gave us a clear idea of what the issue is.

Thanks

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/c5527412e82a5e7c9cf5b640ebcbf4ede0991ea3_2_1035x469.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/c5527412e82a5e7c9cf5b640ebcbf4ede0991ea3_2_1380x626.png 2x" data-dominant-color="EEEDEC">

image1835×835 108 KB

Despite how the pub.client:http works, as for workaroud since it was 301 Moved Permanently, then it should be safe to update the previous url value to the new url as per response Location header.

What was it responding to if not the PATCH?

Salesforce only saw a GET request which was initiated by Integration Server to the redirected url after receiving a HTTP 301 from the initial URL.

I can also see the same in the IS server logs.

Hi Vaibhav,
According to the description of 301 from the RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (ietf.org)

Note: For historical reasons, a user agent MAY change the request
method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.

So, IS is behaving as expected since Saleforce is returning 301.

If the server returns a 307 status, the HTTP method should not be changed from POST to GET. ( RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (ietf.org)

So, if Saleforce returns 307/308 response, then IS will not change the HTTP Method on redirection.

Thanks for the explanation Jaideep. We eventually changed the url in our configuration to the one returned by HTTP 301 response as also mentioned by @Aryell_Hutagalung but we got a bit confused as to why Postman could handle it and Integration Server couldn’t.