we are getting SOMETIMES following error messages when we call a custom SOAP WebService from Biztalk:
INVALID_SESSION_ID: Invalid Session ID found in SessionHeader: Illegal Session. Session not found, missing session hash: LWte3bok6NqsvPWBa6tv6A== This error usually occurs after a session expires or a user logs out.
Integration first retrieve the sessionID and then sends data into Salesforce. It seems that Salesforce is invalidating the session for some reasons, and this happens only SOMETIMES and is not predictable.
This error message can be thrown in the following scenarios:
1) The affected integration is sharing credentials with a user or another integration. In this case, if the user or the other integration log out of Salesforce.com while the first integration is running, the existing Session ID will be invalidated, and the integration will get the INVALID_SESSION_ID error message the next time it tries to send a message to the Salesforce API. To solve this problem, avoid sharing credentials and make sure each integration application or user use their own username.
2) One integration is making concurrent calls and not handling the session ID status. Integrations that make concurrent API calls and issue logout calls run a higher risk of receiving INVALID_SESSION_ID errors. For example, if the integration performs the following operations, in this order: 1. Login 2. Create 3. Logout An operation may attempt to issue a create call even though the other operation has logged out, resulting in an INVALID_SESSION_ID. Concurrency is not explicitly supported in the Web Services API and the scenario described above is not recommended. However, in some cases, multiple API requests may issue concurrent calls under the same username (i.e. possibly using the same session). For example, one user may be using the Outlook Edition plugin and a third-party integration at the same time.
We are EXCLUDING both of those. Does anyone have ideas why we are still getting the error??
PS: We also have tested the interface with SoapUI, and we never got the error.