Apex Code Development You need to sign in to do that
Don't have an account?
John Saunders Any Practical Examples of Real Code handling Session Expiration?
I can't believe that I have to either log in on each API call or else wrap every single API call in a loop with retry logic. I _must_ have missed something.
Also, what happens if I'm doing a long query:
result = binding.query(q);
while (!result.done){result = binding.queryMore();}
If I trap the session expiration with a try block around the queryMore, and if I then log in again, will I lose my place within the query?
Should we just make sure we don't take too long?
John Saunders
P.S. Sorry to sound so nasty, but I've been working on a program for the last two weeks, and it works just fine - as long as it doesn't take too long. It looks to me that in order to handle session expiration, I'll have to rearchitect the entire program!
sforce.SforceService SForceService
get
{
if ( DateTime.Now > next_login_req_date )
{
LoginResult lr = svc.login(.....);
svc.SessionHeaderValue.SessionId = lr.SessionId;
next_login_req_date = DateTime.Now.AddHours(1);
}
return svc;
}
void someFunc()
{
SForceService.query(...);
while(!result.done) SForceService.queryMore(..);
...
}
Thank you, Simon, I'll give that a try. In most places, I already access the service stub through a property getter. This at least isolates the inconvenience to a small area of the code.
From an architecture standpoint, this still feels like you're turning your problem into my problem... At the very least, this approach should be documented. Chances are that I should have written my code like this to begin with, and shouldn't be in the position of rearchitecting it simply because it now takes more than two hours!
John Saunders
The possible change in session duration is a good point, i wonder if login should also tell you how long the session is valid for, sound useful ?
Sorry for the late reply, but I may have thought of a way you can make it be "not my problem". My "solution" only works if I understand the entire problem, which is unlikely, but I'll offer it anyway.
If the problem is, "we give out session ids on insecure channels, so we have to make them expire in order to limit the potential damage", then the solution is, "wait until I've used the suspect session id to create a secure session, then pass me a secure session id for me to use on that session in the future". This new session id would only be useful on the secure session, so you'd have to continue to give out an insecure session id on login, which could be used (with expiration) in insecure situations. But the secure session id would be expected not to expire during the secure session.
Ok, I think I just proved that I don't understand the problem, since one shouldn't need a session id of any kind during a secure session?
This is why I should know to leave security up to the security experts!
"Sessions expire automatically after a period of inactivity, which can be configured (in the Setup section in the salesforce.com user interface) for your organization to be 30, 60, 120, or 240 minute intervals. Client applications should log in again after a session has expired or is close to expiring."
Thus, you can configure your sforce organization's session timeout, and set your application to use a configuration file (e.g., web.config or app.config) which contains the same value. Easy, no?
Yes, while somewhat true the water gets a bit muddier when you are writing an environment-agnostic application -- when you don't know what the session expiration is set to.