Apex Code Development You need to sign in to do that
Don't have an account?
John A Handling large XML Response
We have developed a Apex class which retrieves information from a external server where the
response we get is sometimes more than 100000 charecters and the SFDC API is not
able to handle it. We are using XML DOM for it. Can anyone suggest a
solution to handle a response which is more than 100000 charecters ?
Apex callouts do have a limit to the size of the web service response. Is that the error you are running into?
Here is a possible workaround. You could make the callout from Apex to invoke your external web service. Then simply respond "ack" or "yes" back to Apex. But the actual data response comes through the Force.com Web Services API. Let me know if that is an option for you and I can elaborate (if needed).
Thanks,
Andrew
Hi Andrew,
Thanks for quick reply. Actually we have written a apex class to get the data of all cities from external server based upon the State selection which is made in the S-control. Some times the response which we are getting is more than 100000 charecters or 128kb. So it is throwing an exception that the usage limit exceeded of more than 100000 charecters and the call fails.
Thanks & Regards,
John
Yeah, that is what I was afraid of. The size of the web service response can't be that large. Can you chunk the external web service to return less data? Or only return chunk and the scontrol can make additional calls as necessary? (similar to how the salesforce.com query and querymore API works..).
Or another workaround is to solve this asynchronously and also using the standard salesforce.com Web Services API. This might not be feasible for you - but thought I would walk through it briefly.
1. Scontrol invokes web service.
2. Web service returns "ack" but no data.
3. salesforce.com scontrol completes and user moves on with there work.
4. the external web service uses the salesforce.com Web Services API to send the response data back to salesforce.com (ie update a record...).
Just thinking out loud here.
Andrew,
Thanks again. The client is not ready to split up the response. What we r doing now is based upon the criteria selected S-control UI it generates the xml payload and call the apex class. The apex class sends the xml payload to the external server. when we are accepting the response it fails.
can u explain the asynchronous cal option in detail ?
Thanks & Regards
John .
1. Scontrol invokes web service. (sounds like you have this already working)
2. Web service returns "ack" but no data
- This allows the SControl to not hit the response size limit error you are running into today.
3. salesforce.com scontrol completes and user moves on with there work.
4. the external web service uses the salesforce.com Web Services API to send the response data back to salesforce.com (ie update a record...).
- This is the major change in the design. The web service response still needs to get to salesforce.com. This will be async since the scontrol and user have already received the "ack" message, but here you can have the external service use the salesforce.com Web Services API to update/insert/query/delete the related data.
Thanks Andrew. I wil try the approach which u have explained.
Thanks & Regards,
John
I personaly got stuck there and it seems like there is no way to work around it. they have a limitation of 100000 byte (1MB) for each callout and 10 callout per run. so it means that if you have any data bigger than 10MB then forget salesforce! this keeps their platform for only super small businesses. They should increase or just remove these limitations!!
About using asynch approach: this sacrifices the reliability since you cant get any acknowledge unless you modify your code on the other side to update certain field in salesforce and then check that from salesforce to see if the update was completed. but if you want to show your results right away then this approach is not for you. the solution would be to forget salesforce limited service! I dont know why they call it SaaS. not scalable at all.