function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
SBUserPSBUserP 

INVALID_SESSION_ID: Invalid Session ID found in SessionHeader: Illegal Session

    

Hi,

I know there are multiple posts related to this exception and I've gone through them, but I can't seem to find a solution.

I am trying to call a custom web service provided to us by a customer. We used a Partner WSDL previously for making other 'describeObject' type calls to the API. But now, we need to call the web service method exposed by the customer's WSDL. I added the custom WSDL as a web reference on my project.

I'm able to get the session id and server url by calling the sForceService.login(username, password) method. But the subsequent call to the customer's web service method fails with an 'Invalid SessionId' exception. Customer's account is a Sandbox account.

Here is the code:

//_sforceService: Salesforce Partner WSDL reference.

_sForceService = new SforceService();
_sForceService.Url = "https://test.salesforce.com/services/Soap/u/28.0";  //Is this correct? if I don't assign this, the login fails
_loginResult = _sForceService.login("username", "Password+security token");

//ucGuideBook.GIA_ServiceService is Customer's webservice.
ucGuideBook.GIA_ServiceService ucGIAService = new GIA_ServiceService();
ucGIAService.SessionHeaderValue = new ucGuideBook.SessionHeader();
ucGIAService.SessionHeaderValue.sessionId = _loginResult.sessionId;

//This call fails:
string ucGuideBook = ucGIAService.getGuidebookXml("AccountId");

Exception:

INVALID_SESSION_ID: Invalid Session ID found in SessionHeader: Illegal Session. Session not found, missing session key:

It seems like it's going to a different Sandbox than the one that has the active session. It might have something to do with the WSDL endpoint, I'm not sure. The WSDL end point is: https://cs2.salesforce.com/services/Soap/class/ClassName.

The serverUrl that is returned from the .login() method: "https://mysandbox.cs13.my.salesforce.com/services/Soap/u/28.0/OrgId" . I tried changing the wsdl end point to be cs13, but that didn't help.

I looked at existing forum answers, and ensured this setting was off - "Lock sessions to the IP addresses from which they originated" (doesn't make a difference whether it is ON or OFF), and could not find anything else relevant.

Any help would be greatly appreciated.

 

Satish_SFDCSatish_SFDC

From the docs:

 

After logging in, a client application needs to perform these tasks:
Set the session ID in the SOAP header so that the API can validate subsequent requests for this session.
Specify the server URL as the target for subsequent service requests. You must change to the server URL, the login server only supports login calls.
Development tools differ in the way you specify session headers and server URLs. For more information, see the documentation for your particular development tool.

 

I see that you are setting the session id, but not the server url. The initial url is pointing to a login server. Once the login is done, you will be given a new endpoint URL which has to be set as well. Further requests should go to this url and not to the login server.

You should add something like:

ucGIAService.Url = loginUrl.serverURL .

 

Hope this helps.

 

 

Regards,
Satish Kumar
Please mark my answer as a solution if it was helpful so it is available to others as a proper solution.
If you felt I went above and beyond, please give me Kudos by clicking on the star icon.

SBUserPSBUserP

Thank you for the quick reply.  I did try that first actually, but when I do that it gives me the following error:

 

No operation available for request {http://soap.sforce.com/schemas/class/Cust_Service}getGuidebookXml

 

 

 

And one of the forum answers said that we need not reassign the Url as the original one is correct. 

 

But that does seem counter-intuitive to me.  Not sure if I'm doing something wrong?

 

SBUserPSBUserP

After more research, I am more sure that it is not a ServerUrl issue.  I issue the following request through SOAP UI (with end point https://cs2.salesforce.com/services/Soap/class/GIA_Service) and get the same result. (changed sessionid to 'Abc' for security)

 

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:gia="http://soap.sforce.com/schemas/class/GIA_Service">
   <soapenv:Header>
      <gia:AllowFieldTruncationHeader>
      </gia:AllowFieldTruncationHeader>
      <gia:DebuggingHeader>
      </gia:DebuggingHeader>
      <gia:CallOptions>
      </gia:CallOptions>
      <gia:SessionHeader >           <gia:sessionId>Abc</gia:sessionId>
      </gia:SessionHeader>
   </soapenv:Header>
   <soapenv:Body>
      <gia:getGuidebookXml>
         <gia:accountId>?</gia:accountId>
      </gia:getGuidebookXml>
   </soapenv:Body>
</soapenv:Envelope>

 

 

Here is the original login call's response:

 

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns="urn:partner.soap.sforce.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Body>
      <loginResponse>
         <result>
            <metadataServerUrl>https://custSanBox/services/Soap/m/29.0/OrgId</metadataServerUrl>
            <passwordExpired>false</passwordExpired>
            <sandbox>true</sandbox>
            <serverUrl>https://custSandbox.cs13.my.salesforce.com/services/Soap/u/29.0/OrgId</serverUrl>
            <sessionId>Abc</sessionId>
            <userId>005W0sdfdfd1XIAU</userId>
            <userInfo>
            </userInfo>
         </result>
      </loginResponse>
   </soapenv:Body>
</soapenv:Envelope>

 

 

 

Nickname7Nickname7
Hi,

We are seeing the same problem where the API seem to give us back another Sandbox's URL to connect to. Did you find a solution to your problem?

Thanks,
Bulent
SolBUserSolBUser
Hi,

Yes, the problem was that the WSDL given to us was created in the wrong Sandbox Org.  So from my initial example, I was trying to login to a cs13 Org but the endpoint was cs2 from the WSDL.

If I changed the endpoint to cs13 manually in the WSDL, I would login with the correct session, so the above error SessionId went away, but it was giving me the 'No Operation defined' error because the method that I was trying to call - getGuidebookXml was not yet defined on the cs13 Org.

Creating the method in cs13 and the generating a new WSDL with the correct end point resoved our issue.  FYI - Salesforce Tech support helped us figure it out.

Hope that helps
SBUserP.
GABRIEL SILVAGABRIEL SILVA
Hi,

I have the same error. I'm new to the Salesforce web service and I'm trying to understand this error a bit more. In below is my class in java and I'm trying to call the WS method. Can anyone help?

This is my code:
 
package client;

import com.sforce.soap.enterprise.Connector;
import com.sforce.soap.enterprise.EnterpriseConnection;
import com.sforce.ws.ConnectorConfig;

public class Main {

    static final String USERNAME = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXX";
    static final String PASSWORD = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXX";
    static EnterpriseConnection connection;

    public static void main(String[] args) {

        ConnectorConfig config = new ConnectorConfig();
        config.setUsername(USERNAME);
        config.setPassword(PASSWORD);

        try {
            connection = Connector.newConnection(config);

            System.out.println("Username: " + config.getUsername());
            System.out.println("SessionId: " + config.getSessionId());

            int x = soma(4, 6);
            System.out.println("X = " + x);

        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    private static Integer soma(java.lang.Integer a, java.lang.Integer b) {
        client.WebServiceBielService service = new client.WebServiceBielService();
        client.WebServiceBielPortType port = service.getWebServiceBiel();
        return port.soma(a, b);
    }
}


Error:

com.sun.xml.internal.ws.fault.ServerSOAPFaultException: Client received SOAP Fault from server: INVALID_SESSION_ID: Invalid Session ID found in SessionHeader: Illegal Session Please see the server log to find more detail regarding exact cause of the failure.
    at com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
    at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:116)
    at com.sun.xml.internal.ws.client.sei.StubHandler.readResponse(StubHandler.java:238)
    at com.sun.xml.internal.ws.db.DatabindingImpl.deserializeResponse(DatabindingImpl.java:189)
    at com.sun.xml.internal.ws.db.DatabindingImpl.deserializeResponse(DatabindingImpl.java:276)
    at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:104)
    at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:77)
    at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:147)
    at com.sun.proxy.$Proxy37.soma(Unknown Source)
    at client.Main.soma(Main.java:36)
    at client.Main.main(Main.java:25)

 
SBUserPSBUserP
Please confirm that the endpoint that you're using matches the SF account that you're trying to login to.  Your WSDL should contain the endpoint URL.  Find your WSDL in your SF Account by going to Setup --> Develop --> API --> Generate (appropriate) WSDL.  Also please verify that you are using the correct type of WSDL (Enterprise vs. Partner) - you probably are, but just another potential point of failure. Hope this helps. 
GABRIEL SILVAGABRIEL SILVA
Hi SBUserP,

Thanks for answering. I checked what you told me and everything is correct. The WSDL I'm using is the enterprise and the url I tried to set it on the connection but it didn't work.
GABRIEL SILVAGABRIEL SILVA
How can i do this?
 
After logging in, a client application needs to perform these tasks:
Set the session ID in the SOAP header so that the API can validate subsequent requests for thissession.
Specify the server URL as the target for subsequent service requests. You must change to the server URL, the login server only supports login calls.
Development tools differ in the way you specify session headers and server URLs. For more information, see the documentation for your particular development tool.