SOAP Services: Defining a Class from a WSDL Document

Invoking an External Service

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:

  // Create the stub
  strikeironIplookup.DNSSoap dns = new strikeironIplookup.DNSSoap();

  // Set up the license header
  dns.LicenseInfo = new strikeiron.LicenseInfo();
  dns.LicenseInfo.RegisteredUser = new strikeiron.RegisteredUser();
  dns.LicenseInfo.RegisteredUser.UserID = 'you@company.com';
  dns.LicenseInfo.RegisteredUser.Password = 'your-password';

  // Make the Web service call
  strikeironIplookup.DNSInfo info = dns.DNSLookup('www.myname.com'); 

HTTP Header Support

Sending HTTP Headers on a Web Service Callout

docSample.DocSamplePort stub = new docSample.DocSamplePort();
stub.inputHttpHeaders_x = new Map<String, String>();

//Setting a basic authentication header
// Tip: Use named credentials instead.
stub.inputHttpHeaders_x.put('Authorization', 'Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==');

//Setting a cookie header
stub.inputHttpHeaders_x.put('Cookie', 'name=value');

//Setting a custom HTTP header
stub.inputHttpHeaders_x.put('myHeader', 'myValue');

String input = 'This is the input string';
String output = stub.EchoString(input);

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

Tip

Instead of hardcoding the Authorization header value, use named credentials. Named credentials offer a declarative and secure way to store and manage the credentials needed for HTTP callouts so that Salesforce can authenticate with external APIs. For more information, see Named Credentials in Salesforce Help.

Accessing HTTP Response Headers from a Web Service Callout Response

docSample.DocSamplePort stub = new docSample.DocSamplePort();
stub.outputHttpHeaders_x = new Map<String, String>();
String input = 'This is the input string';
String output = stub.EchoString(input);

//Getting cookie header
String cookie = stub.outputHttpHeaders_x.get('Set-Cookie');

//Getting custom header
String 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.

Supported WSDL Features

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

Note

The Salesforce datatype anyType is not supported in WSDLs used to generate Apex code that is saved using API version 15.0 and later. For code saved using API version 14.0 and earlier, anyType is mapped to String.

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:

    <wsdl:types>
      <xsd:schema
       elementFormDefault="qualified"
       targetNamespace="http://s3.amazonaws.com/doc/2006-03-01/">
        <xsd:include schemaLocation="AmazonS3.xsd"/>
      </xsd:schema>
    </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:

    <wsdl:types>
      <xsd:schema
        xmlns:tns="http://s3.amazonaws.com/doc/2006-03-01/"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified"
        targetNamespace="http://s3.amazonaws.com/doc/2006-03-01/">
  
        <xsd:element name="CreateBucket">
          <xsd:complexType>
            <xsd:sequence>
       [...]
      </xsd:schema>
    </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.

    <wsdl:types>
      <xsd:schema targetNamespace="http://test.org/AccountPollInterface/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <xsd:element name="SFDCPollAccountsResponse" type="tns:SFDCPollResponse"/>
        <xsd:simpleType name="SFDCPollResponse">
            <xsd:restriction base="xsd:string" />
        </xsd:simpleType>
      </xsd:schema>
    </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.

    <wsdl:types>
      <xsd:schema targetNamespace="http://test.org/AccountPollInterface/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <xsd:element name="SFDCPollAccountsResponse" type="tns:SFDCPollResponse" />
        <xsd:complexType name="SFDCPollResponse">
          <xsd:sequence>
            <xsd:element name="SFDCOutput" type="xsd:string" />
          </xsd:sequence>
        </xsd:complexType>
      </xsd:schema>
    </wsdl:types>