You will need to get an active Salesforce session id and know which instance it comes from. You can do this in a number of ways, such as:
- using one of the oauth flows (generally the preferred method),
- by calling login on the partner/enterprise API,
- via a canvas app (signed request),
- or just copying the id from the current sid cookie.
Once you have it, you will need to send that value in the SessionHeader.
For example, take the web service:
global class TimeWebService {
webService static string getTime() {
return DateTime.now().formatLong();
}
}
Just for demonstration purposes, I generated the Apex classes to call it. Invoking it with anonymous Apex:
soapSforceComSchemasClassDfbTimeweb.TimeWebService ts = new soapSforceComSchemasClassDfbTimeweb.TimeWebService();
ts.SessionHeader = new soapSforceComSchemasClassDfbTimeweb.SessionHeader_element();
ts.SessionHeader.sessionId = UserInfo.getSessionId();
String serverTime = ts.getTime();
System.debug(serverTime);
Note here that the Session Id was taken directly from the active Salesforce Session and that the web services endpoint default to that from the WSDL. In my case: https://na5.salesforce.com/services/Soap/class/DFB/TimeWebService. In an external application you will need to determine the SessionId and instance(na5) components via other means.
The XML Soap Request was:
<?xml version="1.0" encoding="utf-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<env:Header>
<SessionHeader xmlns="http://soap.sforce.com/schemas/class/DFB/TimeWebService">
<sessionId>00D700000000001!AQoAQHvUJOLpAbU1d_NOTAREALSESSIONID_KlHXaMdj</sessionId>
</SessionHeader>
</env:Header>
<env:Body>
<getTime xmlns="http://soap.sforce.com/schemas/class/DFB/TimeWebService" />
</env:Body>
</env:Envelope>
Note the env:Header containing the SessionHeader and sessionId.
Best Answer
Use a "wrapper" class:
In general, you should consider this design for any method once you exceed about 4 parameters anyways.
Note that this a hard limit in Apex, and is related to managing the size of the call stack, since stack is a limited resource (maximum of 1000 recursive calls). In essence, the 32 parameter limit keeps the maximum stack size under 128kb of data (4 bytes of 32 parameters for 1000 stack frames).
If you don't understand the previous paragraph, it's okay. Just know that that the limitation isn't arbitrary. You need to use a wrapper class, which can hold many thousands of items, if you prefer.