SOAP Services: Defining a Class from a WSDL Document

Classes can be automatically generated from a WSDL document that is stored on a local hard drive or network. Creating a class by consuming a WSDL document allows developers to make callouts to the external Web service in their Apex code.

To generate an Apex class from a WSDL:

1. In the application, from Setup, enter Apex Classes in the Quick Find box, then select Apex Classes.

2. Click Generate from WSDL.

3. Click Browse to navigate to a WSDL document on your local hard drive or network, or type in the full path. This WSDL document is the basis for the Apex class you are creating.

   The WSDL document that you specify might contain a SOAP endpoint location that references an outbound port.

   For security reasons, Salesforce restricts the outbound ports you can specify to one of the following:

   • 80: This port only accepts HTTP connections.
   • 443: This port only accepts HTTPS connections.
   • 1024–66535 (inclusive): These ports accept HTTP or HTTPS connections.
   Note

4. Click Parse WSDL to verify the WSDL document contents. The application generates a default class name for each namespace in the WSDL document and reports any errors. Parsing fails if the WSDL contains schema types or constructs that aren’t supported by Apex classes, or if the resulting classes exceed the 1 million character limit on Apex classes. For example, the Salesforce SOAP API WSDL cannot be parsed.

5. Modify the class names as desired. While you can save more than one WSDL namespace into a single class by using the same class name for each namespace, Apex classes can be no more than 1 million characters total.

6. Click Generate Apex. The final page of the wizard shows which classes were successfully generated, along with any errors from other classes. The page also provides a link to view successfully generated code.

The successfully generated Apex classes include stub and type classes for calling the third-party Web service represented by the WSDL document. These classes allow you to call the external Web service from Apex. For each generated class, a second class is created with the same name and with a prefix of Async. The first class is for synchronous callouts. The second class is for asynchronous callouts. For more information about asynchronous callouts, see Make Long-Running Callouts with Continuations.

Note the following about the generated Apex:

• If a WSDL document contains an Apex reserved word, the word is appended with _x when the Apex class is generated. For example, limit in a WSDL document converts to limit_x in the generated Apex class. See Reserved Keywords. For details on handling characters in element names in a WSDL that are not supported in Apex variable names, see Considerations Using WSDLs.
• If an operation in the WSDL has an output message with more than one element, the generated Apex wraps the elements in an inner class. The Apex method that represents the WSDL operation returns the inner class instead of the individual elements.
• Since periods (.) are not allowed in Apex class names, any periods in WSDL names used to generate Apex classes are replaced by underscores (_) in the generated Apex code.

After you have generated a class from the WSDL, you can invoke the external service referenced by the WSDL.

To invoke an external service after using its WSDL document to generate an Apex class, create an instance of the stub in your Apex code and call the methods on it. For example, to invoke the StrikeIron IP address lookup service from Apex, you could write code similar to the following:

1// Create the stub
2strikeironIplookup.DNSSoap dns = new strikeironIplookup.DNSSoap();
3
4// Set up the license header
5dns.LicenseInfo = new strikeiron.LicenseInfo();
6dns.LicenseInfo.RegisteredUser = new strikeiron.RegisteredUser();
7dns.LicenseInfo.RegisteredUser.UserID = 'you@company.com';
8dns.LicenseInfo.RegisteredUser.Password = 'your-password';
9
10// Make the Web service call
11strikeironIplookup.DNSInfo info = dns.DNSLookup('www.myname.com');

You can set the HTTP headers on a Web service callout. For example, you can use this feature to set the value of a cookie in an authorization header. To set HTTP headers, add inputHttpHeaders_x and outputHttpHeaders_x to the stub.

The following samples work with the sample WSDL file in Generated WSDL2Apex Code:

1docSample.DocSamplePort stub = new docSample.DocSamplePort();
2stub.inputHttpHeaders_x = new Map<String, String>();
3
4//Setting a basic authentication header
5// Tip: Use named credentials instead.
6stub.inputHttpHeaders_x.put('Authorization', 'Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==');
7
8//Setting a cookie header
9stub.inputHttpHeaders_x.put('Cookie', 'name=value');
10
11//Setting a custom HTTP header
12stub.inputHttpHeaders_x.put('myHeader', 'myValue');
13
14String input = 'This is the input string';
15String output = stub.EchoString(input);

If a value for inputHttpHeaders_x is specified, it overrides the standard headers set.

1docSample.DocSamplePort stub = new docSample.DocSamplePort();
2stub.outputHttpHeaders_x = new Map<String, String>();
3String input = 'This is the input string';
4String output = stub.EchoString(input);
5
6//Getting cookie header
7String cookie = stub.outputHttpHeaders_x.get('Set-Cookie');
8
9//Getting custom header
10String myHeader = stub.outputHttpHeaders_x.get('My-Header');

The value of outputHttpHeaders_x is null by default. You must set outputHttpHeaders_x before you have access to the content of headers in the response.

Apex supports only the document literal wrapped WSDL style and the following primitive and built-in datatypes:

Apex also supports the following schema constructs:

• xsd:all, in Apex code saved using API version 15.0 and later

• xsd:annotation, in Apex code saved using API version 15.0 and later

• xsd:attribute, in Apex code saved using API version 15.0 and later

• xsd:choice, in Apex code saved using API version 15.0 and later

• xsd:element. In Apex code saved using API version 15.0 and later, the ref attribute is also supported with the following restrictions:

  • You cannot call a ref in a different namespace.
  • A global element cannot use ref.
  • If an element contains ref, it cannot also contain name or type.

• xsd:sequence

The following data types are only supported when used as call ins, that is, when an external Web service calls an Apex Web service method. These data types are not supported as callouts, that is, when an Apex Web service method calls an external Web service.

• blob
• decimal
• enum

Apex does not support any other WSDL constructs, types, or services, including:

• RPC/encoded services

• WSDL files with multiple portTypes, multiple services, or multiple bindings

• WSDL files that import external schemas. For example, the following WSDL fragment imports an external schema, which is not supported:

  1<wsdl:types>
  2    <xsd:schema
  3     elementFormDefault="qualified"
  4     targetNamespace="http://s3.amazonaws.com/doc/2006-03-01/">
  5      <xsd:include schemaLocation="AmazonS3.xsd"/>
  6    </xsd:schema>
  7  </wsdl:types>

  However, an import within the same schema is supported. In the following example, the external WSDL is pasted into the WSDL you are converting:

  1<wsdl:types>
  2    <xsd:schema
  3      xmlns:tns="http://s3.amazonaws.com/doc/2006-03-01/"
  4      xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  5      elementFormDefault="qualified"
  6      targetNamespace="http://s3.amazonaws.com/doc/2006-03-01/">
  7
  8      <xsd:element name="CreateBucket">
  9        <xsd:complexType>
  10          <xsd:sequence>
  11     [...]
  12    </xsd:schema>
  13  </wsdl:types>

• Any schema types not documented in the previous table

• WSDLs that exceed the size limit, including the Salesforce WSDLs

• WSDLs that don’t use the document literal wrapped style. The following WSDL snippet doesn’t use document literal wrapped style and results in an “Unable to find complexType” error when imported.

  1<wsdl:types>
  2    <xsd:schema targetNamespace="http://test.org/AccountPollInterface/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  3      <xsd:element name="SFDCPollAccountsResponse" type="tns:SFDCPollResponse"/>
  4      <xsd:simpleType name="SFDCPollResponse">
  5          <xsd:restriction base="xsd:string" />
  6      </xsd:simpleType>
  7    </xsd:schema>
  8  </wsdl:types>

  This modified version wraps the simpleType element as a complexType that contains a sequence of elements. This follows the document literal style and is supported.

  1<wsdl:types>
  2    <xsd:schema targetNamespace="http://test.org/AccountPollInterface/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  3      <xsd:element name="SFDCPollAccountsResponse" type="tns:SFDCPollResponse" />
  4      <xsd:complexType name="SFDCPollResponse">
  5        <xsd:sequence>
  6          <xsd:element name="SFDCOutput" type="xsd:string" />
  7        </xsd:sequence>
  8      </xsd:complexType>
  9    </xsd:schema>
  10  </wsdl:types>

• Generated WSDL2Apex Code

  You can generate Apex classes from a WSDL document using the WSDL2Apex tool. The WSDL2Apex tool is open source and available on GitHub.

• Test Web Service Callouts

  Generated code is saved as an Apex class containing the methods you can invoke for calling the web service. To deploy or package this Apex class and other accompanying code, 75% of the code must have test coverage, including the methods in the generated class. By default, test methods don’t support web service callouts, and tests that perform web service callouts fail. To prevent tests from failing and to increase code coverage, Apex provides the built-in WebServiceMock interface and the Test.setMock method. Use WebServiceMock and Test.setMock to receive fake responses in a test method.

• Performing DML Operations and Mock Callouts

• Considerations Using WSDLs