This is a bit of old issue, but I making this post as it does drive home an important lesson regarding Salesforce.com custom code development. For one of our customer, there was this legacy code that used HTTP Callouts, which has been working for several years. However, around the time of Winter '14 Release, the users started reporting that that piece of code was not working.
After digging through it, I was able to narrow it down the problem to following error on response from the callout to the external web service - a standard non-descriptive error message that appears for pretty much all error with HTTP callout:
Read Timeout Error
Unexpected End of Element...
Because the way Apex parses the response, I couldn't find out much more from the debug log. As a next step, I tried to find out if the issue was related to how Apex handles the Callout or if it was something wrong with the web service itself by duplicating the request that the Apex code is suppose to generate within SoapUI. However, from SoapUI, we were getting the response that we expect to get, leading us to go back to the Salesforce side of things.
This time around, what I did to find the issue in the Callout was to strip down the Callout message to bare bones to see if it would work and then adding the elements back to the message one at a time. The bare bone message did indeed work from Salesforce, and it turned out that problem was caused by following header:
Expect: 100-Continue
The fix for this problem was simply removing that header. I don't know for sure if this issue was introduced with Winter '14 Release or through the changes to the external web service (btw, this limitation is now documented here). However, this does provide a reminder on the dangers of using custom code in terms of its fragility when it comes to upgrade either to Salesforce or external service it interfaces.
No comments:
Post a Comment