I have been studying Web Services in Salesforce, specifically SOAP. When must I use the wsdl2apex tool and when can I manipulate XML Document directly?

  • What do you mean by when can I manipulate XML Document directly
    – Raul
    Nov 9, 2016 at 10:05
  • When I work directly on XML for the request and for the response.
    – vt89
    Nov 9, 2016 at 11:01
  • 3
    Don't ignore JSON as an option: JSON APIs are usually better designed and simpler to use and JSON support in Apex is pretty good. There are many WSDLs beyond wsdl2apex 's capabilities.
    – Keith C
    Nov 9, 2016 at 11:29

2 Answers 2


[TL;DR;] It depends on how confortable you are with your coding skill.


You can use the WSDL2Apex tool anytime the webservice you want to call has a wsdl that you can use (believe me, sometimes they don't).

And you can create your own xml at anytime you want to call a webservice.

Even if you use WSDL2apex, you might want to review the generated code in order to see if it need any tweaks.

WSDL2Apex just creates sample code that matchs the WSDL of the webservice. Depending on how complex it is, it might be easiear to create the XML manually. For simple XMLs I normally just create a xml string and send it using an HTTP callout.


The web based version of WSDL2Apex is ultimately a code generator for WebServiceCallout.invoke. If you use it then you generally get the limitations for both WSDL2Apex and WebserviceCallout.invoke. See Considerations Using WSDLs and Supported WSDL Features.

It is possible to get a bit more out of WebServiceCallout.invoke by using an alternative tool to generate the Apex. There is, for example, the Open-Source version of Wsdl2Apex.

I'm somewhat biased with this being my current employer, but another options is the FuseIT SFDC Explorer that has an alternative version of WSDL2Apex which can do things like handle imports and extensions. See Improved Apex support for SOAP based web services.

When you can get these tools to work, they should significantly reduce the amount of plumbing you need to invoke a SOAP web service and then process the response. For example, our FuseIT version of the tool can also generate Apex to give you test coverage.

I say if you can get them to work as there seems to be as many different ways of building a WSDL as there are SOAP web services to call. Almost everyone has some strange variation or oddity that can make the WSDL challenging to work with.

If instead you went with the manually manipulating the XML then you have all the flexibility in the world to work with more difficult WSDL features. You do however have to do the plumbing work yourself. Again, the FuseIT version of WSDL2Apex can also generate boiler plate Apex using HttpRequests and XML response parsing. It might not get you all the way, but will hopefully save some time.

Don't forget that it might not just be a one-off implementation of the WSDL in Apex. The reason I created the FuseIT version of WSDL2Apex was to handle updates to a web service. Several times a year the third parties web service would be updated and I'd need to bring the changes into Apex. Having an automated tool made this considerably easier in the long run for a non-trivial WSDL.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .