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
SergeantAgniSergeantAgni 

Problems with Sforce 3.0 using session ID from WIL

I have a composite app integrated with SFDC will a Web Integration Link (WIL.  (I'm accessing Sforce using Java with Axis 1.1.)

I noticed Saturday that it was not working using API 2.5 so I upgraded to the WSDL 3.0 and regenerated the Sforce client stubs.  This did fix the initial problems I was seeing.  (If you are currious, I was getting complaints about "nameField", which is a new element in Field in WSDL 3.0, even though I was still using 2.5).  

However further testing using 3.0 revealed an intermittent problem which I have not been able to work around.  I sometimes get the error back from the Sforce server saying that the session id is bad.

INVALID_SESSION_ID: Invalid Session ID found in SessionHeader

Using tcpmon I have compared traces of runs where it works and where it does not work.  The server will return this error with no changes on the client side.  It will work, then not work, then work again.  So it does not appear to be a problem with the session ID obtained from the WIL, nor with the client request.  I am thinking there is an intermittent issue on the Sforce server.

Please advise.

--SergeantAgni

DevAngelDevAngel

Hi SergeantAgni,

First issue, can you tell which objects the fieldName field was showing up on?  Was this from the describe call and are you using the partner or enterprise wsdl?

On the second issue, I will follow up via email, then post the results.

 

SergeantAgniSergeantAgni

I'm using the Partner API.  With the 2.5 WSDL the error I saw was during the describeSObject call:

org.xml.sax.SAXException: Invalid element in com.sforce.soap.partner.Field - nameField
    at org.apache.axis.encoding.ser.BeanDeserializer.onStartChild(BeanDeserializer.java:260)
    at org.apache.axis.encoding.DeserializationContextImpl.startElement(DeserializationContextImpl.java:963)
    at org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:198)
    at org.apache.axis.message.MessageElement.publishToHandler(MessageElement.java:722)
    at org.apache.axis.message.RPCElement.deserialize(RPCElement.java:233)
    at org.apache.axis.message.RPCElement.getParams(RPCElement.java:347)
    at org.apache.axis.client.Call.invoke(Call.java:2272)
    at org.apache.axis.client.Call.invoke(Call.java:2171)
    at org.apache.axis.client.Call.invoke(Call.java:1691)
    at com.sforce.soap.partner.SoapBindingStub.describeSObject(SoapBindingStub.java:793)

 

rchoi21rchoi21

I'm guessing the redirect server URL you're getting during login is returning 3.0, where it was returning 2.5 in our last release.

This is probably the case, and a bug fix is coming out for it in the next couple of days.

Thanks for your patience.

SergeantAgniSergeantAgni

Right.  However, the second and bigger problem here is that it seems the security option: "Lock sessions to the IP address from which they originated" is now always true.  There is no work around for this one and pretty much ends integrations using composite app servers. 

Many thanks to Dave Carroll who helpped me identify this problem with my composite app.  Apparently, this will also be fixed very soon.

--Sergeant