Currently I'm battling a strange problem that has only appeared recently.
We have a situation where i'm transfering data that often takes longer then 4 hours to my system from SalesForce. I have read and have implemented a system where I replace the sessionId in my SOAP header with SessionIds from the frontdoor.jsp. This has been working, but as of last thursday I'm getting INVALID_SESSION_ID errors from the sessionIds gathered from the jsp.
Has something changed recently with regards to this approach I'm taking? Is there something with regards to my account that could be causing this?
(Ok, the title could use work, but who am I, Steven King?)
In the process of preparing to migrate a bunch of integrations away from .NET (my client is going to be switching to Firefox with or shortly after the new release) I began work in earnest converting things to Java, and Axis. Most of the simple stuff came across fairly easily. Printing is another story entirely, but performance became an early problem.
Async calls in Axis seem to be _very_ undocumented. In fact I couldn't find any examples at all, and only a small directory of source code in the Axis source to guide me. After putting Async calls on the back burner I turned to SOAP compression. Before I get into my tale let me set some background. I hate modifying 'stock' code, and would much rather extend and override it where I can. The SFDC technote, while I'm soure it would work, did exactly this. (Seeing as I can't control _every_ machine that would get these applets deployed I can't depend on a modified Axis distribution.)
Off I went looking for solutions to the SOAP compression problem. Why neither .NET or Axis allow for (at least) receiving a gzip-encoded response is beyond me. Nonetheless Google is your friend and I quickly found this library for Axis SOAP compression... And there was much rejoicing.
That was until I actually tried it. Problem is that library makes a call to close the outbound socket. While normally not a problem, the Java SSL sockets really don't like this. In fact it pukes up a very nice exception for you. I even went as far as to disassemble the library and comment out those pieces of code. That didn't get far either as it appeared to just hang at that point waiting to read from the server.
From time to time you find a problem that just kicks your ass. The human spirit triumphs and you get determined to kick it's ass back into submission.
Two days later, holding my sorry and very disfigured ass after getting it handed to me, repeatedly, by SSL sockets in Java, I had pretty much rewritten the Axis HTTPSender routiene. I'd like to say it was all working quite well now, but I can't, in fact it had gotten about nowhere. Invariably what would work with SSL would fail without, or vice versa. Time to try another angle.
One of the stock Axis transports uses the Apache Commons HTTPClient library. Oh joy of joys, perhaps it knows how to do gzip encoding? Nope. Bzzt, sorry Hans, wrong answer...
But there just might be a way to do it. Another 8 hours later I find this interesting message howing how the HTTPClient PostMethod can be abstracted and overridden to allow for receipt of gzip encoded data. Not bad. Halfway there.
Copy and paste that into a class in Eclipse, and modify the one line in org.apache.axis.transport.CommonsHTTPSender.java, making it into my own class int he process, and vola it works!
The moral of the story: What a $%#@ PITA. And I still haven't even gotten to async calls yet...
If anyone is interested in my .java files I used to get here, or the ones that are FUBAR, let me know and I'll be happy to forward them over. My email address should be visible in my profile.
I'm going to wait a few days and give another crack at outbound compression and modifiying what I've got working so far... If anyone wants to chip in, let me know.
Currently I'm battling a strange problem that has only appeared recently.
We have a situation where i'm transfering data that often takes longer then 4 hours to my system from SalesForce. I have read and have implemented a system where I replace the sessionId in my SOAP header with SessionIds from the frontdoor.jsp. This has been working, but as of last thursday I'm getting INVALID_SESSION_ID errors from the sessionIds gathered from the jsp.
Has something changed recently with regards to this approach I'm taking? Is there something with regards to my account that could be causing this?
