Use WSDL2Apex to Generate Apex Code

In addition to REST callouts, Apex can also make callouts to SOAP web services using XML. Working with SOAP can be a painful (but necessary) experience. Fortunately, we have tools to make the process easier.

WSDL2Apex automatically generates Apex classes from a WSDL document. You download the web service’s WSDL file, and then you upload the WSDL and WSDL2Apex generates the Apex classes for you. The Apex classes construct the SOAP XML, transmit the data, and parse the response XML into Apex objects. Instead of developing the logic to construct and parse the XML of the web service messages, let the Apex classes generated by WSDL2Apex internally handle all that overhead. If you are familiar with WSDL2Java or with importing a WSDL as a Web Reference in .NET, this functionality is similar to WSDL2Apex. You’re welcome.

Info on the process here.

Test Web Service Callouts

All experienced Apex developers know that to deploy or package Apex code, at least 75% of that code must have test coverage. This coverage includes our classes generated by WSDL2Apex. You might have heard this before, but test methods don’t support web service callouts, and tests that perform web service callouts fail. So, we have a little work to do. To prevent tests from failing and to increase code coverage, Apex provides a built-in WebServiceMockinterface and the Test.setMock method. You can use this interface to receive fake responses in a test method, thereby providing the necessary test coverage.

Specify a Mock Response for Callouts

When you create an Apex class from a WSDL, the methods in the autogenerated class call WebServiceCallout.invoke , which performs the callout to the external service. When testing these methods, you can instruct the Apex runtime to generate a fake response whenever WebServiceCallout.invoke  is called. To do so, implement the WebServiceMockinterface and specify a fake response for the testing runtime to send.

Instruct the Apex runtime to send this fake response by calling Test.setMock  in your test method. For the first argument, pass WebServiceMock.class . For the second argument, pass a new instance of your WebServiceMockinterface implementation.

Test.setMock(WebServiceMock.class, new MyWebServiceMockImpl());

Lets make an example. In this example, you create the class that makes the callout, a mock implementation for testing, and the test class itself.

First, make the AwesomeCalculator class:

public class AwesomeCalculator {
    public static Double add(Double x, Double y) {
        calculatorServices.CalculatorImplPort calculator = 
            new calculatorServices.CalculatorImplPort();
        return calculator.doAdd(x,y);
    }
}

Create your mock implementation to fake the callout during testing. Your implementation of WebServiceMock calls the doInvoke method, which returns the response you specify for testing. Most of this code is boilerplate.

The hardest part of this exercise is figuring out how the web service returns a response so that you can fake a value. Look at the WSDL2Apex-generated service and see exactly how the return value works.

@isTest
global class CalculatorCalloutMock implements WebServiceMock {
   global void doInvoke(
           Object stub,
           Object request,
           Map<String, Object> response,
           String endpoint,
           String soapAction,
           String requestName,
           String responseNS,
           String responseName,
           String responseType) {
        // start - specify the response you want to send
        calculatorServices.doAddResponse response_x = 
            new calculatorServices.doAddResponse();
        response_x.return_x = 3.0;
        // end
        response.put('response_x', response_x); 
   }
}