Apex Code Development You need to sign in to do that
Don't have an account?
Mike Sax ASP.NET best practices
I'm looking for some information on ASP.NET / salesforce.com best practices... For example, if you provide something on your website that accesses the Salesforce.com API (let's say product registration), Do you do a login / logout for each transaction? Per session? Or do you login once and store the session keys in your Application object? What kind of load in terms of calls and simultaneous logins does the API handle? Any information (or pointer to information) would be very helpful.
Thanks!
-- Mike
Hi Mike,
Very topical post as I am currently working on a sample that implements best practices in ASP .Net for a couple of different use cases.
To answer your specific questions around session management, the answer is it depends (what else did you expect). If the page is not accessed via a web link from our ui, then it is reasonable to cache the username, password, session id at the session scope. The server url, which is also something that you should cache, can be cached at the application scope as this will be the same for every user in your company.
The reason for cacheing the username and password are so that if the session extends beyond the session expiration of salesforce.com, you can re-authenticate without bothering your users for their credentials again.
One thing to keep in mind when thinking about the strain on the system in terms of simultaneous login calls (I'm assuming that these will not be simultaneous, but occur in higher frequency at predicatable times such as the start of the business day), is that we have almost 200k users, of which the majority are in the US. With this many users, the number of logins a minute is quite high and the number of logins that your company might make in a minute will just be part of that normal expected traffic and not impact the system in an extraordinary way.
There is a limit to concurrent requests today, but it is user based. By user based I mean to say that it is dependent or keyed on the session id which is unique for each logged in user. This means that if you have 200 users logged into your website and also logged into the api and they each make a request that results in an api call at exactly the same time, there is no concurrency issue. On the other hand, if a single user somehow lauches 5 threads that make an api call at exactly the same time, one thread will fail.
Cheers
Hi Dave,
Thanks for the quick and comprehensive reply. What about customer-related operations... for example, let's say we'd want to implement a more sofisticated version of web-to-lead where we do our own server-side validation, or we ask questions in a multi-page wizard instead of a single form. Is it realistic to call the API on the fly to import the lead, or is that just asking for trouble?
I guess we could do an HTTP Post to the web-to-lead URL but that seems a bit clumsy. Another approach could be to create a queue on our own server with a process that periodically imports these leads into salesforce.com seems like a lot of work (and avoiding that is one of the reasons we like salesforce.com).
FWIW, I noticed that salesforce.com on its own site doesn't use straight up web-to-lead form for most forms (like the ones you fill out to get a demo or a whitepaper).
Thanks,
-- Mike
Hi Mike,
Certainly Web2x (web to lead, web to case, etc) is one of the common use cases of our API. Using lead assignment rules, the lead will be assigned appropriately. So in this case, you would use credentials that have the permissions to create leads.
You can collect up the info from your set of forms and at the end make a create call to create the lead, record any other information that you obtained in any of your other backend system if requred, and then present your confirmation page.
You would need to somehow code the credentials to use to login into your app. I suggest a secure web config or similar mechanism (Check out the MS PetShop sample for securing data in a config) for this purpose.
The one thing that I would remind you about is to use the AssignmentRulesHeader so that the lead gets assigned according to whatever assignment rules you may have established.
Cheers