Monday, March 24, 2014

An alternative to Salesforces Wsdl2Apex for calling SOAP web services in Apex

Salesforce provides a tool called Wsdl2Apex that allows you to generate Apex classes from a WSDL. These Apex classes act as a proxy for invoking the web service methods.

While functional, Wsdl2Apex has a number of limitations. Including:

  1. The generated Apex classes require code coverage, which needs to be created manually.
  2. You need to import the entire WSDL. In many cases you may only require a subset of the web methods. Reducing the number of methods cuts down the lines of Apex (a limited resource) that are generated and subsequently the number of lines requiring code coverage.
  3. Support for complex types that extend a base type. <xsd:extension base="foo:Bar">.
  4. Support for importing another WSDL. <xsd:import>
  5. Support for attributes. <xsd:attribute>
  6. The ordering of the generated methods appears to be arbitrary (maybe hash based ordering internally?). At the very least, a small change in the input WSDL can produce Apex that doesn't diff very well. This can be a pain with source control and tracking the history of changes.
  7. Conflicts between named WSDL elements and reserved keywords in Apex. E.g. long
  8. WSDLs that contain multiple wsdl:binding elements

I've been working with an intern student here at FuseIT to create a replacement tool as part of the FuseIT SFDC Explorer under the new WSDL tab in the release. The current release is aimed at having reasonable feature parity with the existing Salesforce Wsdl2Apex implmentation.

Current functionality:

  • Import a WSDL from URL or local file.
  • User definable class names for each WSDL namespace
  • Detection of existing Apex Classes that match those being generated
  • The ability to select just the Apex methods that should be generated (including a description of the input and output parameters)
  • Publish the Apex classes directly into a Salesforce Org via the Tooling API.

Work in progress and possible future extensions:

  • Generate test Apex methods and mocks that give 100% code coverage for the generated callout code.
  • Generate HttpRequest web service calls as an alternative/backup to the WebServiceCallout.invoke calls.
  • Generate a WebServiceMock class with expanded request/response objects and doInvoke implementation.
  • Generate a wrapper Apex class that will revert to the mock implementation with running in a test case context. This could also expose the end point and timeout settings as properties.

See also:


  1. Nice blog..Looks like this tool will help us in the future for all SOAP implementation

    1. Thanks. There are still several areas that we will be expanding it. Please do let us know if you find a problematic WSDL.

    2. Hi, I found problematic WSDL. I've tried generate SpringCmService WSDL and seems that there is the problem with inheritance. The generated apex class has errors and can not be deployed to SFDC.

    3. Hi. Are you able to share the WSDL URL with me? I'll give it a test to see what the issue is. Also, what version of the sfdc explorer are you using?

    4. Hi, I'm using sfdc explorer v You can find WSDL under link:


    5. Hi Magdalena,

      The missing class SCMSecurity is based on a simpleType in the WSDL with the possible values: None, See, Read, Write, Move, Create, SetAccess.

      I'll need to look at updating the tool to support this. In the short term, you could manually edit the generated Apex Class replacing "wwwSpringcmComAtlasWebservicesV2013.SCMSecurity" with "String". Then just ensure you only set a valid value.


    6. Thank you Daniel for quick response.

      it is not the only problem. There is also issue with inheritance.
      In WSDL: SCM Document extends SCMObject and SCMObject extends SCMBaseObject.
      SCMObject inherits properties from SCMBaseObject, but from SCMDocument I don't have an access to them. In short scmDocument object doesn't inherit the SCMBaseObject.


    7. Hi Magda,

      We've updated to tool to handle multiple levels of inheritance. It will now pull the required fields from the extended complex types as required. Please get v1.16 or later to get this update.

      There is still a potential issue with the in SCMSecurity. In your case you can just space seperate the listed restriction values and it should work fine.


  2. This comment has been removed by the author.

  3. Hi Daniel.

    Very useful tool for Salesforce developers.

    I am battling to generate Apex stub classes from a RPC / encoded style WSDL. Would it be possible for you to have a quick look at the error? I have tried also after covering the WSDL to a Document / literal style WSDL, but I still cannot parse the WSDL file. I am using version 3.2.16095.1 of the FuseIT SFDC Explorer. I would really appreciate some help.

    Rudolf Niehaus

    1. Hi Rudolf,

      Unfortunately the native WebServiceCallout.invoke Apex method doesn't support RPC style web services. It might be possible using HttpCallout and XmlDom to construct and process the raw HTTP request/response. See